Source-linked AI summary

Approve What, Exactly? Effect Binding and Trusted Rendering for Agent Step-Up Authorization

Sai Varun Kodathala, Prashanth Pollishetty, Jaylen Cargill

arXiv:2610.21063v1cs.CRcs.AI

TL;DR

Agent approvals are treated as a second factor, but the paper asks whether they are independent of the agent and bound to the exact action. It defines attacks, audits runtimes, and builds and evaluates ASU, a gateway-based reference defense. Binding removed post-approval attacks against ASU in the experiments, while trusted rendering improved attack detection by approvers in the tested settings.

  • Problem

    Agent approvals are often treated as a second factor, although they may remain reachable by the agent or fail to name the exact effect being approved.

    Source: §1.1 · p. 2
  • Method

    The paper defines approval-path attacks, audits agent runtimes, and builds ASU, which renders a canonical effect descriptor for passkey approval and executes the stored call.

    Source: §5.1 · p. 13, §5.2 · p. 13
  • Results

    Binding removed every post-approval attack against ASU in the experiments, while trusted rendering reduced forged-narration attack success from 0.54 to 0.03.

    Source: §8.1 · p. 25, §10 · p. 28
  • Takeaways & Limitations

    Binding and trusted rendering address different approval failures, and the rendering benefit depends on an approver reading the card.

    Source: §8.1 · p. 25

    No human approvers were studied, so the language-model results do not establish how often people catch attacks.

    Source: §8.3 · p. 26

Abstract

from arXiv · show

AI agents now pause for approval before they send money, delete files or email outsiders, and that approval is usually treated as a second factor. We argue it is one only when compromising the agent cannot produce it and when it names exactly what it approves, and we test both conditions. We define twelve attacks on the approval path, including decoy recipients, amount cancellation, card padding, label spoofing, enrollment squatting and threshold splitting, and run them against the Agent Payments Protocol (AP2), the Microsoft action-bound approval design and Model Context Protocol (MCP) elicitation. An audit of ten agent runtimes finds no third-party verifiable approval record, no flood limits where measurable, and post-approval argument changes in four of eight runtimes with measurable binding. As a reference defense we build ASU (Agent Step-Up), a gateway that renders the approval card from a canonical effect descriptor, has a passkey on the phone of the user sign its digest, and executes only the stored call. Tamarin proves its binding, single-use and key-level non-repudiation properties under three stated hypotheses (53 lemmas). Across 27,108 scripted trials and 609 AgentDojo attack pairs, ASU stops substitution, replay and grant stretching, and the trusted card cuts forged-narration attack success from 0.54 to 0.03. With 15 current language models as automated approvers, the trusted card raises the attack catch rate from 0.30 to 0.98, at the cost of refusing 16 percent of harmless near misses, mostly due to a placeholder artifact in our stimuli. A second device adds nothing measurable over a trusted on-host confirmation in these experiments, flooding still succeeds 0.45 to 0.60 of the time against a modeled approver, and approval cannot stop effects that policy already allows. Code, data and proofs: https://github.com/Sports-Vision-Inc/agent-step-up

1 Introduction

Agent approval counts as a second factor only when the agent cannot produce it and it commits to the exact effect. The paper tests this criterion through attacks, runtime audits, a formalized reference defense, and evaluation.

1.1 The problem: an approval the agent can reach is not a second factor

  • Approval protects an agent action only if compromising the agent cannot produce it and the approval commits to exactly what executes.The motivating examples include same-channel confirmations and out-of-band codes or cards that do not bind the approval to the effect.Source: §1.1 · p. 2

1.2 Motivating evidence: approvals already fail in practice

  • Agents of Chaos cases describe non-owners impersonating the owner and obtaining confirmations through channels the agent treated as trusted.The paper also cites deployed post-approval substitution and practitioner reports of misreported actions and symbolic-link changes.Source: §1.2 · pp. 2–3

1.3 Approach

  • The study defines approval properties and attacks, audits ten runtimes, builds and formally models ASU, then evaluates binding, rendering, and a second device.The evaluation includes scripted attacks, AgentDojo replays, simulated approvers, and language models acting as automated approvers.Source: §1.3 · p. 3

1.4 Contributions

  • The contributions include a seven-property criterion, twelve attacks, a reproducible runtime audit, ASU with 53 Tamarin lemmas, and an evaluation of approval components.The paper does not claim the underlying idea or cryptographic primitives as new, and reports no human-subjects data.Source: §1.4 · pp. 3–4

2 Background and Threat Model

The paper frames agent approval around independence from the agent and commitment to the complete effect. Its model specifies capabilities, properties, trust boundaries, and comparison designs.

2.1 From human MFA to agent approval

  • Agent approval adapts MFA’s independence and dynamic-linking ideas: the factor must be beyond the agent’s reach and commit to the complete effect, not merely a session.The paper also notes that a trusted path is needed when the agent controls the usual approval surface.Source: §2.1 · pp. 4–5

2.2 System model and properties

  • A call is canonicalized into an effect descriptor and digest, while agent-written explanation stays outside that descriptor; seven properties define the intended guarantees.The properties cover independence, effect binding, single use, trusted rendering, non-repudiation, grant scope, and flood resistance.Source: §2.2 · pp. 5–6

2.3 Threat model

  • The agent is fully adversarial, while the gateway and user device are trusted; human behavior is modeled rather than measured, and several effects remain out of scope.Out-of-scope cases include knowingly approved harmful actions, reads already allowed by policy, gateway bypass, and phone compromise.Source: §2.3 · p. 6

2.4 Approval designs compared

  • The comparison modes omit selected properties: host-confirm isolates the second device’s contribution, while txn-sign tests the cost of displaying only payee and amount.Both are modes of the same gateway; the latter still binds every argument.Source: §2.4 · p. 7

3 Attacks on the Approval Path

The section defines attacks on the approval path and evaluates third-party designs alongside ASU. Findings distinguish binding failures, rendering risks, and remaining trust assumptions.

3 Attacks on the Approval Path

  • The study defines twelve attacks targeting what is shown, signed, or executed, applies them to three third-party targets and ASU, and reviews a fourth statically.The targets were tested in documented intended use with neutral placeholders; no real service, credential, or person was contacted.Source: §3 · p. 7, §3.2 · p. 8

3.3 Findings

  • AP2’s constraint layer rejected executed binding attacks, but its sample card can display different payees alike and cumulative budgets depend on integrator-maintained usage context.These residuals are sample or integrator issues, not breaks of the signed mandate.Source: §3.3 · p. 9
  • AGT binds the whole action, consumes approvals once, and rejects post-approval substitution; it leaves flood control to the host and has a documented cross-language float-serialization parity issue.The float issue fails closed, while 50 pending requests could be opened without rate limiting.Source: §3.3 · p. 9
  • MCP form elicitation forwards server-written text without binding the answer to an effect; different payments produced identical requests and both executed after acceptance.These findings concern form mode; the specification directs sensitive interactions to URL mode and recommends client rate limits.Source: §3.3 · pp. 9–10
  • OpenClaw’s card escapes and caps text and its standing grants use resolved arguments, while in-process frameworks let the agent drive approval and four showed post-approval substitution.OpenClaw’s residual standing-grant match uses parsed arguments rather than a signed digest; no framework has a trusted renderer.Source: §3.3 · p. 10
  • ASU blocks AB1–AB8 and AB10–AB12 in live-gateway tests; its partial AB9 result depends on an honest gateway rendering origin.The device signs the effect that executes, but authenticators do not display the challenge, so a compromised gateway-origin page could show a different card.Source: §3.3 · p. 10, Table 4 · p. 10

4 Measuring Deployed Agent Runtimes

The audit applies uniform probes and criteria to documented runtime approval mechanisms, then finds gaps in effect binding, rollback-safe single use, flood control, and verifiable records.

4.1 Method

  • The audit used isolated probes with stub models for nine runtimes and static review for OpenClaw; proprietary Claude Code, Codex CLI and Cursor were excluded.CrewAI and AutoGen each contributed two rows, yielding twelve rows overall.Source: §4.1 · p. 11
  • P1 was treated as structural, while P2 tested resume and backing-store changes, P3 tested three replay modes, and P4–P5 were source-review judgments excluded from counts.P1 callbacks in the agent process were marked †; 32 judgment cells were excluded.Source: §4.1 · p. 11

4.2 Results

  • Across eight rows where effect binding was measurable, 3 pass, 1 is partial and 4 fail.The reported outcomes include post-approval argument changes in multiple runtimes.Source: §4.2 · p. 11, Table 5 · p. 12
  • The same Agno substitution probe reproduced through the remote continue endpoint in 3.0.9, 3.0.10 and 3.1.3; rollback still double-executed in 3.1.3.Same-call replay double-executed on the 3.0 releases but executed once on 3.1.3.Source: §4.2 · p. 12, Table 6 · p. 12
  • In five rows, approvals consumed relative to run state double-execute after rollback; the two passing gates ask again for every call.The approval artifacts in the five rows carry no independent nonce or expiry.Source: §4.2 · p. 12
  • In all seven measurable rows, no runtime capped or rate-limited pending approvals, and the audit found no signed approval record verifiable by a third party.A single model turn raised 20 pending approvals in the five runtimes with a native pause.Source: §4.2 · p. 12
  • These results cover documented approval primitives, not every way integrators might use them; careful rendering, nonce persistence and trusted resumption can close several gaps.The audit’s conclusion is that the default pause is not yet a factor the agent cannot reach.Source: §4.2 · p. 13

5 ASU: A Reference Defense

ASU is a reference gateway that binds approval to a canonical effect descriptor and renders the approval card on the user’s phone. It executes the stored call after verification, with typed rendering, policy triggers and scoped grants addressing approval-path attacks.

5 ASU: A Reference Defense

  • ASU combines a second device, digest-bound approval, typed card rendering and argument-complete grants as a control whose properties are proven rather than assumed.The design places the decision in a trust domain the agent cannot reach.Source: §5 · p. 13

5.1 Protocol

  • On a challenge, the gateway stores a pending approval and returns an opaque identifier; the phone displays the gateway-rendered descriptor, and the gateway later executes that stored descriptor.The agent receives no card text or challenge, and resubmitted arguments with a different digest produce an effect_mismatch response without execution.Source: §5.1 · p. 13, Figure 3 · p. 14

5.2 What the card shows and why

  • The card uses typed, quoted values; escapes and flags unusual characters; separates agent-chosen argument names from trusted labels; and identifies every recipient, account, URL and path as a target.It also flags inline interpreters and collapses the agent’s explanation by default as untrusted.Source: §5.2 · pp. 13–14, Figure 4 · p. 15

5.3 Descriptor, policy and grants

  • The descriptor normalizes typed arguments and targets, while policy triggers cover first-time recipients, thresholds, destructive classes and aggregate windows that prevent sub-threshold splitting.Grants bind arguments to approved values except explicitly bounded fields, and carry use, total and expiry caps scoped to a session and tool.Source: §5.3 · pp. 14–15

5.4 Implementation

  • The implementation includes a FastAPI gateway, MCP front end, authenticator page, enrollment and offline-verification tools, formal models, probes and tests.In-process medians were 3.5 ms for a challenged call, 3.4 ms for passkey verification, 36 µs for policy evaluation and 144 µs for offline receipt verification; network and human decision time are excluded.Source: §5.4 · p. 16, Figure 5 · p. 16

6 Formal Analysis

The formal analysis checks ASU’s binding properties across unbounded sessions and makes its adversary model and three required hypotheses explicit. All 53 lemmas produced their expected verdicts, while hypothesis-removal variants expose the attacks each assumption prevents.

6.1 Model and hypotheses

  • The model gives the agent Dolev-Yao control over tool calls, targets, amounts, explanations, gateway outputs, and messages to gateway rules.The challenge is modeled as a free tuple.Source: §6.1 · p. 16

6.2 Results

  • 53 lemmas across 7 theories produced the expected verdict, with 0 mismatches and no errors; the full run took about three minutes.Table 7 reports the main lemmas, whose existence results show that executions, grant executions, and receipt verification are reachable under H1–H3.Source: Table 7 · p. 17, §6.2 · p. 17

6 Formal Analysis

  • Canonical JSON is assumed injective and SHA-256 collision resistant; dropping the nonce is conservative for safety lemmas, and rendering injectivity is checked by property test.The analysis uses Tamarin 1.10.0 and claims no priority for applying formal analysis to agent authorization; verdicts were obtained with Maude 3.2 despite Tamarin reporting that engine version as unsupported.Source: §6.1 · pp. 16–17, §6 · p. 16

6.1 Model and hypotheses

  • The proofs rely on H1, that humans decide from trusted card fields; H2, closed first-credential enrollment; and H3, an honest rendering origin that shows the card matching the authenticator challenge.Authenticators do not display the challenge, making H3 a stated assumption.Source: §6.1 · p. 17

6.2 Results

  • Removing H1 lets an agent mislead a human with “send 5 to alice” while paying 500 to an attacker, even though signature binding and key-level non-repudiation still hold.Each single-hypothesis-removal variant was falsified and produced the expected attack.Source: §6.2 · p. 17
  • The baselines fail selectively: narrated cards and relayed codes fail effect binding and agent independence, while removing consumption breaks single use and replacing the passkey with a shared-key MAC breaks non-repudiation.Table 8 compares the same lemmas across the baselines; the shared-key MAC trade-off matches aiAuthZ’s design.Source: Table 8 · p. 18, §6.2 · p. 18
  • Removing H3 lets the origin show one card while the authenticator signs another approval’s challenge; removing H2 lets the agent enroll the first credential and approve its own calls.Key-level non-repudiation still verifies without H3; the H2 attack is AB7.Source: §6.2 · p. 18
  • The model excludes free-text arguments left unconstrained by a grant, makes no claim about their scope, and does not model whether a person reads the card.Nonces and expiry are omitted because the fresh approval identifier performs their role in the model.Source: §6.2 · p. 18

7 Evaluation

The evaluation tests whether effect binding blocks post-approval attacks, whether trusted rendering helps when agents misrepresent actions, and what approval still leaves unresolved. Across scripted attacks, AgentDojo replays, and language-model approvers, it finds strong benefits from binding and trusted cards, alongside limits from fatigue and effects policy allows without approval.

7.1 Setup

  • The evaluation paired scripted attacks with AgentDojo replays and tested 15 language models on attack stimuli and benign near misses.The scripted suite ran 27,108 trials; AgentDojo supplied 609 user-and-injection pairs. Simulated approver miss probabilities were assumptions, so results depending on them are sensitivity results.Source: §7.1 · p. 19

7.2 RQ1: binding stops what happens after approval

  • Against post-approval attacks, all four failed against ASU, while unbound approvals allowed each attack to succeed every time.Other bound designs failed on grant stretching in 0.20 of trials because the changed recipient appeared as an ordinary card and the perceptual approver sometimes missed it.Source: §7.2 · p. 19, Figure 6 · p. 20

7.3 RQ2: trusted rendering matters when the agent lies

  • In AgentDojo forged-narration attacks, success fell from 0.54 with narrated cards to 0.03 with ASU for the exact-compare approver.ASU’s residual 0.03 consisted of effects allowed without approval; removing the agent’s explanation also helped narration-trusting approvers, while partial transaction displays let more attacks through than the full card.Source: §7.3 · p. 21, Figure 7 · p. 21

7.4 RQ3: the second device adds nothing measurable here

  • Host-confirm matched ASU in 137 of 140 scenario cells and every AgentDojo cell; their three differences all involved grants, not the second device.The experiments compromised the agent but not the host display; whether a separate device changes what people notice remains untested.Source: §7.4 · pp. 21–22

7.5 RQ4: language models as automated approvers

  • Language-model attack catch rates rose from 0.30 on agent descriptions to 0.98 on trusted cards, while trusted-card false-deny rates on benign near misses were 0.16.Most false denials were attributed to placeholder bodies in the stimuli; without those, the rate would be 0.02.Source: §7.5 · p. 22
  • On attack families, models caught decoy recipients, narration forgery, and padding at 1.00 on the card, while visible substitution had the lowest card catch rate at 0.88.Removing agent explanations changed at most two of 34 paired decisions per model; temperature-0.7 samples agreed with each other on at least 0.91 of items for every model.Source: §7.5 · p. 23, Figure 9 · p. 23, Figure 10 · p. 23

7.6 RQ5: what approval does not fix

  • With flood limits on, approval flooding still succeeded 0.45 to 0.60 of the time against the perceptual approver.Pending-card limits and lockout reduce an attacker’s chances, but each remaining chance is still a draw against an imperfect approver.Source: §7.6 · pp. 23–24
  • Approval cannot stop effects policy permits without prompting, and the preferred step-up policy varied with assumed fatigue parameters.Payment splitting succeeded in every mode without an aggregate limit (A7, 1.00) and fell to 0.00 with the aggregate window; every bound design completed all 97 benign AgentDojo tasks without false blocks under simulated approvers.Source: §7.6 · p. 24, Figure 11 · p. 25

8 Discussion and Limitations

Binding is the dependable half of agent MFA: it prevents post-approval substitution, while trusted rendering addresses misleading descriptions but depends on an approver reading the card. Deployment guidance pairs effect binding with faithful rendering and flood controls; the evaluation leaves important limits around human behavior, attack coverage, and runtime auditing.

8.1 What the results say about agent MFA

  • Binding removed every post-approval attack against ASU in the experiments, while trusted rendering made the largest difference when the agent lied but could prompt harmless refusals.The attacks that succeeded against real designs were mostly rendering attacks, including padding, spoofed labels, and displays that failed to distinguish effects.Source: §8.1 · p. 25

8.2 Deployment guidance

  • For deployment, bind a canonical digest of every argument and execute the stored call; render every value, escape hidden content, list all recipients, and cap pending approvals.Lock out repeated denials, while recognizing that this only reduces the attacker’s chances; an agent’s claim that a user requested an allowed write alone was enough to skip approval in the scenarios.Source: §8.2 · pp. 25–26

8.3 Threats to validity

  • No human data were collected: approver miss probabilities were assumptions, the exact-compare oracle was an upper bound, and the fatigue model was a sensitivity analysis.The language-model findings concern automated reviewers and do not establish how often people catch attacks; a user study was not attempted.Source: §8.3 · p. 26
  • The scripted suite used one attack technique per scenario, while AgentDojo used ground-truth calls with honest or forged narration; a best-response attacker could raise baseline success or find untested ASU attacks.The red-team tests and attack matrix separately cover ASU-specific attacks.Source: §8.3 · p. 26
  • Model-approver evaluation used 23 attack and 11 benign hand-built stimuli with placeholder bodies, inflating card false denies; per-model intervals were wide.Models were selected automatically on one day, routing could change backends, and a content filter blocked some answers.Source: §8.3 · p. 26
  • OpenClaw was reviewed from its released bundle rather than run, proprietary coding agents were not audited, and tested runtimes and protocols may change with new releases.The attack matrix and language-model runs used working trees with uncommitted changes outside the gateway code.Source: §8.3 · p. 26

9 Related Work

Prior work already specifies or builds several ingredients of digest-bound, single-use, device-signed agent approval. This paper’s contribution is an attack and measurement study focused on rendering and grant attacks, runtime behavior, and the effects of binding, trusted rendering, and a second device.

Digest-bound approval for agents

  • SUDP (Yu et al., 2026) and Microsoft’s ADR 0030 (Microsoft Agent Governance Toolkit, 2026) are closest to ASU: both bind canonical operations to fresh approvals, while this paper tests ADR 0030’s implementation rather than claiming its constructions.SUDP has no empirical evaluation; ADR 0030 specifies one-time execution consumption, fail-closed validation, and a hash-chained log.Source: §9 · pp. 26–27

Payment mandates and out-of-band authorization

  • AP2 (Google, 2025) uses trusted-surface cart mandates, while CIBA with rich authorization requests uses a separate-device bearer token whose details come from the backend.Prior analyses report that valid AP2 mandate signatures do not guarantee user intent (Aviv et al., 2026); trusted rendering addresses that gap only in part.Source: §9 · p. 27

Binding approval to execution

  • Binding-focused work includes same-machine browser-chrome cards, commit-time rechecks, and reauthorization approaches; this paper adds rendering and grant attacks that binding alone does not cover.The related work includes Consent Integrity (Weng, 2026), Verifiable Action Card (Irshad et al., 2026), AID-Guard (Tong et al., 2026), and others.Source: §9 · p. 27

Agent identity and authorization

  • Earlier aiAuthZ bound messages to identities and checked calls against off-host policy; this paper adds per-action human approval and an asymmetric receipt.Other proposals address agent identity, delegation, intent-governed authorization, and workflow authorization.Source: §9 · p. 27

Failures, approvers and fatigue

  • Prior work documents approval failures and fatigue, while studies of machine approvers find agent justifications can raise approval of policy-violating actions; the trusted effect-rendered card largely removes that effect in this paper.Table 10 positions the closest work by whether items are specified, host-dependent, partial, or addressed elsewhere.Source: §9 · pp. 27–28, Table 10 · p. 28

10 Conclusion

The conclusion is that agent approval depends on both binding the approval to the exact effect and rendering that effect faithfully. Binding prevents post-approval attacks in the experiments, while trusted cards improve attack detection; second-device value, flooding, and policy-permitted effects remain bounded or unresolved.

10 Conclusion

  • Binding removed every post-approval attack against ASU, while a trusted card reduced forged-narration attack success from 0.54 to 0.03 and raised language-model attack catch rates from 0.30 to 0.98.The second device changed no measured outcome; its value is the separate trust domain and verifiable receipt, which proofs establish but experiments do not test.Source: §10 · p. 28
  • Padding, spoofed labels, and displays that fail to distinguish effects succeeded against real designs; flooding and effects allowed by policy without asking remain open.The paper’s contribution is an attack set, an audit, and measurements of which half of agent MFA existing designs address.Source: §10 · p. 28

Ethics and Availability

The study used local tests against documented intended uses, with placeholder data and mock resources, and did not contact real people or production systems. The authors provide the gateway, models, proofs, audit, probes, harness, results, and figure/table-generation script, with experiment commits identified.

Ethics

  • All attacks ran locally against documented intended uses of open-source code with placeholder data and mock resources; no real service, account, credential, person, or production third-party system was contacted.The study had no human subjects, so it makes no claims about human behavior; model prompts contained no personal data.Source: Ethics and Availability · pp. 28–29
  • The reported third-party findings concern AP2 sample code and integrator documentation, MCP form-mode behavior specified for sensitive interactions, and post-approval substitution in Agno; maintainers were not contacted.The paper describes these as design observations and provides no exploit code for deployed services.Source: Ethics and Availability · p. 29

Availability

  • The gateway, authenticator, Tamarin models, audit, probes, harness, raw results, and figure/table-generation script are available; scripted experiments used commit a0f304a.Language-model approvers used commit f358b1a and the attack matrix used commit 1138121; those trees had uncommitted changes outside the gateway code.Source: Ethics and Availability · p. 29

A Scripted Scenarios

The scripted scenarios pair benign user tasks with additional actions by a compromised agent, with success measured from the resource ledger. The language-model approver materials specify the review prompt and stimuli, and describe the evaluated approver conditions.

A Scripted Scenarios

  • Each scripted scenario keeps the user’s task benign while adding an attack by the compromised agent; success is measured from the resource ledger.A13 reduces each Agents of Chaos case to the shape of the tool calls made by the manipulated agent.Source: A Scripted Scenarios · p. 33, Table 11 · p. 33

C Language-Model Approver Materials

  • The same prompt asks automated reviewers to compare the user’s exact request with one action and approve only actions the user asked for.It requires a JSON decision and a one-sentence reason.Source: C Language-Model Approver Materials · p. 33
  • The trusted card does not protect a narration-trusting approver unless the explanation is removed or not shown.The exact-compare approver is an upper bound, with deterministic cells based on three identical trials.Source: Figure 12 · p. 34, Figure 13 · p. 34
  • The stimuli comprise 23 attacks in eight families and 11 benign near misses, using placeholder hosts, accounts, and bodies.Item order and answer-option order are randomized per model from a fixed seed, while card layout remains fixed as the treatment.Source: Table 13 · p. 35, C Language-Model Approver Materials · p. 35

D Reproducing the Results

The paper’s artifact regenerates its reported numbers and figures from raw results, and provides commands to rerun experiments, formal proofs, and audits.

D Reproducing the Results

  • The figure-generation script reads raw results and writes every figure, generated table, and the macros used for reported numbers.Thus, changing the data changes the paper rather than leaving stale values.Source: D Reproducing the Results · p. 35
  • Four commands rerun the scripted scenarios, AgentDojo replay, fatigue sweep and latency; language-model approvals; all Tamarin lemmas; and both audits.The language-model run requires an OpenRouter key.Source: D Reproducing the Results · p. 36
  • The language-model run caches responses and records provider-returned model identifiers for each call.Reruns therefore pay only for missing calls.Source: D Reproducing the Results · p. 36
Loading 2610.21063v1…