Give the agent separate credentials or scoped grants for each named user whenever the action is performed on a person’s behalf. That preserves accountability, limits blast radius, and makes revocation practical. A shared credential hides whose authority was used and makes every incident harder to investigate.
Why separate credentials matter when one agent acts for many people
An agent that can act for multiple users should not run on a single shared identity. Separate credentials or scoped grants preserve who authorised each action, keep the privilege boundary narrow, and make revocation and incident review possible without guessing. The main design goal is not convenience, it is preserving attribution and limiting the damage if one delegated path is abused.
When a shared credential is reused across users, every action inherits the same indistinct authority. That creates an accountability gap: logs show that “the agent did it”, but not which user’s approval, scope, or session was actually in force. It also turns a compromise into a broader event because one leaked credential can expose every user mapped to that agent.
For teams implementing agent delegation, the right mental model is closer to per-principal delegation than to a generic bot account. The agent can still automate work, but each user-bound action should be tied to that user’s grant, consent, or delegated token so the resulting record is unambiguous and reversible.
What breaks when attribution is collapsed into one shared identity
The first failure is forensic ambiguity. If the same credential is used across several users, investigators cannot reliably separate legitimate delegated actions from misuse, which slows containment and weakens post-incident reconstruction. That is especially important when the agent can reach sensitive systems or perform irreversible operations.
The second failure is blast radius. Shared credentials tend to accumulate permissions because they must cover multiple workflows, so one compromise can expose far more than one user’s authority. In practice, the worst-case outcome is not just misuse of a single account, but uncontrolled reuse of broad access across many sessions and many principals.
The third failure is lifecycle fragility. Revoking access for one user becomes awkward if that user’s authority is bundled into a shared credential or long-lived grant. Separate grants let you expire only the affected authority, which is far safer than rotating or replacing the entire agent relationship for everyone.
That is why AI Agent Observability, Audit and Incident Response Guide matters here: attribution only works when action logs, correlation IDs, and revocation points are designed to distinguish one user’s delegated activity from another’s.
How to structure delegation so the agent remains attributable
Give each named user an explicit delegation path, then scope the agent’s access to that user’s approved tasks, data, and systems. The important detail is that the agent should present the user-specific grant when performing the action, not a universal credential that pretends every user is the same principal.
Where possible, enforce per-action authorization rather than blanket access. This keeps the decision point close to the action itself, which is the best way to prevent an agent from carrying one user’s approval into a different context. It also makes it easier to answer the question “who authorised this?” after the fact.
The supporting identity model is described well in Agentic AI Identity Guide, which frames delegated authority, token exchange, registration, and retirement as part of the same lifecycle rather than as an afterthought.
When the agent needs broader control patterns, pair delegation with AI Agent Authorisation Guide so task-scoped access and human approval gates stay aligned with the user whose behalf the agent is acting on.
For the underlying delegation mechanism, RFC 8693: OAuth 2.0 Token Exchange is the cleanest reference point when an agent needs a token that reflects on-behalf-of authority rather than a shared bearer token.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent-on-behalf-of flows hinge on delegated authority and scoped privilege. |
| Recommendation — Enforce per-user delegated authority and per-action policy checks for agent actions. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Agents and services need distinct authenticating identities for attributable delegated actions. |
| AU-3 — Content of Audit Records | Attribution requires logs that preserve which user grant authorized each agent action. | |
| AC-6 — Least Privilege | Shared credentials expand privilege beyond a single user’s needed scope. | |
| Recommendation — Use separate authenticating identities or tokens for each user-bound agent delegation. Record the delegated principal, grant, and action context in audit events. Scope each delegation to the minimum access needed for that named user’s task. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Per-request verification and no standing trust fit multi-user agent delegation. |
| Recommendation — Verify each agent request against the current user context before permitting action. | ||
Practitioner Guidance
Decision rule: If the action can create a durable record, move money, change access, read sensitive data, or trigger another system, do not let the agent act under a shared userless identity. Bind the action to the named user’s grant, even if that means a slightly more complex workflow.
What to verify: You should be able to prove, for any significant action, which user authorised it, which grant was used, and how that grant can be revoked without affecting other users. If you cannot produce that evidence quickly, the delegation model is too coarse.
Common mistake: Teams often optimise for convenience by creating one “agent account” with enough privilege for everyone. That saves integration effort up front, but it removes the very separation needed for audits, incident response, and safe offboarding.
Practitioner takeaway: The safest design is not “one powerful agent with many users behind it”, it is “one agent, many distinct delegations”, so attribution, revocation, and containment all remain precise.
Related resources from NHI Mgmt Group
- How can organisations reduce the blast radius of compromised agent identities?
- How should organisations design audit logging for delegated agent actions so the record survives multiple hops?
- How do organisations operationalise NHI ownership at scale?
- Why is single-provider AI agent governance not enough for enterprise security?