OAuth for AI agents: why static API keys no longer scale

At a glance

What this is: This is a deep-dive on replacing long-lived API keys with OAuth-based, scoped access for AI agents and MCP servers.

Why it matters: It matters because identity teams have to govern agent access as a live authorization problem, not a configuration shortcut, when deployments scale across tools and services.

Context

AI agent access becomes a governance problem when teams hand out long-lived API keys and expect them to behave like controlled, revocable identity. The article frames the core failure plainly: static secrets make agents broadly capable, but they do not make them safely governable.

The practical alternative is to treat agent access as a delegated identity flow, not a shared credential pattern. That shift matters for API key management because the control question moves from where the key is stored to how the agent is authorised, scoped, observed, and revoked.

Key questions

Q: Why do long-lived API keys create more risk for AI agents?

A: Long-lived API keys increase risk because they persist across tasks, deployments, and runtime changes. If one is exposed in a container, pipeline, or config file, the attacker can reuse it until it is manually revoked. For AI agents, that persistence creates a larger blast radius than the workload actually needs.

Q: Why does OAuth token exchange reduce risk compared with giving an AI agent broad access or shared user credentials?

A: Token exchange reduces risk because the agent never needs a permanent bundle of credentials or blanket permissions. Each exchange can be limited to a specific resource, scope, and time window, so compromise yields less usable access. The resulting token can also preserve delegation context, which improves transparency and helps downstream systems distinguish legitimate on-behalf-of activity from direct user action.

Q: How should teams govern agent access when autonomy increases?

A: Teams should govern agents as runtime principals, not as static app settings. As autonomy rises, the important decisions move from provisioning to execution: what the agent may do, when it may do it, and how quickly authority can be withdrawn if behaviour drifts outside intent.

Q: What should security teams monitor after moving agents to delegated identity?

A: Security teams should monitor token issuance, refresh, scope changes, consent grants, revocation events, and unusual tool usage. Those signals show whether delegated identity is still aligned to the intended task, or whether the agent has accumulated access that no longer matches its original authorisation.

Technical breakdown

Why static API keys break down for agents at scale

API keys are bearer credentials, which means anyone in possession of the key can use it until the key is revoked or expires. In agentic environments, that becomes especially risky because one key may be copied into configuration files, environment variables, or multiple runtime contexts. The result is permanent capability without context, scope, or meaningful auditability. OAuth changes the model by separating authentication, authorisation, and resource access. Instead of embedding standing access into the agent, it issues tokens that can be time-bound, scoped, and revoked. See the API Key Management Guide.

Practical implication: Treat static API keys as an exception path, not the default identity pattern for agents.

How OAuth maps to MCP without collapsing the trust model

MCP works best when the resource server verifies tokens issued by a separate authorisation server, rather than trusting whatever client connects first. That separation preserves the standard OAuth roles: client, resource server, and authorisation server. Dynamic Client Registration adds an additional layer by letting unknown or newly created clients register metadata at runtime, which reduces manual pre-registration friction while still preserving identity controls. The key governance point is that agent identity must remain explicit, not implied by a shared server secret or a copied configuration block. Read OAuth 2.0 and OpenID Connect Guide for Identity Teams.

Practical implication: Use separate authorisation services and runtime client registration so the MCP server does not become the policy engine.

Where autonomous agent behaviour changes the authorisation problem

Once agents begin selecting tools, timing actions, and chaining requests without a human approval gate, access stops being a static entitlement issue. The hard question becomes whether the identity system can still reason about scope before execution, because autonomy introduces runtime variability in both intent and delegation. That does not make OAuth obsolete. It makes the surrounding controls more important: consent, token lifetime, delegated authority, and audit trails must all be designed for agent behaviour, not just for human-initiated sessions. See the AI Agent Authorisation Guide.

Practical implication: Design for runtime delegation decisions, not just for token issuance at onboarding.

Threat narrative

Attacker objective: The attacker wants durable, reusable access through an agent credential that outlives the task and bypasses normal consent boundaries.

1. Entry begins when an agent receives a long-lived API key or broadly scoped credential and can use it across tools without a fresh authorisation decision.
2. Escalation follows when that credential is reused across multiple services or agent instances, expanding the blast radius beyond the original task.
3. Impact occurs when a compromised or over-privileged agent can read, modify, or act across connected systems with no clean revocation path.

Breaches seen in the wild

• Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Static secrets are not an agent governance model: API keys turn every connected agent into a permanent bearer of authority, which is the opposite of how identity should behave in a delegated runtime. The article correctly shows that the problem is not just leakage, but persistence without context. That persistence defeats revocation discipline and makes agent access impossible to reason about at scale. Practitioners should treat long-lived keys as an architectural warning sign, not a convenience.

OAuth does not solve agent security by itself, but it restores governability: The value is not that OAuth is fashionable, but that it reintroduces scoped, revocable, inspectable authority into the access path. That matters for NHI governance because agent access should be discoverable and bounded, not hidden inside a config file. The article’s strongest point is that standards-based delegation beats credential stuffing every time when the estate grows.

Identity review processes were built for stable access, not ephemeral agent action: The governance assumption is that privilege persists long enough to be reviewed, certified, and remediated. That assumption fails when agents can be provisioned, act, and be retired through dynamic registration and short-lived tokens with little or no standing access. The implication is not a new checklist, but a rethink of what an access record even is in agent ecosystems.

Cross-boundary delegation is where NHI programmes will either mature or fail: Once an agent moves across systems, the security question becomes chain of custody for identity, not just authentication at the edge. That is where runtime authorisation, auditability, and revocation must line up. Without that, the organisation has delegated power without clear accountability, which is exactly the kind of blind spot NHI governance is meant to remove.

From our research library:

• 69% of organisations still authenticate machine identities with long-lived API keys, according to the 2026 State of AI Agent Identity Security Report.
• Read next: OAuth 2.0 and OpenID Connect Guide for Identity Teams

What this signals

Identity teams need to move agent governance from secret custody to runtime delegation: Once an agent can be registered on demand and issued short-lived credentials, the control point becomes authorization, not vault storage. That is a material shift for IAM and NHI programmes because the question is no longer where the secret lives, but whether the delegated session is still valid for the action being taken.

Agent identity will increasingly look like software identity, not human impersonation: The most durable model is to give each agent a distinct client identity, metadata, and revocation path. That aligns with agent identity governance and helps programmes separate user intent from machine execution without collapsing both into one brittle approval flow.

Ephemeral credentials are only useful when the surrounding control plane can observe them: If access is short-lived but invisible, the governance problem just changes shape. Teams need to see issuance, refresh, revocation, and scope drift as first-class signals so they can tell whether delegated access still matches the original purpose.

For practitioners

• Replace standing API keys with short-lived delegated tokens Move agent access to scoped OAuth flows with token expiry, explicit consent, and revocation paths instead of static secrets in config files.
• Separate the authorisation server from the MCP resource server Keep policy enforcement and token issuance outside the tool server so the server only validates tokens and serves resources.
• Model each agent as a distinct software identity Give agents their own client identity, metadata, and audit trail so permissions can be assigned, traced, and retired independently.
• Instrument token lifecycle and unusual access patterns Log token issuance, refresh, revocation, scope changes, and tool use so you can detect access that no longer matches the original grant.

Key takeaways

• Static API keys give agents durable authority that is difficult to scope or revoke, which makes them a poor fit for scaled agent deployments.
• OAuth-based delegation restores time bounds, consent, and auditability, but only when the surrounding architecture keeps policy and resource access separate.
• As agent autonomy grows, identity governance has to move from storing secrets to governing runtime decisions, scope drift, and revocation.

Related NHI Mgmt Group resources: API Key Management Guide · Agentic AI Identity Guide · OAuth 2.0 and OpenID Connect Guide for Identity Teams · AI Agent Authorisation Guide

Key terms

• Dynamic Client Registration: Dynamic client registration is a protocol pattern that allows a software client to register itself with an authorization system automatically. For AI agents, it can reduce manual setup, but it also creates new identities at speed, which makes ownership, policy checks, and revocation essential.
• Bearer Credential: A bearer credential is a secret that grants access to whoever possesses it, without requiring proof of the original user at every request. In SaaS and cloud environments, OAuth tokens, session cookies, and similar artifacts behave this way, which makes theft and replay a direct access path.
• Delegated Identity: Delegated identity is when one actor acts on behalf of another with explicit permission and bounded authority. In AI-assisted commerce, it requires clear consent, limited scope, and traceable records so the retailer can distinguish authorised delegation from unauthorised automation.
• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.