How should teams handle identity when multiple people share the same AI agent interface?

Treat the caller, not the agent, as the security boundary. Resolve each request to a specific human identity, then execute tools only within that user’s entitlements. If the caller cannot be verified, return an anonymous identity with no grants and force an auth step instead of falling back to a shared bot token or service account.

Shared Agent Interfaces Still Need Per-Caller Identity

When one AI agent interface is used by multiple people, the interface is only a shared front door, not a shared security principal. The team should bind every request to a specific human, then evaluate tool access, data access, and approvals from that person’s entitlements. The agent can assist with orchestration, but it should not become the identity boundary.

That distinction matters because shared entry points often hide who actually asked for the action. If the platform cannot resolve the caller cleanly, the safe default is to treat the request as unauthenticated, not to borrow a standing bot token or service account just to keep the workflow moving. The user identity is what drives accountability and least privilege.

What Changes in Authorization When Many People Use the Same Agent UI?

The core design shift is from “who is operating the interface?” to “who is the request on behalf of?” That means the agent session should inherit only the current caller’s claims, scopes, and session state, and those should be re-evaluated at each action that has security impact. Shared interfaces can reuse the same chat surface, but not the same authorisation context.

This is especially important for delegated actions such as reading records, writing tickets, moving money, triggering deployments, or calling internal APIs. If the interface collapses multiple users into one backend identity, the agent loses the ability to enforce separation of duties, per-user approvals, and individual audit trails. A shared bot account is a convenience pattern, not a valid substitute for caller-bound authorisation. For teams standardising those controls, AI Agent Authorisation Guide explains how to apply least privilege and per-action policy decisions, and RFC guidance such as RFC 8693: OAuth 2.0 Token Exchange and OpenID Connect Core 1.0 support on-behalf-of identity propagation and authentication flows.

Where the agent can act across tools, the safest pattern is to separate the interactive session from the execution identity. The UI session identifies the person, while the execution layer uses short-lived, scoped credentials derived from that person’s rights. That preserves user-level control without giving every participant the same standing power.

How to Prevent Identity Drift, Shared Tokens, and Audit Blindness

The main failure mode is identity drift, where a request starts with a human but ends up executing as an oversized shared principal. Once that happens, logs, approvals, and downstream tools all record the wrong actor. The result is weak attribution, overbroad access, and a much harder incident investigation if something goes wrong.

Teams should also watch for “soft sharing” patterns, such as copying session cookies, reusing API keys, or letting the agent keep a generic authenticated context after the user steps away. Those shortcuts blur ownership and make revocation ineffective. AI Agent Observability, Audit and Incident Response Guide is directly relevant here because attribution, logging, and kill-switch design only work when the system can tell which human initiated each action. Shared-session risk is also why Browser and Computer-Use Agent Security Guide matters whenever an agent reuses a person’s active session to drive a browser or desktop.

Risk and Threat Considerations

Shared agent interfaces create a predictable trust-bypass problem: if one backend principal can act for everyone, any compromise, misuse, or mistaken approval can scale across the whole user group. The exposure is not just unauthorized action, it is also broken attribution, which weakens detection and makes it harder to prove what happened.

Failure mechanism: The platform falls back to a shared token, cached session, or service account when it cannot confidently bind the request to a single verified caller, so the tool call executes with broader or less traceable authority than intended.

Impact: Attackers or careless users can inherit permissions they should not have, sensitive actions may be executed without proper approval, and incident response loses the ability to tie high-risk operations back to a specific person.

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 OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Agentic AI Top 10	ASI03 — Identity & Privilege Abuse	Shared agent interfaces can collapse user identities into one authority path.
Recommendation — Bind each action to the current human principal and enforce per-action authorization.
NIST SP 800-53 Rev 5	IA-2 — Identification and Authentication (Organizational Users)	The interface must identify the caller before any privileged tool use.
	AC-6 — Least Privilege	Shared agents must execute only within the caller’s entitlements.
	AU-2 — Event Logging	Caller-bound attribution is needed when multiple people share one agent UI.
Recommendation — Require per-user authentication before the agent can act on a request. Scope agent tool access to the minimum rights needed for the verified user. Log the verified caller, action, and authorization result for every agent tool call.
OWASP ASVS	V8 — Authorization	Shared UI access still requires per-request authorization decisions.
Recommendation — Check each request against the current user’s permissions before executing any action.

Practitioner Guidance

What to verify: Confirm that every agent action carries a caller-specific identity assertion, not just an interface session ID. The authorization decision should be reproducible from logs, including who the caller was, what entitlements were consulted, and whether the request was verified before execution.

Decision rule: If the system cannot resolve the caller to a verified human, treat the request as anonymous and stop at authentication. Do not let the agent continue under a shared bot identity, even if that seems operationally easier, because convenience is exactly how privilege sprawl starts.

What good looks like: Different users can share the same chat or agent surface, but each tool invocation is still bounded by the current user’s rights, the action is attributable to that user, and revocation removes their ability to act immediately.

Practitioner takeaway: The right control is not “which agent is speaking?”, it is “which person is the agent acting for right now?” If that answer is not explicit and enforceable, the interface is not safe enough for privileged work.