Enforce blended identity so the agent’s capability is always constrained by the user’s permission set and the tenant boundary. That prevents a shared agent instance from reusing the wrong context across customers and keeps delegated actions auditable at the right scope.
When customer agents act on behalf of users, what identity model should teams use?
The right model is blended identity, where the agent never acts as a free-standing principal. It carries delegated authority that is explicitly tied to a user, a tenant, and a scoped purpose. That keeps the agent’s effective permissions bounded by the user’s entitlements and prevents one shared runtime from drifting into cross-customer or cross-session access.
That distinction matters because “the agent can do it” is not the same as “this user may do it through the agent.” Teams need a representation that preserves who requested the action, who owns the data boundary, and what the agent is allowed to borrow from the session. Without that split, audit trails, policy checks, and customer isolation all become ambiguous.
In practice, the blended model usually combines user context, agent identity, and short-lived delegation. The user remains the source of authority, the agent supplies execution, and the platform enforces which requests are valid at the moment of use. When the agent needs to cross a boundary, such as calling a tool, reading tenant data, or performing a sensitive action, the permission check should still resolve against the user-scoped consent and the tenant-scoped policy, not only against the agent’s own technical identity.
How do delegation and isolation fail when a shared agent serves multiple customers?
Shared agents fail when context is reused too broadly, when tokens outlive the session that created them, or when the platform treats the agent as a single trusted helper across customers. The main hazard is context bleed: a valid action in one tenant or conversation is mistakenly replayed in another. That is why identity separation, tenant binding, and per-session state management have to be designed together.
Delegation also breaks when teams store standing permissions inside the agent rather than issuing them per request. A shared runtime may still be technically authenticated, but it can become operationally over-privileged if it can repeatedly invoke actions without re-checking the user’s current authority. The safest pattern is to make the agent prove which user it is acting for at the point of action, then constrain the action to the narrowest usable scope.
For teams building on AI Agent Authorisation Guide, the practical test is whether the agent can be forced through a policy decision for each sensitive step rather than carrying broad ambient power. For delegation flows that exchange one token for another, RFC 8693: OAuth 2.0 Token Exchange is a useful anchor because it formalises on-behalf-of style handoff without collapsing user and agent authority into one static credential.
How should teams design auditability and customer boundaries for on-behalf-of actions?
Auditability has to answer three questions: which user authorised the action, which agent executed it, and which tenant or customer boundary was in force. If any of those are missing, the record may show activity, but it will not explain authority. That is especially important when one agent instance serves many users, because logs that only identify the agent will not support incident review, customer dispute handling, or policy enforcement.
The boundary design should make the tenant context a first-class control, not an afterthought in logging. A request should inherit only the data, tools, and action scope that belong to the current user and tenant, and it should fail closed if that scope cannot be resolved cleanly. This is where identity, authorization, and observability meet: the system must be able to prove why an action was allowed, not just that it happened.
When teams need a wider identity lens, Human vs Non-Human Identity is useful for understanding where people and machine access meet, while AI Agent Observability, Audit and Incident Response Guide maps the logging and attribution side of the problem. For a broader policy model, Zero Trust for AI Agents reinforces the idea that each request should be verified at execution time, not assumed safe because the agent is already active.
Risk and Threat Considerations
Blended identity fails most dangerously when the agent’s convenience starts to outrun its authority. If delegation is too broad, a compromised prompt, replayed session, or misrouted token can turn one user’s valid request into another customer’s exposure. The core risk is not just over-permission, but confused authority across tenants, which can produce both data leakage and unauthorised action.
Failure mechanism: The platform reuses an agent session, token, or execution context beyond the user and tenant for which it was issued, so a later action inherits the wrong authority or data boundary.
Impact: Customer data can cross boundaries, audit trails can misattribute actions, and a single agent compromise can scale into multi-tenant blast radius rather than a contained user session.
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 and OWASP Non-Human Identity Top 10 address 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 | On-behalf-of agents can overstep user authority or tenant scope. |
| Recommendation — Enforce per-action checks so agent execution never exceeds delegated user authority. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | Customer-facing agents need strong authentication when acting for external users. |
| AC-6 — Least Privilege | Shared agents should only receive the minimum authority needed for each task. | |
| AU-2 — Event Logging | Agent actions on behalf of users must be attributable for audit and review. | |
| Recommendation — Use token exchange and bounded credentials to authenticate delegated agent actions. Scope each delegated action to the minimum permissions required. Log user, agent, tenant, and action context for every delegated request. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Per-request verification fits delegated agent actions across tenants and sessions. |
| Recommendation — Verify each agent request at execution time instead of trusting the session. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Shared customer agents become risky when permissions are broader than user need. |
| Recommendation — Reduce agent privileges to the narrowest customer-scoped access path. | ||
Practitioner Guidance
What to verify: Confirm that every sensitive action resolves against current user consent, current tenant context, and a short-lived delegation record. If any one of those is implied rather than enforced, the design is not ready for production use.
Common mistake: Teams often authenticate the agent once and then treat it as permanently trusted for the rest of the conversation. That shortcut is what turns a helpful assistant into a shared privileged runtime.
Practitioner takeaway: The safest model is not “trust the agent less,” but “bind the agent more tightly to the user and tenant at the moment of action.” If the platform cannot prove that binding for a given operation, the operation should not proceed.
Related resources from NHI Mgmt Group
- What should teams do when AI agents act on behalf of real users?
- Why do traditional customer IAM controls break down when AI agents act on behalf of users?
- How should teams govern consumer authentication when AI agents can act on behalf of users?
- How should security teams manage permissions for AI agents?