The Authentication and Authorization Challenges of Agentic AI
For twenty years, identity and access management has been built around two actors. A human, authenticated through something like OpenID Connect, sitting behind a browser and a session. And a machine — a backend service, a batch job, a cron script — authenticated through a client credentials grant, holding a static set of permissions it never has to explain itself out of.
Agentic AI doesn’t fit into either box, and pretending it does is where most of the current security problems come from.
An agent can act autonomously, with no human anywhere in the loop. It can act as a delegate, carrying out a task on behalf of a specific person, with that person’s authority but not their literal session. And it can act as a link in a chain — calling a tool, which calls another service, which hands off to another agent — sometimes all three of these things within a single user request. None of that maps cleanly onto “human” or “machine.” It’s a third category, and the identity infrastructure most teams are running today was never built to model it.
This post is the map for the rest of the series. Each section below names one place where the two-actor model breaks, and points to the post that goes deep on it.
What actually changes versus traditional application auth
Before getting into the specific gaps, it’s worth being precise about what’s genuinely new here, because a lot of “AI agent security” content overstates the novelty. The underlying protocols — OAuth 2.0, OpenID Connect, JSON Web Tokens — are not being replaced. What’s changing is the shape of the problems you’re asking them to solve:
Standing versus task-scoped permission. A logged-in human session typically carries a broad, relatively static set of permissions for the duration of that session. An agent acting on a task should ideally hold only the narrow slice of permission needed for that specific task, for as short a time as possible, and nothing more once the task ends. Most existing systems have no concept of a permission that’s this short-lived or this narrow by default.
Asynchronous, long-running action versus synchronous request/response. A browser-based OAuth flow assumes a human is present, at a screen, right now, to click “allow.” An agent might decide three steps into a workflow that it needs elevated permission for an action — and the human it needs approval from may not be looking at anything at that moment.
Chains of delegation versus a single hop. Classic delegated access is one hop: app A acts for user U against API B. Agentic systems routinely have multiple hops — an agent calls a tool, which is itself backed by another service, which may call a second agent. Each hop needs to preserve whose authority is actually being exercised, or you lose the ability to answer “why was this allowed” a few hops in.
Attribution. When something goes wrong, “who did this” now has at least three possible answers: the human who initiated it, the agent that executed it, and the specific grant of authority under which it acted. Conflating any two of these is how audit trails become useless exactly when you need them most.
The seven gaps
Everything in this series maps back to one of these seven places where the two-actor model runs out of road.
The identity gap. Is the agent its own principal — a distinct, identifiable entity with its own credentials and audit trail — or is it just borrowing a human’s session or a generic service account’s static permissions? Both of the easy answers (treat it as the user, or treat it as any other backend service) lose something important: either least-privilege scoping or clean attribution. → Agent Identity: Why Your AI Agent Needs to Be a First-Class Principal
The delegation gap. Once an agent is a distinct principal, how does it prove — to a resource server that has never seen it before — that it’s acting for a specific user, with a specific scope, and not simply presenting a stolen or overly broad credential? This is a solved problem in principle (token exchange patterns exist for exactly this) and a frequently botched one in practice. → Delegation Done Right: Token Exchange and the On-Behalf-Of Pattern
The consent gap. Some actions are sensitive enough that a human should approve them specifically, but agents often act at moments when no human is watching a screen. The naive fix — a broad, one-time “allow this agent to do things” checkbox — trains people to click yes and defeats the purpose. → Human-in-the-Loop, Automated: Asynchronous Authorization for High-Stakes Agent Actions
The trust-chain gap. Per-application OAuth consent screens work when a human is present to grant each connection individually. They stop scaling the moment agents start reaching into other applications, or other agents, on an enterprise’s behalf — you end up needing the identity provider to mediate that trust the same way it already mediates single sign-on. → Beyond the Consent Screen: Agent-to-Agent and Agent-to-App Trust
The tool-surface gap. Handing an agent a tool is functionally the same as standing up a new API client — with all the authentication and authorization obligations that implies. A large fraction of early agent deployments skip this step entirely, on the theory that “it’s just a tool call.” It isn’t just a tool call; it’s a new entry point. → Securing the New Attack Surface: Authorization for Tool-Calling Agents and MCP
The data-scoping gap. Scopes and roles answer “can this agent call this API.” They don’t answer “can this agent retrieve this specific record, for this specific user, right now.” That second question is exactly the one that matters for retrieval-augmented generation, where the wrong document silently becomes part of a model’s answer. → Least Privilege at the Data Layer: Relationship-Based Authorization for RAG
The governance gap. After all six of the above are handled correctly in the moment, there’s still the question of afterward: can you audit what happened, revoke a grant instantly and have that revocation actually take effect, and prove — not just assert — what a human actually authorized versus what the agent executed on their behalf? → Governing Autonomous Systems: Auditability, Non-Repudiation, and Revocation
The diagram below is the visual spine for the series: three actors (human, agent, resource), plus the fourth node — another app or agent — that shows up once delegation chains get longer. Each arrow is annotated with the gap numbers that apply to it. We’ll reuse and crop this same diagram across the individual posts so the series reads as one coherent architecture rather than seven disconnected essays.
Where the standards actually stand today
It matters to be honest about maturity here, because a series like this ages badly if it overstates how settled things are.
OAuth 2.1 and OpenID Connect remain the substrate for everything discussed in this series — nothing here proposes replacing them. Several of the extensions that make agent delegation work are mature and already shipping in production systems: token exchange patterns for on-behalf-of access, Client-Initiated Backchannel Authentication for asynchronous approval, and Rich Authorization Requests for carrying structured, specific permission requests instead of flat scope strings.
At least one piece that’s central to the agent-to-agent trust-chain gap — the identity assertion grant that extends single sign-on trust to API access — is, as of this writing, still an active IETF draft rather than a ratified RFC. Multiple vendors are already implementing against it, which is a reasonable bet on where the standard is heading, but it hasn’t finished standardizing. We’ll flag this specifically in the post where it’s relevant, and we’ll revisit this series as the draft progresses.
How to use this series
This isn’t a checklist where you’re meant to implement all seven patterns on day one, for every agent you ship. Which gaps actually matter to you depends heavily on what kind of agent you’re building:
- Building a customer-facing assistant that calls a couple of first-party APIs on a logged-in user’s behalf? Start with the delegation post and the tool-surface post.
- Building a fully autonomous background agent with no user in the loop at all? Start with the identity post — you need to decide what kind of principal it is before anything else makes sense.
- Building a multi-agent workflow that spans several internal or partner systems? Start with the trust-chain post; that’s where most of the actual incidents in this category originate.
- Building anything that touches a retrieval pipeline over documents with mixed access levels? Start with the data-scoping post — this is the gap most commonly discovered after a leak, not before.
Wherever you start, the governance post is worth reading regardless of which agent you’re building. It’s the one that determines whether, six months from now, you can actually answer “what happened and why” when someone asks.
Closing
None of this requires inventing new security theater for AI specifically. It requires taking identity and access management discipline that’s decades old — least privilege, explicit and provable delegation, auditability — and applying it to a shape of system that genuinely didn’t exist five years ago. The protocols mostly already exist. The gap is in recognizing where the old assumptions quietly stop holding, and that’s what the rest of this series works through, one gap at a time.