Index
Patterns
Twelve ways, four piles. Each names a trouble that keeps coming back, and shows the fix: the parts, when to use it, screen reader talk, wrong turns, code.Twelve patterns across four categories. Each pattern names a recurring problem in agent consent design and documents a solution: anatomy, when to use it, accessibility behavior, anti-patterns, and code.Twelve patterns across four categories: granting access, approving actions, standing authority, trust & transparency. Each names a recurring problem in agent consent design and documents its resolution: anatomy, applicability conditions, accessibility semantics, anti-patterns, and a reference implementation.
Granting access
- 01live
Scoped Grant
One "allow" button can mean read one letter, or burn the whole mail pile. Same button. Use small keys instead.OAuth-era scope screens don't show what an agent can actually do with access. Reading a single message and exporting an entire inbox look the same on the consent screen.OAuth's opaque scope strings collapse capability granularity to a single bit. The consent screen has to decompose grants along access-level and resource axes, or it forces over-provisioning by construction.
- 02live
Progressive Scope
Don't hand over every key on day one. Give the small key first. Let it ask for the next one only when it hits a locked door.Asking for every permission upfront forces users to consent to hypotheticals. Agents should start minimal and ask for more only when the task needs it.Upfront permission maximalism elicits consent with zero task context. Deferring capability acquisition to the moment of demonstrated need keeps the authority curve tied to earned trust.
- 03live
Connection Card
Keys you hand over go invisible. Show what the machine still holds, when it last used it, and how to take it back.Once granted, connections become invisible. Users need a surface that shows the current grant state, when it was last used, and a way to revoke it.Consent decays while authority persists. Standing grants need a present-tense representation (capability state, lifecycle status, recency, reversal) to remain governable.
Approving actions
- 04live
Action Preview
"Machine wants to send a letter" isn't enough. Show who it goes to, what it says, and what it costs, before it flies."The agent wants to send an email" isn't enough to approve. Users need to see the exact action: the recipient, the content, and the amount, before it runs.Generic confirmations collect assent over a category while the agent executes a token. Review has to render the verbatim parameters, since they are model inferences that no human ever typed.
- 05live
Irreversibility Gate
Same fence for every act teaches hands to hop it without looking. Small acts get a small door. Forever-acts get a heavy one, with spoken words.Uniform confirmation friction trains users to click through. Weight the gate to the consequence instead.Uniform confirmation is a zero-variance signal that trains click-through. Confirmation cost has to scale with recovery cost, up to typed commitment for what can't be undone.
- 06live
Batch Approval
Judging a pile piece by piece numbs the hand. Wave the safe pieces through together. Pull the risky one out alone.Reviewing agent work item by item causes approval fatigue. Queues need a way to triage without collapsing into rubber-stamping.Serial modals amortize scrutiny to zero, and blanket approval deletes it outright. Queues need bulk triage over the routine partition, with flagged items structurally excluded from every group operation.
Standing authority
- 07live
Consent Memory
"Always allow" is the button tired hands press to kill the box forever. Ask how long, separately, and show the price."Always allow" is a standing grant made in a moment of task focus. Each memory option needs consequences the user can actually read.The in-task prompt makes maximal authority transfer the path of least friction. Durability needs to be its own consequence-labeled choice, with the ephemeral option as the default.
- 08live
Authority Boundary
Little yeses pile up until nobody knows what the machine can do alone. One list should rank every ability: on its own, ask first, or never.Users need one settings surface that answers: what may this agent ever do on its own, and what must it always ask about?Standing authority accretes without aggregation, so the effective policy becomes unstatable. It needs one editable surface that maps every capability to an explicit autonomy level.
- 09live
Spend & Rate Limits
"Spend $100 a week, then come back" is the leash, not a bill-setting. Show the cap next to what's already spent.Numeric guardrails (budget caps, action counts, time windows) are consent primitives, not billing features.Quantitative guardrails are consent primitives, not billing configuration. They should be metered against live usage, editable in place, and treat cap-reached as a re-consent event that fails closed.
Trust & transparency
- 10live
Injection Flag
Strangers hide orders inside pages the machine reads. It must stop, hold up the exact words, say where they came from, and ask you.When instructions arrive from untrusted content, the agent must show users where the instruction came from and ask whether to proceed.Data-channel imperatives exploit the model's undifferentiated token stream; unresolvable in principle, they must surface as provenance-labeled, verbatim-quoted consent events with non-compliance resting.
- 11live
Action Receipt
After the machine acts, it leaves a mark: what it did, who said it could, when, with an undo-rope where the act can still be pulled back.Consent doesn't end at approval; users need a post-hoc record of what the agent did, under what authority, with undo where possible.Ex-ante consent is open-loop for standing grants; each exercise needs a durable record binding effect to authorizing grant, with reversal offered exactly where honorable.
- 12live
Credential Handoff
The machine must never touch your password or money-card. It steps aside; a trusted keeper takes the secret; the machine gets one small key back.Agents should never see passwords or payment details; sign-in and payment delegate to a password manager or scoped token flow.Agents are the system's maximum-exposure component; credential exchanges must exclude them structurally, routing to trusted custodians and returning only scoped, expiring derived instruments.