AI Agent Service Accounts vs On-Behalf-Of Access: How to Give Agents Access Safely

Every AI agent that touches a business system has to authenticate as someone, and the choice between giving it its own service account or letting it act on behalf of a signed-in user decides what it can reach, who is accountable and how far one prompt injection can travel. A service account is an identity the agent owns, with permissions granted to the agent itself. On-behalf-of (OBO) access, also called delegated access, gives the agent a token derived from a user's authorisation, so it can do only what that user could do, usually narrowed further by scopes. Both models are legitimate and most production estates need both. This guide compares them side by side, sets out when to use each, the security trade-offs, how to combine them, and the mistakes that turn either into a breach. It is for identity architects, platform engineers and security teams approving agent deployments. For agent authorisation policy in general see the AI Agent Authorisation Guide.

Key takeaways

• Use on-behalf-of access when the agent works for one user on that user's data. OWASP's LLM06 Excessive Agency guidance says actions taken for a user should run on downstream systems in the context of that specific user, with the minimum privileges necessary.
• Use an agent service account when the work belongs to no single user. Scheduled jobs, triage across a shared queue and system-to-system tasks need an identity of their own with a named owner.
• Never use a generic high-privileged identity for per-user work. OWASP names this as a form of excessive permissions: an agent reading one user's documents with an account that can read everyone's.
• Delegation must keep the agent visible. Prefer tokens that record both the user and the acting agent over plain impersonation, so logs show who asked and what acted.
• Neither model removes the need for approval on high-impact actions. Scopes limit reach; a human or policy check limits what the agent does with it.

The short answer

If the agent acts at a user's request on resources that user owns or can see, such as their mailbox, calendar, files or tickets, use on-behalf-of access with narrow scopes and keep the agent's own identity in the token. If the agent acts for the organisation, runs without a user present, or processes data across many users, give it its own service account (or better, a workload identity with short-lived credentials) scoped to that task, owned by a named person, with approvals for destructive actions. When an agent does both, give it both and choose per tool call, never by falling back to the broader one.

What each model actually is

Agent service account

The agent authenticates as itself, typically with the OAuth 2.0 client credentials grant, a cloud workload identity, or a directory service account. Permissions are assigned to that identity directly. Every action is attributed to the agent, whichever user triggered it, so the resource server cannot apply that user's own permissions unless the agent passes and enforces them itself.

On-behalf-of (delegated) access

The user signs in and consents, and the agent receives a token that represents the user, limited by the scopes granted. In a chain of services this is usually done by exchanging the incoming user token for a new one aimed at the next service. RFC 8693 OAuth 2.0 Token Exchange defines that exchange and distinguishes two forms: impersonation, where the holder is treated as the user, and delegation, where the token keeps the user as subject and records the acting party in an act claim. An authorisation server can use the may_act claim to check that a given agent is allowed to act for the user. For agents that have no browser of their own, the OpenID Client-Initiated Backchannel Authentication (CIBA) specification, marked Final, lets a client request authentication and consent on the user's separate device, with a binding message shown on both. See the OAuth Token Exchange and Delegation Guide.

Side-by-side comparison

When to use each

Small and large organisations: a small team can start with on-behalf-of access through its existing identity provider's consent screens and one or two tightly scoped service accounts for scheduled jobs. A large estate needs an agent registry, admin-controlled consent policies that decide which agents may request which scopes, and workload identities rather than stored secrets for agent service accounts. See the AI agent registry.

Security trade-offs

• Prompt injection reach: an agent with a service account turns any successful injection into an action with the service account's full rights across all users. With on-behalf-of access the same injection is limited to the current user's scopes. This is the main reason OWASP prefers running in the user's context.
• Confused deputy: a service account agent that accepts a user's request and acts with its own broader rights can be asked to do something the user could not. If you must use one for user-triggered work, check the user's entitlement before every action, not just the agent's.
• Token custody: delegated tokens, especially refresh tokens, often end up stored by the agent platform for many users. That store becomes a single point of mass compromise. In the Salesloft Drift Breach 2025, OAuth access and refresh tokens held for a chatbot integration were stolen and used to export records from hundreds of customer tenants.
• Token passthrough: forwarding a user's token unchanged to downstream APIs breaks audience checks and audit. The MCP security best practices state that MCP servers must not accept any tokens that were not explicitly issued for the MCP server. Exchange the token for one aimed at the next service instead. See the MCP Authorisation Specification Guide.
• Over-scoped service accounts: a credential created for one purpose ends up reachable by an agent working on another. In the PocketOS Database Deletion 2026, a coding agent found an account-scoped API token created for domain management and used it to delete a production database and its backups.
• Consent fatigue: on-behalf-of access relies on users reading consent screens. The MCP guidance warns that broad, bundled scopes lead users to abandon or blindly accept consent; request a minimal set first and step up for privileged operations.
• Accountability: impersonation tokens make the agent invisible. Logs show the user doing things the user never did, which complicates investigation and, in regulated processes, the evidence of who authorised what.

How they work together: hybrid patterns

1. Agent identity plus user delegation: the agent always has its own registered identity (a client or workload identity) and uses it to authenticate token exchanges. The resulting token names the user as subject and the agent as actor. RFC 8693 notes that omitting client authentication lets a compromised token be leveraged into other tokens by anyone holding it, so the agent's own identity is what keeps delegation safe.
2. Split by tool: read-only organisational lookups use the service account; anything that changes a user's data uses the user's delegated token. Map each tool to one model in the agent's configuration so the model cannot choose the broader credential at run time.
3. Service account with user-scoped enforcement: where a downstream system cannot accept delegated tokens, pass the user's identity alongside the service account call and enforce the user's entitlements in a policy layer before the call. Treat this as a compensating control and record it as an exception.
4. Human approval for high-impact actions in both models: OWASP recommends human approval for high-impact actions, and CIBA gives a standard way to ask the user on another device. See the Human-in-the-Loop for AI Agents Guide.

Implementing and migrating

1. Inventory: list every agent, the credentials it holds, whose authority each represents, and each tool it can call. Flag any agent using a human's personal credential or a shared admin account; both are failures in either model.
2. Classify each tool: user-owned data and user-initiated changes go to on-behalf-of; organisational, scheduled or cross-user work goes to a service account.
3. Register the agent: give it a client or workload identity with a named owner, and restrict which scopes it may request through admin consent policy.
4. Pilot: move one low-risk tool to delegated tokens for a pilot group, compare outcomes and denied calls in logs, then widen. Keep the old path disabled, not deleted, for one release so you can roll back.
5. Retire broad credentials: once delegated access works, narrow or remove the service account permissions it replaced, and rotate any secret the agent could previously read. See the AI Agent Credential Lifecycle and Rotation Guide.

Detection and measurement

• Agent actions outside the requesting user's entitlements when a service account is used for user-triggered work.
• Tokens presented to the wrong audience or user tokens arriving at downstream APIs from agent infrastructure (a passthrough sign).
• Bulk reads by a delegated or integration token far beyond a single user's normal pattern.
• Service account credentials used from outside the agent runtime.

Metrics:

1. Share of user-triggered agent actions executed with delegated tokens rather than service accounts.
2. Share of delegated tokens that carry an actor claim or equivalent agent attribution.
3. Agent service accounts with a named owner and reviewed in the last quarter (target 100%).
4. Agents holding a human's personal credential or a shared admin account (target zero).
5. Median scopes requested per agent, trended down over time.
6. Time to revoke all grants for one agent across all users, measured in an exercise. See Revoking Delegated Access During an Active Agent Incident.

Common mistakes

• One super account for every user: a single high-privileged service account serves all users' requests, so any user can talk the agent into another user's data.
• Agent borrowing a person's credential: a developer's personal token or password configured in the agent, so nobody can tell what the agent did and the access leaves when the person does, or worse, stays.
• Impersonation by default: token exchange configured to issue plain user tokens, hiding the agent from every log downstream.
• Long-lived refresh tokens stored centrally for every user with no expiry policy, monitoring or per-tenant isolation.
• Falling back to the broader credential: when a delegated call is denied, the agent retries with the service account.
• No approval step: narrow scopes, but destructive or financial actions still run without confirmation.

Framework mapping

Practitioner checklist

• For each agent tool, decide whose authority it acts with: the requesting user's, or the organisation's.
• Use on-behalf-of access with minimal scopes for user-owned data and user-initiated changes.
• Use a dedicated service account or workload identity with a named owner for scheduled and cross-user work, never a person's credential.
• Configure token exchange for delegation with agent attribution, not impersonation, and authenticate the agent on every exchange.
• Never pass a user's token through unchanged; exchange it for a token aimed at the next service.
• Pin each tool to one credential type so the agent cannot fall back to a broader one.
• Protect stored refresh tokens as a high-value secret store, with expiry, monitoring and tenant isolation.
• Require human approval for destructive, financial and external-sending actions in both models.
• Rehearse revoking every grant held by one agent.

Standards and references

• IETF: RFC 8693 OAuth 2.0 Token Exchange
• OWASP: LLM06:2025 Excessive Agency
• Model Context Protocol: Security Best Practices
• OpenID Foundation: Client-Initiated Backchannel Authentication Core 1.0
• IETF: RFC 9396 OAuth 2.0 Rich Authorization Requests
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Agent Identity and Access Guide · OAuth Token Exchange and Delegation Guide · Shared credentials between AI agents · API Keys vs OAuth Tokens Guide