Overview
How might we design revocation affordances so people can trust and act on AI output?
When this pattern fits
- Essential for OAuth-based agents, connector marketplaces, and enterprise assistants where users must routinely review and withdraw access without friction.
When to skip or lighten it
- One-shot local demos with no persistent grants.
- Permissions that are legally non-revocable mid-contract (explain that constraint instead).
- Read-only public data where there is nothing privileged to revoke.
States
State model coming soon
Key UX elements
Key UX elements coming soon
Anti-patterns to avoid
Connect buttons with revoke only in a distant account console.
Revoke that fails silently while the agent keeps working.
Bundled revoke-all with no per-connector control.
Hiding revoke behind support tickets.
How products use it
| Product | Implementation |
|---|---|
| Google Account | Third-party access list with per-app Remove. |
| Slack | App management with uninstall and token revoke. |
| GitHub | One-click revoke for PATs and OAuth apps. |
| ChatGPT | Connected apps and connectors with disconnect controls. |
Implementation
Copy this prompt to generate a production-ready implementation in Cursor, Claude Code, Lovable, or any AI coding agent.
Generate a production-ready implementation of the "Revocation Affordances" AI interface design pattern.
Pattern Definition:Frequently asked questions
What are revocation affordances?
They are obvious UI controls that let users withdraw previously granted agent or app permissions, ideally beside the original grant.
Where should revoke live?
Next to the connector chip, in the permission receipt, and again in account settings. Dual placement beats settings-only.
What happens after revoke?
Stop new tool calls immediately, show confirmation, and list what still needs manual cleanup (cached files, scheduled jobs).
How does this relate to granular consent?
Granular consent decides what is granted. Revocation decides how easily it can be taken back. Ship both.