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 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.
Explore the model
Visit Agent Consent Flow to explore the hosted private beta and read the integration guide. For the protocol itself, start with AIP Consent.