Why do production AI agents need per-user delegated OAuth instead of shared service accounts?

Why delegated OAuth fits production agents better than shared accounts

Production agents are not just “another integration.” They act on behalf of a person, often across multiple tools and scopes, so the authorization model has to preserve who initiated the action, what the agent is allowed to do, and under which consent. delegated oauth keeps those boundaries intact, while a shared account collapses them into one credential and one audit trail.

That distinction matters because the security question is not only whether the agent can authenticate, but whether each request can be tied to a real user context with bounded scope. If the agent uses a shared service account, every action looks the same, every compromise gets the same privileges, and every review has to infer intent after the fact instead of enforcing it at runtime.

Per-user delegated access is the cleaner fit for runtime decisioning because it preserves the user principal, the agent principal, and the delegated grant as separate controls. That separation is what lets teams say, “this agent acted for that user, with these permissions, for this purpose,” rather than “the bot did it,” which is not operationally good enough for production.

Where shared service accounts create failure modes

Shared service accounts are attractive because they are easy to provision once and reuse everywhere, but that convenience creates hidden coupling. When multiple users and workflows depend on the same credential, privilege becomes harder to scope, revoke, and investigate. The resulting blast radius is larger because the same identity can be reused across requests, sessions, and sometimes environments.

In practice, the failure mode is not just “more access than intended.” It is loss of attribution, loss of consent boundaries, and loss of containment when an agent is tricked into taking a harmful action. If a prompt injection, misconfiguration, or tool abuse path causes the agent to act, the shared account makes it much harder to separate legitimate delegated use from unauthorized use.

Production systems should treat that as an authorization problem, not just an operational preference. OAuth 2.0 Authorization Framework exists to express delegated access, and OAuth 2.0 Token Exchange is especially relevant when an agent needs an on-behalf-of pattern instead of a shared credential.

For higher-assurance deployments, sender-constrained tokens reduce replay risk if a token is stolen. OAuth 2.0 Best Current Practice reinforces that production OAuth needs more than nominal login, and DPoP or mutual-TLS client authentication can help bind tokens more tightly to the client.

What good delegated design looks like for production agents

A sound production pattern is to issue access based on the user’s delegated consent, then scope the agent’s runtime actions to that user and task. The agent should not inherit a standing enterprise-wide credential just because it is convenient to operate. Instead, it should receive the minimum authorization needed for the specific action, with expiry, audience restrictions, and clear accountability in the token or session context.

That model also improves enterprise reviewability. Access reviews, consent prompts, and post-incident investigations become meaningful when each request can be tied back to a user and a bounded delegation. It is much easier to decide whether an action was appropriate when the system can show who approved it, what the agent was delegated, and whether the action stayed inside the intended scope.

For agent systems that need structured identity and delegation, NHIMG’s Agentic AI Identity Guide explains the identity model for agents, including delegation and retirement, while the AI Agent Authorisation Guide focuses on least privilege and per-action authorization. If the agent’s access is still being expressed as one shared account, the design has not really moved into production-grade delegated control.

It also helps to compare the pattern against broader identity governance. NHIMG’s Human vs Non-Human Identity shows why shared credentials blur ownership, while Service Account Security Guide covers the governance burden that appears when machine credentials are unavoidable.

Risk and Threat Considerations

Shared service accounts expand the blast radius of compromise because one credential can unlock many users, workflows, and tool paths. They also make prompt-injection and tool-abuse outcomes harder to contain, since the agent’s action is no longer clearly bounded by the initiating user’s delegated context.

Failure mechanism: A single reused credential or token is accepted as the agent’s standing authority, then replayed, overextended, or abused across requests, which removes user-level scoping and weakens revocation, tracing, and containment.

Impact: Attackers or abusive prompts can turn one compromised path into broad unauthorized access, while defenders lose the ability to distinguish legitimate delegated use from shared-account misuse during review or incident response.

Practitioner Guidance

What to prioritise: Treat per-user delegation as the default for any production agent that takes user-facing actions. Reserve shared accounts for narrow backend cases where no user context exists and the access can be tightly constrained, monitored, and separately justified.

What to verify: Confirm that the runtime token or authorization grant names the user, the agent, the target resource, and the allowed action, and that revocation actually removes that delegation without breaking unrelated users. If you cannot answer “who approved this action, for whom, and under what scope,” the model is too coarse.

Common mistake: Teams often use a shared account during pilot phase and never replace it because it appears to “just work.” That shortcut usually becomes the permanent security model, even though it undermines attribution, least privilege, and post-incident containment.

Practitioner takeaway: Production agents should be built around delegated authority, not pooled identity, because good agent security is defined by bounded action and clear accountability, not by whether the system can reach the API.

Related resources from NHI Mgmt Group

• How can organisations govern AI agents that use service accounts and tokens?
• How should security teams govern AI agents that use OAuth access?
• How should security teams limit the risk from AI agents that have access to production systems?
• What breaks when AI agents rely on shared service accounts or API keys?