Agent Consent Patterns

View saved version →

---
name: agent-consent-patterns
description: Best practices for designing AI agent consent, permission, and human-in-the-loop UX. Use when building or reviewing ANY surface where an agent asks for access, previews an action, holds standing authority, or reports what it did, such as OAuth/connection screens, tool-approval dialogs, permission settings, autonomy levels, spend caps, activity logs, credential flows. Triggers on "agent permissions", "consent screen", "approval dialog", "human in the loop", "tool approval", "connect integration", "always allow", "autonomy settings".
---

# Agent Consent Patterns

Distilled best practices for consent UX in agentic products, from
[agent-consent-patterns](https://github.com/mrchaarlie/agent-consent-patterns). A taxonomy of
12 named patterns with production React implementations (`@agentconsent/react`). Use this skill
to (a) pick the right pattern for a consent surface, (b) get its non-negotiable rules right, and
(c) avoid the anti-patterns that make consent theater.

## Core principles (apply to every consent surface)

1. **Consent requires legibility.** A user can only consent to what they can understand. Show
   concrete facts (recipient, amount, scope, resource), never categories ("wants to access your
   account"). If you can't explain a permission in plain language, don't ask for it.
2. **Friction proportional to consequence.** Reversible → one click. Undoable → one click plus a
   visible recovery path. Irreversible → enumerated consequences and a deliberate gesture
   (type-to-confirm). Uniform friction trains click-through exactly where it must not.
3. **Declining is always safe.** "No" must never feel destructive or final. Initial focus lands on
   the least-destructive action; Escape routes to the same "no" callback, never an ambiguous
   dismissal that leaves an action half-pending.
4. **Authority is granted over time, not in a moment.** "Always allow" is a standing delegation
   made under task focus. Make duration a first-class, legible choice; default to "just this
   once"; never pre-select or visually favor the standing option.
5. **An agent can never exceed its principal.** Delegation narrows authority, never amplifies it.
   Never offer the agent a capability the user themself doesn't hold (the confused-deputy bound).
6. **Provenance is part of the request.** When an instruction arrived from untrusted content (a
   web page, an email, tool output), say so before asking for approval.
7. **Consent continues after approval.** Every consequential action leaves a receipt; standing
   grants stay visible, with last-used recency, after the consent screen is gone.
8. **Revocation must be real and immediate.** A grant that can't be effectively withdrawn was
   never consent. Pause and revoke live one affordance away from every standing grant.
9. **Authority should expire by default.** Standing is not forever. Prefer session- and
   task-scoped grants; re-surface long-lived ones for reconfirmation.
10. **Minimize what the agent can see.** Least privilege applies to data, not just actions.
    Scope to the narrowest resource (one label, one folder), not the whole account.

## The 12 patterns: pick by situation

**Granting access** (connecting an agent to a service):
- **Scoped Grant**. The connect screen. Per-capability checkboxes tagged read/write/delete (as
  text, never color alone), grouped by resource with the narrowing stated ("'Board 2026' label
  only"). Read is the default; write/delete start unchecked. Required scopes shown locked and
  labeled, never silently bundled. The grant button shows the count it will grant.
- **Progressive Scope**. Escalation mid-task. Ask for exactly one new scope, at the moment the
  agent is blocked, with the reason tied to the blocked action and what it already has. "Just
  this once" is the easy answer; "always" is deliberate. A denial sticks, no nagging.
- **Connection Card**. The settings tile a standing grant lives in afterward. Shows 

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.