Agent infrastructure
Platform integration
Agent authentication methods compared: API keys, OAuth 2.1 with delegated access, and service accounts. When each wins, where each fails security review.
If your agent project is past the prototype stage, authentication is probably the thing slowing the next ship date. The model works. The tool calls work in dev. Then security review asks who the agent is acting as, what it can see, and how you'd revoke access for one user at 3am — and the answers go quiet.
This comparison is for the engineers and Heads of AI choosing between three real options: static API keys, OAuth 2.1 with delegated access, and service-account or machine-to-machine credentials. They look interchangeable on a slide. They are not interchangeable in production. The short version: API keys win for internal, single-tenant prototypes; OAuth 2.1 wins for any agent acting on behalf of a real user; service accounts win for backend agents doing work that genuinely isn't tied to a person. Most teams pick the wrong one first and find out during their first audit.
An API key is a long random string the client sends on every request, usually in an Authorization: Bearer … header or an X-API-Key header. The server looks the key up, finds the account it belongs to, and runs the request with that account's permissions. That's the whole protocol.
The appeal is obvious. No redirect dance, no token refresh, no discovery endpoint. You generate a key in a dashboard, paste it into an environment variable, and you're calling the API ten minutes later. For internal tools, CI jobs, and single-tenant prototypes, this is fine and arguably correct — you don't need delegation if there's no user to delegate from.
The problem is what an API key represents. It's a single credential with a fixed permission set, usually scoped to an account rather than a user. When an agent acts using that key, every action looks identical in the audit log. You cannot tell which end-user triggered the work, you cannot enforce that user's row-level permissions, and you cannot revoke access for one person without rotating the key for everyone using it. Key rotation itself is a project — keys tend to spread into config files, secrets managers, and the occasional Slack DM, and finding every copy is rarely clean.
OAuth 2.1 is the consolidated version of the OAuth 2.0 family of specs, currently in late-stage draft at the IETF OAuth working group. It folds in the security best-current-practices that accumulated over a decade — PKCE is mandatory, the implicit flow is gone, refresh tokens have rotation requirements, and redirect URIs must match exactly. For agents, the relevant flow is the authorisation code grant with PKCE, run on behalf of a real user.
The shape: the user authenticates with the resource server (your SaaS product, Google Workspace, Salesforce, whatever the agent needs to reach). The authorisation server issues an access token scoped to that user, with the specific permissions the user consented to. The agent makes API calls with that token. The resource server validates the token, identifies the user, and applies that user's permissions to the request. Every action in the audit log is attributable to a named human.
This is what "delegated agent access" actually means: the agent is not the principal. The user is. The agent is acting under the user's identity, scoped to what the user explicitly allowed. Token refresh, revocation, scope changes, and audit trails all hang off the user record, not the agent. If a user leaves the company, you disable their account and every agent acting on their behalf loses access in the same revocation. We covered the implementation details in OAuth for AI agents: a practical setup guide — this piece is about choosing between methods, not building one.
The cost is real. You need an authorisation server (or to integrate with the resource server's), you need to handle PKCE correctly, you need a place to store refresh tokens, and you need to think about what happens when a token expires mid-tool-call. None of this is exotic in 2026, but it's not the ten-minute setup that API keys are.
API keys are the right answer in three situations. First: internal prototypes where there is no real user yet, the agent is calling a system you fully own, and the threat model is a developer laptop. Don't over-engineer; ship the prototype. Second: CI and backend jobs where the work is genuinely application-scoped — nightly reports, data sync, scheduled cleanup — and there is no human in the loop whose permissions should constrain the action. Third: integrations with vendors that simply do not offer OAuth. You inherit their auth model whether you like it or not.
What changes the answer: the moment a real user's data is involved, the moment a security review is on the calendar, or the moment you have more than one customer using the same agent. API keys make all three of those harder, not easier.
OAuth 2.1 with delegated access is the right answer whenever an agent is doing work that a specific user would otherwise do themselves. Customer-facing agents in a multi-tenant SaaS product. Internal copilots that read from systems with row-level permissions. Anything that touches a CRM, a calendar, a document store, or a ticketing system where "who did this" matters.
It is also the right answer when your security review wants to see per-user audit logs, when compliance requires that a deprovisioned user loses access to all systems immediately, and when you need to honour scopes that the user themselves can see and revoke. These are not edge cases — they are the default expectations for any B2B SaaS company selling into mid-market and up.
A narrower note: service accounts are a third path, useful for backend-to-backend agent work where the principal genuinely is a machine. Workspace admin operations, infrastructure agents, billing reconciliation. They are not a substitute for delegated access when a human user is the real actor — using one as a shortcut around OAuth is the single most common pattern that fails security review.
OAuth 2.1 is the right model for most agent work in established SaaS. Implementing it correctly across every product in a portfolio is where teams get stuck — token storage, refresh rotation, per-tool scope mapping, and the audit trail that ties a tool call back to the authenticated user. Each connector you build by hand is another place that logic can drift.
Pontil's Tool Runtime executes tool calls as the authenticated user by default. The OAuth flow, token lifecycle, and scope enforcement sit in the runtime rather than in each connector, so the per-user audit trail your security review will ask about is the same shape across every tool the agent can reach. That's the part of the auth problem that compounds at portfolio scale — and the part most worth not solving five times. If you want to see the runtime against your own auth model, book a demo.
For any agent acting on behalf of a real user — which is most of them, in established B2B SaaS — pick OAuth 2.1 with delegated access. The setup cost is real, but it's the cost you'd pay anyway the first time security review asks who the agent was acting as. Pay it once, correctly, at the start.
Keep API keys for the cases where they're honest: internal prototypes, backend jobs without a user principal, and integrations with vendors that don't offer anything else. Use service accounts only when the principal genuinely is a machine, and never as a shortcut to avoid implementing delegation. The deciding variable is always the same — does a specific human user's identity, permissions, and audit trail need to be visible at the resource server? If yes, the answer is OAuth 2.1. If no, the cheaper option is fine. Most teams find, on honest examination, that the answer is yes more often than they thought.
Stay up to date on the ever changing agentic landscape.
GET STARTED
Start with a 30-minute discovery call
contactus@pontil.com
