Consent
See and Control What Your Agent Can Touch
Per-prompt "allow this?" dialogs train the reflex click and leave no record of what the agent can reach. Where a knowledge-source toggle scopes a single query, this is the durable layer above it: one surface listing every app the agent can touch right now — with scope, grantor, and expiry — where any grant can be inspected, narrowed, extended, or revoked inline.
Framing
The problem
An agent reaching across many apps on the user's behalf accumulates access no one can see, because per-prompt dialogs leave no durable record of what it can touch.
The pattern
Render every grant on one inspectable surface — which app, what scope, granted by whom, expiring when — sitting above the per-query toggle, and let the user narrow, extend, or revoke any of it inline.
Why chat breaks here
Permissions approved in chat die with the session and cannot be seen, audited, or revoked later, so the agent's reach only ever grows.
Risks
Without a review cadence the surface still drifts — grants accumulate, scopes broaden, and a permission list no one revisits becomes its own blind spot.
Avoid when
The agent reaches a single trusted system within one fixed scope, where a standing permission surface adds chrome with nothing to control.
Use when
A standing, revocable map of what the agent can reach beats a stream of one-off "allow this?" prompts that vanish the moment they are clicked.
DOPE evaluation
- Directability
- Revoke, narrow, extend, or re-bind any grant at any time
- Observability
- Every active permission is visible on a single surface with scope, grantor, expiry
- Predictability
- Scope and expiry are explicit — there is no implicit grant the user has not seen
- Explainability
- Each permission lists exactly what data and actions it covers, in plain language
In the wild
- Auth0 · Fine-Grained Authorization (Okta) — Relationship-based access control aimed at AI agents: durable grants with explicit scope, expiry, and inspectable history. Permissions as inspectable artifacts, not modal choices.
- Google Workspace · third-party app access (Google) — Per-app, per-scope, per-user permission panels in the Admin console. Revocation propagates immediately; expiry policies and review prompts at the workspace level.
- OpenAI ChatGPT · Connectors (OpenAI) — Settings → Connectors lists every linked service with the scopes granted and a per-connector revoke. The cleanest consumer-facing implementation of "every grant is visible on one surface."
- Anthropic Claude · MCP server consent (Anthropic) — Each MCP server connection is a durable grant with a visible scope description; tool calls show the granting server inline. Mid-maturity — UI varies across surfaces (desktop, Claude Code) and the org-wide audit view is not yet unified.
FAQ
When should I use the Consent pattern?
A standing, revocable map of what the agent can reach beats a stream of one-off "allow this?" prompts that vanish the moment they are clicked.
When should I avoid the Consent pattern?
The agent reaches a single trusted system within one fixed scope, where a standing permission surface adds chrome with nothing to control.
What problem does Consent solve?
An agent reaching across many apps on the user's behalf accumulates access no one can see, because per-prompt dialogs leave no durable record of what it can touch.
Why is chat the wrong fit for this?
Permissions approved in chat die with the session and cannot be seen, audited, or revoked later, so the agent's reach only ever grows.
Related patterns
- Extends: Knowledge Source Toggle — Source toggles scope one query; Consent is the durable permission layer above that — multi-session, revocable.
- Often paired with: Autonomy Dial — Autonomy declares how much the agent may do; Consent declares to which systems and for how long.
- Often paired with: Data Ownership — Inventory shows what data is held; Consent shows the permissions that let it stay there.