A shared bot token makes the agent act as one universal identity. Per-user OAuth makes the same workflow behave differently for each caller because every tool call runs under that person’s own grant. The first centralises risk and weakens auditability. The second preserves attribution, supports least privilege, and lets governance enforce different outcomes for different users.
Why the distinction matters for AI workflows
A shared bot token collapses many users into one technical actor, so every call looks like it came from the same identity. Per-user OAuth keeps the workflow tied to the caller, which means the same automation can produce different outcomes based on that person’s permissions, consent, and policy. The difference is not cosmetic, it changes who is accountable, what can be accessed, and how tightly you can govern the workflow.
That distinction becomes especially important when an AI workflow touches sensitive data, writes back to business systems, or chains multiple tools together. The identity model decides whether the workflow is operating as a single service account or as delegated user access, and that changes both the control surface and the audit story.
For the OAuth mechanics behind per-user access, RFC 6749: The OAuth 2.0 Authorization Framework is the baseline reference for how delegated authorization is expressed.
How shared bot tokens and per-user OAuth behave differently
A shared bot token is usually simplest to deploy. The workflow authenticates once, stores one credential, and reuses it for every user and every action. That simplicity also means the system has a single blast radius: if the token is copied, over-scoped, or left in a log, an attacker may inherit the bot’s full reach.
Per-user OAuth changes the model. Each caller authorizes the workflow with their own grant, so the workflow inherits that user’s effective access rather than a universal bot entitlement. In practice, that lets the same automation respect row-level permissions, mailbox boundaries, file sharing rules, and other user-specific controls without building a separate policy engine inside the workflow.
If you need a practical explanation of the delegated-grant side of this design, the OAuth 2.0 and OpenID Connect Guide for Identity Teams covers grant types, scopes, and the security mistakes that often appear in implementation.
Where organisations still need service-to-service patterns, the RFC 8693: OAuth 2.0 Token Exchange is useful because it separates delegation from simple token reuse, which is often the safer way to represent “on behalf of” behaviour.
What changes in governance, auditability, and operational risk
Shared bot tokens make governance coarse-grained. Access reviews, revocation, and incident response all operate on the bot as a whole, so you lose the ability to ask which person actually triggered a specific action. Per-user OAuth gives you attribution, because the action can be tied back to the caller’s grant, consent, and policy state. That is usually a major improvement for auditability and for investigations after an unexpected tool action.
There is also a meaningful privilege effect. A shared token often accumulates broad scopes “just to keep the workflow working,” which quietly turns one automation into a high-value standing credential. Per-user OAuth can narrow that exposure because the workflow only receives the access that the current caller already has, and governance can differentiate outcomes by user, role, or approval state.
The governance challenge with shared credentials is visible in long-lived token exposure and reuse patterns, which is why the Guide to the Secret Sprawl Challenge is relevant to this trade-off. For a concrete breach pattern, GitHub OAuth token breach 2022 shows how stolen oauth token can become a broad entry point into connected systems.
Risk and Threat Considerations
Shared bot tokens concentrate risk in one reusable credential, so compromise, leakage, or over-scoping affects every workflow path that depends on it. Per-user OAuth reduces that concentration, but it also shifts the problem toward token protection, consent quality, and ensuring the workflow does not silently over-represent the user when it performs downstream actions.
Failure mechanism: A shared token can be replayed, copied, or overprivileged once, then used across all users and integrations; per-user OAuth fails differently when scopes are too broad, tokens are cached too long, or the workflow keeps acting after the user’s actual intent or access has changed.
Impact: The shared-token model increases blast radius, weakens attribution, and makes revocation blunt. The per-user model improves accountability and least privilege, but only if token handling, scope design, and consent enforcement are tight enough to preserve the user boundary in practice.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Relevant when the workflow uses a shared service credential or bot token. |
| IA-2 — Identification and Authentication (Organizational Users) | Relevant because per-user OAuth preserves user-bound authentication and attribution. | |
| AC-6 — Least Privilege | Applies because per-user OAuth should limit tool access to the caller's effective rights. | |
| Recommendation — Authenticate the workflow with a distinct service identity and protect its credentials. Bind workflow actions to the authenticated user when attribution matters. Scope delegated access to the minimum rights needed for the task. | ||
Practitioner Guidance
What to prioritise: Use a shared bot token only when the workflow truly represents one organisational actor and the action set is intentionally uniform. If the workflow makes user-specific decisions, touches customer data, or writes into systems with different permission boundaries, per-user OAuth is usually the better default.
What to verify: Check whether the workflow can prove which user authorised the action, whether tokens are audience-restricted, and whether the app can still function safely after a user revokes consent or changes roles. If you cannot answer those questions, the access model is still too coarse.
Common mistake: Teams often choose the shared token first because it is faster, then try to rebuild attribution later through logs. That reverses the order of control design. If auditability matters, build the identity boundary into the workflow from the start.
Practitioner takeaway: Shared bot tokens optimise deployment simplicity, while per-user OAuth optimises accountability and policy fidelity. The right choice depends on whether the workflow should behave like one service identity or like many user-bound executions.
Related resources from NHI Mgmt Group
- What is the difference between OAuth and token exchange for AI agent access?
- What is the difference between proxying delegated access and giving an AI agent the user’s access token directly?
- What is the difference between acting as a user and acting through a shared service account for AI agents?
- What is the difference between user identity and agent identity in enterprise AI workflows?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
