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

What it is

A preprint from SportsVision AI (Kodathala, Pollishetty, Cargill), a follow-up to the first author's aiAuthZ gateway work. It gives a testable criterion for when an agent approval prompt counts as a second factor, and it tests deployed designs against that criterion. The authors say the primitives are not new. Microsoft's ADR 0030 and SUDP already bind a canonical operation digest to a fresh approval. The contribution is the attack catalogue and the measurements.

How it works

The criterion: an approval protects an action only if compromising the agent cannot produce it, and only if it commits to exactly the action that executes. It is split into seven properties you can check your own design against:

• P1 agent independence: nothing the agent controls can read, forge, answer, overlay or replay the approval.
• P2 effect binding: the executed call's digest equals the signed digest.
• P3 freshness and single use: a nonce and an expiry, consumed atomically.
• P4 trusted rendering: the card is built from the canonical effect by trusted code. Agent text appears only in a region labeled as untrusted, and distinct effects render as distinct cards.
• P5 non-repudiation: a third party holding only the user's public key can verify the signature.
• P6 scope integrity: a delegated grant covers only the arguments the user approved.
• P7 flood resistance: rate limits, caps on pending approvals, lockout after repeated denials, and merging of duplicates.

The paper separates three patterns:

• In-channel "reply yes" confirmation fails P1, because the agent can write to that channel.
• An out-of-band card whose text the agent narrates moves the click off-host, but the user approves a description rather than the call.
• Effect-bound approval is the reference design, ASU. A gateway the agent cannot reach canonicalizes the call (JCS, SHA-256), renders the card from it, has a WebAuthn passkey sign a challenge committing to the digest, and executes only the stored descriptor once.

Preconditions / Affected

• The audit covers ten agent runtimes. By the authors' reading of their APIs, none produces a third-party verifiable approval record.
• None of the seven runtimes where flooding could be measured limits approval floods within a run.
• In four of the eight runtimes where binding could be measured, a resumer, hook or stored history can change what executes after approval.
• A version sweep found that post-approval substitution in one framework persists past its published affected range. The page text provided does not name the framework.
• A passkey or TOTP secret on the agent's own host gives no independence, because it is inside the agent's reach.

What to do

• Render approval cards from the structured call, not from agent text.
• Sign a digest of the exact arguments, and execute the stored call rather than whatever the agent resubmits after approval.
• Make approvals single-use with an expiry.
• Cap pending approvals per session and per user, and lock out repeated denials.
• If you use an LLM approver, give it a trusted card. Across 15 models, the catch rate rose from 0.30 to 0.98.
• The authors released code, data and Tamarin proofs at https://github.com/Sports-Vision-Inc/agent-step-up.

Caveats

• No human data. Every approver is a simulated person or a language model, so the paper makes no claim about how often real people catch attacks.
• False refusals. The trusted card refused 16% of harmless near misses, mostly because of a placeholder artifact in the authors' stimuli.
• Flooding. It still succeeded against ASU 0.45 to 0.60 of the time with a modeled human approver.
• Second device. It added nothing measurable over a trusted on-host confirmation in these experiments.
• Policy-allowed effects. Approval cannot stop effects that policy already allows, and a human can still approve a harmful action that is displayed truthfully.
• Consent claim. The Tamarin proofs rest on three stated hypotheses. The claim that the user saw the effect holds only if the rendering origin is honest (H3). A passkey signs the challenge but does not display it, so what the user sees is whatever the page shows.