Verified loops: Building AI agent trust and accountability

AI agents have crossed an important line from making suggestions to taking actions. They can read a repository, call internal systems, change code, open a pull request, and keep working while the human moves on. In this world, it is no longer enough to ask whether a model is capable. We have to ask: Who is acting, a person or their agent? What authority did they receive? Which systems could they reach? What evidence did the run produce? What permission should that evidence earn? And who remains accountable for the next consequential action? At 1Password, the pattern we use to answer these questions is the verified loop. In a verified loop, an agent works under a job-specific identity, through tools governed by an access control gateway, and earns a given permission by proving that it satisfies the conditions of a human-defined policy. This is how an organization can begin converting human-owned procedures into production tasks for agents. A verified loop doesn’t make the agent infallible, but it clearly defines the agent’s task and authority, and makes incomplete or unsupported work harder to pass off as finished. A plausible result is not the same as a verified result Consider an agent asked to draft release notes for a release containing 1,247 commits. The draft is clearly written and looks complete. Every change in the agent's input appears to be accounted for. But the comparison API returned only its first 1,000 commits, and the agent had no way to know that 247 were missing. The problem in this workflow is that there’s no process that identifies that this plausible-looking result is, in fact, incomplete. A tool inventory could tell us that the agent used the repository API, and scoped authorization could prove that it could read the repository but not publish. Neither tells us whether it received the full commit range or traced each claim to an approved source. That is what verification adds, by evaluating the run against the job that was actually specified. Authorization transition: trusted evidence earns one state-bound, expiring capability. In this model, the agent can propose work and request an action. It cannot write the authoritative evidence, evaluate its own compliance, or grant itself permission. Identity and the tool gateway constrain what the run can reach. The verifier determines whether system-emitted evidence satisfies the contract. Passing earns only the capability declared in the manifest, bound to the exact resource state evaluated. This claim depends on a controlled runtime. The agent and any code it generates cannot hold ambient credentials or use an unmediated network path to the protected systems. If a shell command can reach the same API directly, the tool gateway is a convention, not a security boundary. The job definition is the verification boundary A verifier cannot evaluate arbitrary work; it can only evaluate predefined claims against trusted evidence. "Do a good job" is not an executable requirement. Therefore, the verification contract must be defined before the run starts. A human-owned manifest names the accountable owner, authoritative sources, required checks, actions that may be earned, and actions that can never be earned: version: release-notes-v3 job: release-notes owner: release-team subject: repository: product from: v4.1.0 to: v4.2.0 head_sha: abc123 required: - commit-range-reconciled - every-claim-has-approved-source - missing-metadata-reported may_earn: # deny by default; nothing else is grantable - github.open-draft-pull-request never_earn: # cannot be added to may_earn by any revision - github.merge - release.publish The prompt tells the agent how to do the work, while the manifest tells the control plane what the run may reach, what it must establish, and which permissions it can earn. The control plane must authenticate who approved the manifest and record every change. Otherwise, an agent that cannot bypass a policy could still benefit from a weakened policy. For this job, passing completeness checks can earn a draft pull request, but merge and publication permissions remain with the release owner. The evidence must come from the system, not the agent At 1Password, we use OpenTelemetry traces as the raw event record for a run. The trusted runtime and tool gateways emit the spans, which alone do not necessarily represent the upstream system’s complete state. The agent does not get to write the authoritative record of its own behavior. Calling this evidence requires additional integrity controls: the emitter must be authenticated, the transport and storage protected, and the receipt signed outside the agent's execution context. An overnight run can produce tens of thousands of spans and an unstructured pile of telemetry is not a verification system. Instead, a verification harness applies predefined checks to reduce those spans into job-specific evidence receipts. In the truncated release notes run, one receipt might look like this: { "job": "

Excerpt shown under the publisher's RSS terms · 198 words · full text and figures are on the publisher's site