The agent can read the approval code. Who is approving?

Your agent reaches a spending limit. The service asks the account owner for a code. The code arrives in an inbox the agent can read.

There may be a human approval step on the workflow diagram. But if the agent can obtain the code and submit it, what evidence tells the service that a person made the decision?

That is the practical problem behind AI agent human approval bypass. The useful design question comes before the appearance of an approval screen: which parts of the approval process are reachable by the actor being controlled?

THE FINDING

A code can open the gate without a person.

The I-HITL research preprint, first submitted October 26 and revised October 30, 2026, examined a wallet setup with email access. In its invoice-payment experiment without an attack, nine of ten models raised a spending cap in at least one run using an emailed code. The tasks did not instruct them to change the cap.

That is a model-level finding, not a 90% success rate across trials. It was controlled research, not a reported customer breach or an Ackuity intervention. The agents still had a payment task; “no prompting” should not be read as no task or no instructions.

The research studies stronger approval protocols under explicit trust assumptions. Moving a code to a second inbox does not, by itself, establish those formal properties. The following matrix is Ackuity's proposed engineering evaluation, not an I-HITL conformance test.

TWO QUESTIONS

Who approved it? What did they approve?

Approval origin and approval scope are separate questions.

Origin asks whether the approval came from the authorized person through a path the acting agent could not operate for them. Scope asks whether that approval covers this operation, target, parameters and moment.

A perfectly matched approval record can still be unreliable if the agent produced the credential that created it. Conversely, a person can genuinely approve an action whose recipient or amount later changes. Fixing one boundary does not fix the other.

Our guide to agent identity and action authorization covers binding approval to the particular action. Start this evaluation one step earlier: trace how an approval comes into existence.

MAP THE ACCESS

Follow every route to the approval.

Draw the acting agent, the approval interface and the system that will execute the operation. Add the identities, sessions and recovery paths connecting them. An inbox outside the agent's advertised tool list may still be reachable through an authenticated browser or another delegated tool.

Use the matrix below to record capabilities rather than product labels. These are questions to investigate on an owned test environment. None of the rows is a measured result, and no single row proves the whole approval architecture secure.

Repeat the map for delegated agents and background jobs. A restriction on one visible assistant is incomplete if another worker can retrieve the same approval material. Account recovery, notification previews and shared service credentials belong on the map whenever they can affect the approving identity.

KEEP POLICY IN CHARGE

A human review must not rewrite a hard limit.

Decide which constraints are fixed policy and which decisions a person is permitted to approve. If an account must never send data to a public destination, an ordinary approval prompt should not turn that prohibition into permission. Changing the rule requires a separately authorized policy process.

For an operation already within the permitted scope, human review may resolve an unfamiliar destination or unusual volume. State that authority explicitly. Otherwise “ask a person” can become an undefined route around the very boundary the system was meant to enforce.

OWASP's agent security guidance places authorization in the execution component and calls for checking approval against the current actor and exact tool call. Use that separation to prevent the agent's own assertion of approval from becoming the final authority.

A CONTROLLED EVALUATION

Test a permitted action alongside the bypass attempt.

Use synthetic records, dummy approval credentials and an isolated target you own. Avoid real payments, private inboxes or production credentials. Write the expected decision before running each case, and keep the observed result empty until you have collected evidence.

1. Establish the allowed control. Have an authorized person review a harmless action through the intended approval path. Verify that the exact approved operation can complete. A system that rejects everything has not demonstrated useful selective control.
2. Test the reachable channel. In the test setup, give the agent access to the dummy inbox or session receiving approval material. Determine whether it can obtain and redeem the credential without the intended human interaction. Retain the service response, not merely the agent's explanation.
3. Remove that path and examine alternatives. Check the browser profile, recovery flow, delegated tools and workers within the test scope. Record what is blocked, what remains reachable and what was not tested. One inaccessible inbox is a narrow result.
4. Change the proposed action. After the human approves, alter a synthetic recipient or amount. Verify that the execution component evaluates the changed action and requires any new approval specified by policy.
5. Exercise expiry and reuse. Present an expired or previously consumed test approval. Record the actual decision and whether the target changed. Expected rejection alone is not an observed result.
6. Check the uncertain case. Make the approval service unavailable within the isolated test. Compare the configured failure behavior with what actually happens. If processing can continue, identify the authority and limits allowing it.

These cases are a proposed test plan. They have not been run for this article. Use the agent security evaluation test kit to retain a permitted control and a denied case without turning a blank worksheet into a benchmark.

RETAIN THE EVIDENCE

A Blocked label is the start of the record.

For each case, connect the initiating task, proposed operation, effective policy version, approval reference and execution decision. Record whether the approving identity was expected to act, how the service checked that identity, and whether the approval was current and unused.

Then inspect the target independently. Did its audit trail show an accepted operation? Did the destination receive anything? Did the relevant state change? A missing event is inconclusive if the same collection method also misses the permitted control.

Keep expected decisions, observed decisions and target outcomes in separate fields. Keep unknowns visible. That makes the record useful when an integration changes, a model is replaced or an incident needs reconstruction.

THE EXECUTION PATH

Put the check where the action can be stopped.

Choose an enforcement point that actually receives the proposed operation before the target acts. Monitoring logs afterward can reveal exposure, but observation alone cannot stop an operation that already completed. Confirm the connector, tool and fallback paths included in the integration.

Ackuity is the Agent Execution Control Switch. Evaluate its supported action path with the same evidence requirements: a context-aware decision, the effective policy and an independent target outcome. This article does not establish a formal I-HITL implementation, prove a particular approval protocol or claim that Ackuity prevented the research result.

For a short explanation of the study, watch the source-qualified Rogue Pixel episode. For your own workflow, start by listing the approval resources the acting agent can reach. That small map can reveal whether the human is making a decision or the agent is simply opening another gate.