Agent infrastructure
Platform integration
AI agent authentication needs delegated identity at the tool call, not shared service accounts. Where legacy models break and what actually holds in production.
How should an AI agent authenticate to the systems it acts on? The question sounds like it has an obvious answer — reuse OAuth, hand out API keys, mint service accounts — but every one of those answers breaks in a specific way once agents are the caller. Agents run without a human present at the moment of the call. They act on behalf of users, but they aren't users. They chain tool calls in ways that expose every weakness in your token model. And they get audited by security teams who want to know exactly which human was accountable for each write.
Pontil's view: AI agent authentication is a runtime problem, not a credential-choice problem. The pattern that holds is delegated identity, executed per tool call, tied to the authenticated user, with short-lived credentials and full audit context. Everything else is a shortcut that fails review.
This piece walks through the five things that matter: why the old models break, what delegated agent access actually looks like, how user-scoped agent identity holds under load, where OAuth 2.1 and token exchange fit, and what changes when you push the boundary down to the tool call.
Three patterns dominate legacy API authentication: static API keys, service accounts, and interactive OAuth. Each was designed for a caller that doesn't match how agents behave.
Static API keys assume a small number of long-lived callers with predictable behaviour. An agent isn't that. It fans out across tools, invokes writes on behalf of many different users, and often runs in shared infrastructure. A leaked key is a full-tenant compromise with no way to answer "which user did this action belong to?" — the key doesn't carry that identity. Rotation helps but doesn't fix the underlying problem: one credential, many humans behind the calls.
Service accounts fail the same audit test in a more elegant way. A single shared identity acts on behalf of every user the agent serves. Logs show the service account did it. The permission set is the union of everything any user might need, which means every call runs with the maximum blast radius. This is what most early agent projects ship with. It's also what most security reviews block before the second sprint. We've written about this trade-off directly in zero trust for AI agents: the shared service account is the exact model zero trust exists to reject.
Interactive OAuth — the standard three-legged flow where a user clicks through a consent screen — assumes the user is at a keyboard when the token is issued. Agents call tools minutes, hours, or days after that consent. The flow still works as an initial grant, but the runtime pattern is different: you need a token valid at execution time, scoped to the specific action, tied to the specific user. That means refresh flows, token exchange, and short-lived credentials — not a one-time authorisation.
The common thread: none of these models make the identity boundary hold at the tool call. And the tool call is where the actual write happens.
Delegated access is the pattern where the agent acts on behalf of a specific authenticated user, holding a credential that carries that user's identity into every downstream system. The credential isn't the agent's — it's derived from the user's session, scoped down to what the agent is allowed to do on the user's behalf, and short-lived enough that a leak has a small blast radius.
The practical shape: a user authenticates once (usually through OAuth 2.1 with PKCE), the platform holds a refresh token in a secure vault, and at tool-call time the runtime exchanges that refresh token for a short-lived access token scoped to the specific tool. The tool executes with that token. The downstream system sees the user's identity, applies the user's permissions, and writes an audit record naming the user. The agent is present in the log too — usually as an actor or client attribute — but the accountable identity is the human.
This matters for four concrete reasons.
Permissions honour the real user. If a user can't delete records through the UI, the agent acting for that user can't delete records through the tool. The permission check runs at the same layer it always did.
Audit trails answer the right question. "Who changed this?" resolves to a human, not a service account. Compliance teams can trace every write back to the user who authorised the agent to act.
Data visibility is scoped correctly. Multi-tenant systems already enforce visibility per user. Delegated tokens plug into that model. Service accounts routinely see across tenants — and routinely leak across them.
Consent is revocable and specific. Users can revoke the agent's access without breaking their own account. Admins can scope what the agent is allowed to do, per user or per role.
We've walked through the mechanics of this pattern step by step in OAuth for AI agents — the setup guide covers PKCE, scope design, token refresh, and the audit trail security review will ask for.
Delegated access is the model. User-scoped identity at runtime is the enforcement. They're not the same thing. Plenty of teams design a delegated model on the whiteboard and then, at execution time, resolve everything to a shared token because the runtime doesn't carry per-user context through the call graph.
A user-scoped runtime has to do three things.
First, it has to hold the user context from the moment the agent starts working on a task. That means the invocation carries a user identifier — an authenticated principal, not a header the caller sets — and the runtime refuses to execute tools without one. If your runtime lets tools run without a bound user, you don't have user-scoped identity. You have a service account with extra steps.
Second, it has to issue credentials per call, not per session. A session-long token is a session-long blast radius. The pattern that holds is a just-in-time token: short-lived, narrowly scoped to the tool being called, minted at the moment of the call and destroyed after. We covered the mechanics — token exchange, DPoP, per-call authorisation — in just-in-time tokens for AI agents.
Third, it has to propagate the identity through to the downstream system in a form the system recognises. This is where most implementations fall over. Your tool runtime knows who the user is. Your downstream API expects a bearer token in a specific format, from a specific issuer, with specific claims. Bridging the two is OAuth 2.0 Token Exchange territory — RFC 8693 — and getting it right requires either a compatible identity provider or a purpose-built runtime that handles the exchange.
The trade-off is real. Per-call token minting has a latency cost. Token exchange adds a round trip. Caching helps but has to be scoped tightly (per user, per tool, per short window) or you re-create the sharing problem you're trying to solve. Teams that get this right usually accept an overhead in the tens of milliseconds per call as the price of an audit trail that survives review. Teams that don't usually ship a service account and hope the security team doesn't notice.
OAuth 2.1 (currently an IETF draft that has already been widely adopted in practice) is the consolidation of the OAuth landscape into a smaller, tighter surface: PKCE is mandatory, implicit and password grants are removed, and refresh tokens for public clients have to be rotated or sender-constrained (confidential clients face a softer requirement). For agent authentication, this is a good baseline. It's also what the Model Context Protocol specification points at for MCP server authentication.
The useful shape of OAuth 2.1 for agents:
What OAuth 2.1 doesn't solve: the runtime problem. The spec gives you a way to get a token. It doesn't tell you how to bind that token to a specific tool call, how to exchange it for a downstream credential, or how to make sure the audit trail names the right human. Those are runtime concerns, and they sit above the protocol.
MCP forces the question because MCP servers are, by design, called by many clients on behalf of many users. If an MCP server accepts a static token, you're back to the shared-account problem — the server can't tell which user the current call belongs to. If it accepts a delegated token per call, you need a runtime that can produce one. Most teams discover this the second week of building an MCP server. We wrote up what OAuth 2.1 actually requires for MCP in MCP server authentication — the failure modes production teams miss are almost all runtime failures, not spec failures.
The honest reading: OAuth 2.1 is necessary and not sufficient. It's the protocol you build on. The identity boundary lives above it.
Most API authentication has been designed around sessions. A user logs in, gets a session token, and every request in that session carries the same identity with the same permissions. It works because humans make one request at a time and the session is roughly the scope of one intent.
Agents break this model. A single agent turn can invoke ten tools. Each tool might touch a different system with different permissions and different audit requirements. Some tools should require step-up authentication — deleting records, moving money, publishing content — even if the session is authenticated for read-only work. Some should be blocked entirely for certain users. The session-level identity check happens once at the start and never again.
The pattern that holds is enforcement per tool call. Every invocation carries the user identity, resolves the specific permission for the specific action, and produces an audit record. This looks like more work — because it is — but it's the only pattern that survives security review for agents doing production writes. We laid out the runtime shape in least privilege for AI agents: least privilege is a runtime boundary, not a policy document, and it lives at the tool call.
The trade-offs are real and worth naming:
The alternative — one shared token per agent, session-long — is faster to build and impossible to defend in an audit. The teams shipping production agents on established SaaS platforms have almost all reached the same conclusion: the identity boundary has to hold at the tool call, or it doesn't hold anywhere.
Pontil is a Tools-as-a-Service platform. We generate tools for AI agents from the APIs SaaS companies already have, and we run those tools in a managed runtime. Authentication is one of the specific reasons the runtime exists.
The Pontil runtime executes tool calls as the authenticated user, not a shared service account. User identity is bound at invocation, credentials are issued per call and short-lived, and the downstream system sees the real human on every write. That means permissions honour what the user is actually allowed to do, audit trails resolve to a human, and data visibility follows the multi-tenant boundaries the product already enforces.
This matters for teams building agents on their own established platforms, where the security review is going to ask exactly the questions this article walks through. If you want to see how the runtime handles delegated identity end-to-end, book a walkthrough.
The useful frame is this: authentication for agents isn't about picking the right credential type. It's about deciding where the identity boundary lives. If the boundary is at the session, agents will chain tool calls through it and every audit will resolve to a service account. If the boundary is at the tool call, with a delegated identity and a short-lived credential, the model holds under load and survives review.
That's a bigger change than it looks. Session-level auth was the default for two decades because humans behave in sessions. Agents don't. They behave in call graphs, on behalf of users who aren't in the room, across tools that were built for different threat models. The old boundary was designed for the old caller.
The teams doing this well right now aren't reinventing OAuth. They're taking OAuth 2.1, adding token exchange, and building a runtime that pushes the identity down to the tool call. The credentials are short-lived. The permissions are per-user. The audit trail names a human. It's more work than a service account. It's the only pattern that answers the questions a security team is going to ask.
What's the right question to ask about your own setup? Not "which auth method are we using?" — that's the shortcut. The right question is: at the moment a tool executes, whose identity is on the call, and can the downstream system prove it?
Stay up to date on the ever changing agentic landscape.
GET STARTED
Start with a 30-minute discovery call
contactus@pontil.com
