--- title: "What OAuth can teach us about consent for AI agents" description: "OAuth offers useful lessons for AI-agent access: declared scope, explicit approval, bounded grants, and independent revocation. Learn how Agent Consent Flow relates to AIP." url: "https://gazebohq.com/blog/oauth-consent-screen-for-ai-agents" --- Someone sends you an agent they built. To run it against your systems, its instructions ask for a Stripe key, a GitHub token, or another long-lived credential. That familiar setup problem is bigger than configuration. A raw credential rarely communicates the exact operations an agent needs, gives the user little opportunity to limit that access, and makes revocation mean rotating a key that may be used elsewhere. It is a useful comparison point for the problem OAuth was created to address on the web. --- ## OAuth solved this problem for web apps Before OAuth, if you wanted an app to access your data, you handed over your password. The app could do anything your account allowed. There was no scope, no consent moment, no way to revoke access without changing your credentials. OAuth changed the model with one insight: **access should be declared, explicit, and user-controlled**. The consent screen — that familiar list of permissions, the Approve button — wasn't just a UX decision. It was an architectural one. The app declares upfront what it needs. The user grants access from their own account. The app author never touches the user's password. And the user can revoke anytime, independently. The web scaled because of this trust model. Thousands of third-party apps connect to Google, GitHub, Stripe, and Slack — and users let them, because the consent screen makes the access visible and bounded. Agents need the same thing. --- ## What OAuth teaches us An AI agent is not an OAuth client simply because it uses an API. But both can need access to specific services and operations on a user's behalf. That makes OAuth's design lessons relevant: - **Declare the request before access is granted.** A user should be able to inspect what the agent is asking for. - **Make approval explicit.** Consent is a decision, not an implication of copying a value into a configuration file. - **Issue bounded access.** The grant should be limited to the approved scope rather than the full power of an underlying credential. - **Keep revocation independent.** A user needs a way to withdraw a grant without relying on the agent developer. These principles do not eliminate the need to evaluate an agent's code, its provider, or the service that ultimately authorizes access. They do create a clearer security boundary than a copy-and-paste secret. --- ## Consent for agents needs a clear boundary An agent consent experience should make the requested scope understandable before a user authenticates or approves. In a well-designed implementation, a person can see the agent's identity, purpose, requested services, and requested operations—and can decline without creating a grant. After approval, the authorization system should validate that the approved scope is no broader than the request, record the decision, and issue only the resulting scoped grant. Later scope expansion should require another consent decision. This is an architectural model, not a substitute for the security work behind it. A trustworthy implementation also requires server-side validation, authenticated approval, secure grant issuance, audit handling, and revocation. A browser screen must never mint a trusted grant or receive an underlying service credential. ## Agent Consent Flow is in private beta Agent Consent Flow is a **hosted private beta** around the independently conformable [AIP Consent](/spec/consent) section. It applies OAuth-inspired consent lessons to agents without asking users to paste raw secrets into an application's settings. Registered clients use signed authorization requests, exact callback allowlists, S256 PKCE, one-time codes, short-lived tokens, introspection, and immediate revocation. It is not an agent-publishing feature or a claim of OAuth compatibility. The TypeScript SDK source ships with the beta but is not yet published to a public package registry. --- ## AIP remains the standard The **Agent Identity Protocol (AIP)** remains unchanged. Its Consent section defines normative requirements that can be implemented independently; conforming to AIP does not require using Agent Consent Flow. Agent Consent Flow is one implementation around that section, not a replacement for or extension of the protocol. Keeping the standard separate from an implementation helps developers choose their own architecture while preserving a common set of consent requirements. Read the normative requirements at [AIP Consent](/spec/consent). --- ## Explore the model Visit [Agent Consent Flow](/consent) to explore the hosted private beta and read the [integration guide](/docs/consent). For the protocol itself, start with [AIP Consent](/spec/consent). ## Frequently asked questions **Q: What is the Agent Identity Protocol (AIP)?** AIP is an open standard for AI agent identity and consent requirements. Its Consent section is independently conformable: an implementation can follow it without using Agent Consent Flow. AIP remains unchanged as Agent Consent Flow is developed around it. **Q: What is Agent Consent Flow?** Agent Consent Flow is a hosted private beta around the independently conformable AIP Consent section. It provides signed requests, authenticated approval, scoped grants, short-lived tokens, introspection, and revocation. It is not an OAuth-compatible protocol or an agent-publishing feature. **Q: What should an AI-agent consent flow include?** A secure design should let users inspect an agent's identity, purpose, and requested scope before approval; validate the approved scope server-side; issue a bounded grant without exposing an underlying credential; record access; and support independent revocation. **Q: Does OAuth solve every AI-agent security problem?** No. OAuth-inspired consent helps make delegated access explicit and bounded, but users and developers still need to evaluate the agent, its code, its provider, the authorization system, and the services it can reach. Scope expansion should require a new consent decision.