How Do You Keep an AI Agent Within a Human Approval?

Record approval for a specific, inspectable action, then make the executing service enforce that same action under current authorization conditions. The record should identify the operation, target, significant parameters, payload version, approving authority and permitted lifetime. A changed request needs a new decision. An uncertain execution outcome needs reconciliation before another attempt can create another effect.

A button labeled “Approve” doesn't establish those properties. The reviewer may see a harmless summary while the tool receives different arguments. The agent may revise an attachment after review. A worker may retry an operation that already succeeded. In each case, the interface can truthfully record a click while the system performs something the person never evaluated.

I would treat approval as a transaction contract between the reviewer and the service that creates the effect. This paper develops that contract using twelve original research, protocol and security-guidance works. It proposes an engineering method and a fictional release example; it reports no customer deployment, experiment or measured security improvement. The purpose is to make a bounded approval claim testable, not to certify an agent as generally trustworthy.

Separate a useful plan from permission to execute it

The user, the planning model, the approval service and the executor have different responsibilities. The user expresses the task. The model proposes actions. The approval service establishes whether an authorized person accepted a particular consequential action. The executor checks whether that acceptance still permits the request it is about to perform. Combining those roles in one conversational transcript makes their boundaries difficult to inspect.

Indirect prompt injection matters because external material can influence the proposal. Greshake and colleagues demonstrated that retrieved content could steer LLM-integrated applications, using synthetic applications and controlled experiments including local HTML inputs (Greshake et al., 2023, §4). Their historical demonstrations establish a relevant failure mechanism, not a current failure rate for your deployment. They don't establish that every proposed action is malicious or that every approval design will contain the influence.

My starting assumption is narrower: the planner may produce an incorrect or manipulated request, but it cannot edit the trusted approval record, impersonate the reviewer or bypass the executor. If those assumptions fail, a well-designed approval dialog isn't the remaining boundary. The architecture must protect the approval service and make relevant effects pass through enforcement, including effects available through scripting tools or background jobs.

OWASP distinguishes excessive functionality, permissions and autonomy in its excessive-agency guidance (OWASP Foundation, 2025). Those are separate design choices. Removing an unnecessary send function is stronger than asking a reviewer to police every attempted send. Where a consequential function is necessary, give it a narrow interface and a credential appropriate to the task. Human approval should govern a bounded capability, not compensate for an unrestricted executor.

Define the object of approval before designing the dialog

“Approve the plan” leaves an important ambiguity: which parts of the plan may the agent change afterward? A deployment plan might contain an environment, artifact, configuration, rollout scope and fallback. Approving its general objective doesn't necessarily approve every future choice of those values. I would first define the fields whose change alters the decision the reviewer is making.

For a release action, those fields might include the immutable artifact identifier, target environment, configuration revision, rollout limit and operation identifier. For a disclosure action, they might include the exact document version, attachments, recipient identities and delivery channel. This is a proposed application contract. The right fields follow the consequence, not a universal list copied into every integration.

Keep descriptive context separate from executable authority. A model-written explanation can help the reviewer understand a proposed change, but it must not be the only representation of that change. The service should resolve actual target identifiers and construct the authoritative action record. Otherwise the model can supply both the request and the reassuring account of what the request means, without an independent check connecting them.

I would store an immutable approved revision rather than mark a mutable job “approved.” If a revision changes, the previous approval remains part of the history but doesn't silently migrate to the new revision. The approving person's authority also needs a defined scope: permission to review a staging change is not permission to release to production. A genuine click from the wrong decision-maker is still insufficient authorization.

Show the reviewer the same significant facts the executor uses

OWASP's transaction-authorization guidance requires meaningful acknowledgment of significant transaction data, server-side enforcement, controlled state transitions and a final check tied to execution. It also discusses invalidating authorization when transaction data changes (OWASP Foundation, n.d., §§1.1, 2.1, 2.5–2.8). These principles predate AI agents. Their value here is that they focus on the transaction rather than the persuasiveness of the assistant's explanation.

The review surface should therefore be generated from the authoritative action record. Display the resolved environment and resource, the actual change, the material limits and any permitted continuation. If names are ambiguous, show enough stable identity to distinguish the target. A familiar display name that now resolves to another destination can change the meaning of approval without changing the words the reviewer recognizes.

For large artifacts, don't pretend that displaying a checksum makes the contents inspectable. The reviewer needs an appropriate diff, rendered preview or independently checked artifact description, together with a binding to the version that will execute. A digest helps preserve identity after inspection. It cannot establish that the person understood the document, that the document is accurate, or that the proposed action is suitable.

Test the representation boundary explicitly. Give the review interface a record with one target and the executor a request with another. Change a hidden default, attachment or rollout field while keeping the generated summary identical. The required result is rejection or renewed review under the declared policy. If the only defense is that the model normally produces an honest summary, the approval is dependent on precisely the behavior it was meant to constrain.

Make the approved representation unambiguous

When approval binds to a structured request, the application needs a reproducible representation. Equivalent-looking JSON can differ in serialization, and poorly defined schemas can let different components interpret a value differently. I would decide which fields are required, how defaults are resolved, which values are forbidden and which version of the action schema applies before creating the approval record.

RFC 8785 defines the JSON Canonicalization Scheme, an informational specification for deterministic serialization suitable for hashing or signing. Its input constraints prohibit duplicate property names and limit number representation to the supported JSON/I-JSON model (Rundgren et al., 2020, §§3.1–3.2). It supplies one possible serialization discipline. It does not define your action's business meaning or make two different tool schemas semantically equivalent.

Resolve identifiers and defaults before binding approval, and reject fields that the executor doesn't understand. If one component treats an omitted rollout limit as “one instance” and another treats it as “all instances,” canonical bytes alone won't fix the disagreement. The application must establish shared semantics and verify the executor's interpretation. A schema migration can therefore invalidate an approval even when a convenient subset of the visible fields hasn't changed.

Use either a protected server-side record or an appropriately authenticated portable representation, according to the architecture. A bare hash submitted by the model is not proof that anyone approved the hashed content. The executor needs a trusted connection between the record, the reviewer, the approved revision and the pending operation. Protect that connection with the same care as the permission to execute; otherwise an attacker can substitute a different record instead of altering the payload.

Match credential scope to the concrete action

OAuth provides useful components, but a valid access token doesn't by itself establish approval of a particular transaction. RFC 9396 introduces structured authorization_details for fine-grained requirements, with a required type that determines the permitted contents. The specification includes detailed transaction examples and describes enforcement involving authorization and resource servers (Lodderstedt et al., 2023, §§1–2). This is more expressive than a broad scope name, provided the deployment implements the relevant type and checks.

I would evaluate whether the platform can carry the action restrictions through that mechanism or needs a separate protected approval record. In either design, document what the resource service actually enforces. If it reads only “deployment.write” and ignores the artifact, environment and rollout limit, a detailed approval object elsewhere in the system doesn't narrow the credential's effective power. Expressiveness on the request side is useful only when it reaches enforcement.

RFC 8707 separately allows a client to identify the protected resource for which a token is requested, enabling audience restriction. Its security discussion also considers specificity in multi-tenant resources (Campbell et al., 2020, §§2–3). Audience restriction helps prevent using a token at the wrong service. It is not a substitute for checking the action, object and parameters within the intended service.

This distinction gives the reviewer a practical architecture question: what would reject an approved staging artifact being sent to production through the same API? An audience check may pass because the service is unchanged. The environment restriction and approved action revision must still hold. Avoid describing several individually useful controls as though each independently answers every authorization question.

Preserve who is acting when the request crosses services

An agent-facing service may call another service under its own workload identity. That can conceal the difference between the human who approved, the application acting for that human and the account technically permitted to modify the target. I would keep those identities explicit in the authorization and audit model, including which one has authority to approve the specific effect.

RFC 8693 distinguishes delegation from impersonation and defines an actor claim for identifying a delegated actor (Jones et al., 2020, §§1.1, 4.1). It does not decide your business approval policy. An actor identity answers who is acting; it doesn't automatically answer which release the reviewer accepted. A downstream service must receive trusted approval context or enforce a constrained operation through another defined mechanism.

MCP's versioned security guidance prohibits token passthrough, describing the risks of accepting tokens not properly issued for the MCP server and forwarding them downstream (Model Context Protocol, 2025, “Token Passthrough”). That guidance concerns credential boundaries. I would treat it as complementary to action approval, not assume that an MCP connection supplies transaction-specific consent simply because protocol authorization succeeds.

Trace the final credential to the actual effect. If an approved operation is handed to a general automation worker, what stops the worker from executing a different revision under broader standing permissions? A trusted job identifier is useful only when the worker resolves it to the protected action and enforces that action. A generated message saying “the user approved this” must remain a claim to verify, not a credential that other agents accept at face value.

Don't mistake possession of a key for approval of a payload

Sender-constrained tokens address another useful but different problem. RFC 9449 defines DPoP proofs that bind requests to possession of a key. Its security discussion explicitly states that the proof covers the HTTP URI and method rather than the message body or general request headers; message integrity relies on other protections such as TLS (Fett et al., 2023, §§3–4, 11.7). DPoP is not a record of what a human reviewed.

A client that legitimately holds the key can still propose the wrong release, recipient or attachment. Sender constraint can help prevent misuse of a copied token by someone lacking the key, while the application separately checks whether the key holder's requested action matches the approval. These properties reinforce one another, but they should have different tests and different evidence in the review.

I would ask the team to demonstrate a request with valid transport, valid credentials and valid proof of possession but a changed significant parameter. The action must fail the approval check even though the other layers succeed. This is a controlled negative test of the application contract, not a claim that the protocol is defective. It prevents a familiar category error: treating proof of the requester as proof of the requested business decision.

Revalidate the state that made approval meaningful

An unchanged payload can become inappropriate when the world changes. A release target may move to a different owner, an approver's role may be removed, or a sharing restriction may be introduced. I would distinguish immutable approved inputs from live predicates that the executor must check near the effect. The contract should state which changes invalidate execution and which approved continuations are deliberately allowed.

HTTP conditional requests illustrate one available mechanism. RFC 9110 defines If-Match using strong entity-tag comparison so an operation can be conditioned on a matching representation. It also defines idempotent methods and cautions about automatically retrying non-idempotent requests without grounds for knowing the effect is safe to repeat (Fielding et al., 2022, §§9.2.2, 13.1.1). These are protocol semantics, not a complete cross-service approval transaction.

An entity tag can protect the represented resource version without protecting a permission stored elsewhere. If policy-relevant state changes without changing the checked tag, the conditional request may still pass. Identify the state covered by each condition and the point at which the service treats authorization and effect as committed. A local transaction doesn't automatically include a remote approval database or identity provider.

Where a remote effect cannot be made atomic with the approval state, document the residual race and choose an appropriate containment or reconciliation design. The honest claim may be narrower than “approval can never become stale.” For a consequential workflow, that uncertainty should influence whether the operation is allowed at all, whether it needs a reservation mechanism, or whether a smaller action can be supported safely.

Give approval an execution lifecycle, not a reusable green flag

I would model a consequential action as proposed, reviewed, eligible, executing and resolved, with explicit alternatives for rejected, expired, cancelled and uncertain. These are proposed application states, not a new standard. Their value is that they force the team to define allowed transitions instead of letting a mutable Boolean stand for several different facts.

“Eligible” should not mean that any number of workers can spend the same approval. Concurrent requests need a coordinated decision about which operation may proceed. Yet marking approval consumed before sending a request can also strand a legitimate action if the worker fails before transmission. The solution depends on the executor and target: durable operation records, supported deduplication and recovery rules must work together. Renaming the flag doesn't solve distributed failure.

A timeout is particularly important. The target may have committed the change before its response was lost. I would move the operation to an uncertain state and query authoritative status where the target supports it. If the target supplies no reliable status or deduplication contract, automatic repetition may be inappropriate. A human choosing to retry still needs to understand that the earlier effect might already exist.

Separate execution permission from permission to retrieve a previous result. A duplicate request can be recognized without disclosing protected response data to a caller who is no longer entitled to it. Likewise, cancellation can stop locally queued work without undoing an effect already accepted downstream. The interface should report those distinctions plainly rather than turning “request cancelled” into an unsupported promise that nothing happened.

Work through a fictional release approval

Consider a fictional assistant preparing a release of artifact A7 to a staging environment. The proposed action specifies configuration revision C3 and a rollout of two test instances. A reviewer authorized for staging inspects the artifact evidence and approves that exact record. The application permits one release operation under that approval; it doesn't authorize production deployment or a later revised artifact.

The identifiers, limits and outcomes below are invented. They demonstrate the proposed contract, not a real product's behavior or a measured test result.

Event after approval	Decision under this fictional contract	Evidence the reviewer needs
Agent substitutes artifact A8	Reject; request a new review	Executed artifact identifier differs from the approved revision
Target changes from staging to production	Reject	Environment is a significant approved field; reviewer lacks production authority
Another process changes configuration C3 to C4	Re-evaluate; don't apply the old decision silently	Relevant state precondition no longer holds
Same operation is delivered to two workers	Coordinate one operation; reconcile duplicate delivery	Durable operation identity and target deduplication/status contract
Target accepts A7 but the response is lost	Record uncertainty and reconcile	Target's authoritative release status, not the agent's account

Suppose the agent's explanation remains “deploy the reviewed update” in every row. That text is insufficient to distinguish the cases. The authoritative action record and observed target state carry the distinction. A security review should be able to reproduce why the first two cases are outside approval, why the third requires fresh evaluation, and why the last two are execution-state problems rather than new permission grants.

Now suppose the task legitimately expands to production. The correct path is a new concrete proposal evaluated under production policy by an appropriate authority. Copying the previous approval identifier into a larger job would obscure the change. A useful agent can prepare the evidence for the next decision without treating the previous decision as a mandate to complete whatever it believes the user ultimately wants.

Keep a batch from multiplying a narrow approval

A collection of individually acceptable actions can exceed the approved whole. Suppose a standing policy permits a small rollout, and two workers each observe the same unused allowance before submitting their requests. Checking each request against the original limit is insufficient if their combined effect exceeds it. This is a proposed concurrency concern, not a measured defect in a particular orchestration platform.

I would define whether the approved limit applies per request, per job, per resource or across an entire campaign. Where it is aggregate, the enforcement design needs coordinated accounting or a reservation mechanism. A worker should not acquire a fresh allowance merely by inventing another job identifier. The approval record must connect the budget to the trusted task identity and the unit that matters operationally.

Partial completion makes the accounting harder. Releasing a reservation after a timeout can permit additional work even though the first action already happened. Holding every uncertain reservation forever can prevent legitimate recovery. Resolve that tradeoff through authoritative outcome reconciliation and an explicit exception process. Record which capacity is committed, still reserved or unresolved. Those states let an authorized person decide what to do next without treating an ambiguous failure as free permission to start again.

Test the contract separately from the planner

I would first send deliberately altered requests directly to a controlled executor harness. Change one significant field at a time, use a stale revision, substitute an unauthorized reviewer and deliver the same operation concurrently. This tests whether the boundary rejects invalid actions without relying on the model to generate them by chance. Record actual effects and authorized useful work, not just error messages.

Then test the full agent workflow with adversarial and ordinary inputs. InjecAgent evaluates tool-integrated agents from a hypothetical state following a user-tool call and uses simulated tool responses for parts of its data-theft evaluation (Zhan et al., 2024, §2.3). That makes it useful for studying induced actions, but it doesn't establish the behavior of your live approval service or downstream transaction. Use its threat categories without borrowing its reported success rates as your own.

AgentDojo provides stateful tool environments and checks utility and attacker objectives against environment state (Debenedetti et al., 2024, §3). That approach supports a useful distinction here: the planner can propose an unauthorized action while the executor successfully blocks its effect. Conversely, an agent that never performs any work may avoid harmful effects while failing the legitimate task. Report proposal behavior, containment and useful completion separately.

Include the human interface in the test. Can the reviewer identify a changed target, understand a significant default and reject without an accidental fallback execution? Can the audit record connect the displayed revision to the effective request? These are local acceptance questions, not outcomes established by the cited benchmarks. Testing should cover the actual tools, policies and recovery paths, and its conclusion should state which variants remain unexamined.

Keep the boundary usable, and state what it cannot prove

The strongest objection is that exact approvals can make useful agents cumbersome. Requiring a new click for every harmless internal step would consume attention without necessarily improving decisions. I would reserve individual approval for defined consequential effects and use bounded standing policy for routine work. A standing policy must still specify its resource set, limits and invalidation conditions; it should not be disguised as a one-time transaction approval.

Another objection is that a malicious or inattentive reviewer can approve the wrong thing. Correct: binding preserves the relationship between review and execution; it doesn't establish the wisdom of the decision. Sensitive actions may need independent evidence or separation of duties. No digest, OAuth extension or benchmark can supply judgment that the process never obtained.

For the earlier question of keeping retrieved instructions from becoming authority, use the document-to-action boundary analysis. For whether temporary authority actually ends, use the privileged-access expiry analysis. This approval review addresses a different decision: whether the effect remains within a specific human authorization, including after changes and failures.

The combined method remains an engineering proposal. Its effectiveness depends on complete enforcement, protected records, correct schemas, trustworthy identity and supported target behavior. The sources establish individual mechanisms and historical research settings, not this deployment's assurance. If you need that evidence, request an AI-agent approval-boundary review. Bring one sanitized workflow and its consequential tool action; I can help identify what is actually approved, where substitution is possible and which acceptance tests would make the claim defensible.