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.
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.
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.
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": "release-notes",`
` "manifest": "sha256:8a37…",`
` "issuer": "release-verifier",`
` "issuedAt": "2026-07-29T08:42:17Z",`
` "subject": {`
"repository": "product",
"headSha": "abc123"
},
` "claim": "commit-range-complete",`
` "evidence": [`
{
"source": "github-compare-api",
"commitCount": 1000,
"responseHash": "sha256:917c…"
},
{
"source": "git-local",
"commitCount": 1247,
"responseHash": "sha256:30ea…"
}
],
` "check": {`
` "name": "commit-range-reconciled",`
"result": "fail"
},
"requestedAction": "github.open-draft-pull-request",
"decision": "deny",
"signature": "ed25519:4f89…"
}
The receipt is the trusted runtime's statement of which claim was evaluated, against which resource state, using which evidence, with what result. The signature makes tampering detectable, and the hashes identify the records evaluated. Importantly, neither proves those records were true. The verifier can evaluate only what the job has made deterministic: presence, counts, hashes, schemas, policy predicates, tests, source coverage, and conflicts. Correctness is only as deterministic as the job and its authoritative systems.
The action must also be bound to the same state that was verified. A receipt for commit abc123 must not authorize an action against a branch that has since moved to def456. The capability therefore carries the resource version, permitted action, expiry, and receipt digest. The action gateway checks them again at the point of use.
Receipts create their own security and privacy obligations. They should contain the minimum facts required for independent verification, use safe identifiers rather than secrets, and follow explicit access, retention, and deletion policies. Where possible, a production implementation should use an established signed-attestation envelope rather than inventing a new one.
"Authoritative" does not have to mean "a human typed it."
Authority can come from the system that owns the fact. Git owns the commit range, the pull request system owns the merge state, a feature flag service owns the rollout state, and a signed policy defines the access rule.
Humans remain authoritative for judgments the organization has not reduced to an executable policy. Is this change important enough to lead the release notes? Is the customer explanation accurate and appropriately framed? Does the value of publishing justify any risks that the release notes are incomplete?
The goal is to leave the human with the smallest consequential decision that cannot yet be verified mechanically, and to give them evidence they can act on without reconstructing the run.
Illustrative receipt review based on the workflow design. It shows the decision surface we are building toward.
We have seen two recurring categories of verified work.
As agents generate more code, trustworthy reviews have to scale with it. We built SAGE, our Security Analysis Guidance Engine, to run alongside a general code-review agent and bring evidence-backed feedback earlier into the development cycle. SAGE orchestrates different models in roles such as: Finder, Critic, and Judge to surface, challenge, and validate findings before they are returned to our engineers.
The important move was translating engineering judgment into inspectable inputs: architecture documents, repository-specific rules, security policies, deterministic tests, and a threshold for feedback that should affect whether code merges. Each finding carries the rule and evidence that produced it. Useful findings, false positives, and issues that Product Security identifies as missed feed the evaluation corpus.
Across our repositories, SAGE ran hundreds of scans, and more than 70% of the findings it raised were resolved before Product Security reviewed the pull request. To be clear, that does not prove the model is always right, and it does not establish the false-negative rate. It shows that the loop can move relevant evidence earlier while the consequential merge decision remains accountable. Missed findings and unnecessary findings still need to feed the evaluation set.
The release notes example exposes a different failure mode; an output can look finished even when the agent never received everything it needed.
The workflow must establish that the commit inventory is complete before classifying customer-visible changes. The value of the control becomes clearer when we hold the agent constant and change only the system around it:
The model behaves identically in both runs. The difference is whether the system treats plausible output as success or requires evidence of completeness before granting the write.
This is a controlled adversarial case, not a production benchmark, and complete inputs still do not guarantee perfect editorial judgment. But they do make the result independently reviewable, and they prevent a known class of silent failure from passing as success.
"Self-healing," an agent’s ability to detect and recover from failure automatically, is a useful goal, but not when it can disguise policy circumvention as legitimate recovery.
A loop can safely self-heal in limited, clearly-defined ways. It can retry a timed-out read, refresh an expired run-scoped credential without widening its scope, rerun a deterministic test after an approved fix, or choose a documented fallback source.
It should not respond to a denied action by finding another credential, switching to an unapproved tool, weakening a policy, or redefining success. That is privilege escalation or goal drift.
Recovery is another declared part of the job. The manifest defines which failures may be retried, which fallback is authoritative, how many attempts are allowed, and when the loop must halt. For consequential writes, it should also define revocation and recovery: how an issued capability is withdrawn, how an invalid receipt is marked, and which rollback or compensating action remains available if the verifier itself was wrong.
The right first workflow is repeatable, consequential enough to matter, and narrow enough to specify.
Start with five artifacts:
A job manifest. Name the owner, required inputs, approved tools, actions that may be earned, actions that can never be earned, and halt conditions.
An authority map. List each source, credential, write path, and system boundary. Start read-only if the consequence of a wrong action is not understood.
An evidence schema. Define the claims the run must support and what source, scope, resource version, time, and check result each receipt contains.
An evaluation set. Include representative successes, missing inputs, conflicting sources, plausible false leads, and known false positives and negatives.
A human decision point. State which judgment remains human and exactly what evidence that person receives.
Run the same evaluation set with and without the verification gate. Measure:
| | Incomplete-input false accepts | How often unsupported work earns permission | Correctly halted incomplete runs | Whether the gate catches the failure modes it claims to catch | Complete runs incorrectly halted | Whether the control creates unnecessary friction | Median human review time | Whether receipts reduce reconstruction work | Rework after an accepted result | Whether accepted work is actually trusted downstream | Cost per trusted completion | Whether the full loop is economically viable |
Runtime verification and offline evaluation are different loops. Runtime verification asks whether this run satisfied its contract. Offline evaluation asks whether the overall system completes useful work, halts for the right reasons, avoids unnecessary human intervention, and improves over time.
Do not promote the agent because its output has improved. Promote the loop only when the evidence shows that the next specific permission is safe to grant. That might mean moving from analysis to opening a draft pull request while merge and publication remain prohibited.
The first goal is not general autonomy. It is one production mandate with a control pattern the next team can reuse.
Agents will keep using more tools, crossing more systems, and taking on longer-running work. But while their outputs will remain probabilistic, the rules governing their authority must be explicit and deterministically enforced.
At 1Password, we are building the identity and credential boundary that makes this possible. Each run executes under a job-specific workload identity, not a persistent agent identity. It receives only the credentials and mediated access required for that job, and that access is revoked when the run ends.
The next step is to make this pattern runnable: one open reference loop, one adversarial evaluation set, and one receipt a human can independently inspect.
Are you interested on building the future of AI-powered security? 1Password is hiring. View our open positions here.