On-behalf-of access means the server acts downstream using the caller's identity or delegated authority rather than a shared service account. For MCP, this preserves accountability and keeps enterprise permissions aligned with the actual user, not a generic bot credential.
How On-Behalf-Of Access Works
On-behalf-of access is a delegation pattern, not a shared credential pattern. The server performs downstream actions with the caller’s identity or a constrained delegated token, so the request can be traced back to the original actor instead of a generic bot account.
This matters because it preserves accountability across service boundaries. When the downstream system sees a delegated identity, policy decisions, audit trails, and incident review can reflect who initiated the action and under what authority.
Why It Is Used in Agent and MCP Flows
In agentic and MCP-style workflows, on-behalf-of access is the cleanest way to let software assist a user without collapsing every action into one high-privilege service account. The delegation model lets the agent act, but only within the permission boundary already granted to the user or a narrowly scoped intermediary token.
That design helps separate the agent’s execution role from the user’s authority. It is especially important when the same server may serve many users, tenants, or environments, because the access decision must stay tied to the correct principal rather than to the platform itself.
Identity, Authorization, and Delegation Boundaries
On-behalf-of access sits at the intersection of authentication and authorization. The system must know who the caller is, who is allowed to delegate, what downstream audience is permitted, and how far the delegation can travel before it expires or becomes invalid.
The practical question is not just whether a token is valid, but whether the token represents the right authority for the next hop. RFC 8693: OAuth 2.0 Token Exchange is the most relevant standard reference for this model because it formalises token exchange for delegation and impersonation flows.
Related authentication mechanisms such as audience restriction, sender-constrained tokens, and mutual TLS help keep delegated access from being replayed outside its intended path. The point is to make delegation narrow, auditable, and hard to reuse elsewhere.
Operational Consequences for Security and Audit
When on-behalf-of access is implemented well, audit logs can distinguish user intent from service execution. That separation is critical for investigations, approvals, and entitlement reviews because it shows which actor requested the action and which component carried it out.
It also reduces the temptation to overuse broad service accounts. If every downstream call runs under one shared identity, the organisation loses attribution, expands blast radius, and makes least-privilege enforcement much harder to prove in practice.
Risk and Threat Considerations
Delegated access becomes risky when implementations silently fall back to shared service credentials, over-broad scopes, or reusable bearer tokens. In that failure mode, a workflow that should preserve user accountability can instead turn into a high-value credential path with weak attribution and broad lateral reach.
Failure mechanism: The server or agent receives authority that is wider than the original user intent, or it reuses a token beyond the intended audience, lifetime, or downstream hop. That can enable privilege inflation, token replay, or confused-deputy behaviour.
Impact: Attackers or misconfigured workflows can trigger actions that appear to come from a legitimate service, obscure the original requester, and expose sensitive systems to unauthorised downstream operations.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API2 — Broken Authentication | On-behalf-of flows rely on correct downstream authentication and token handling. |
| Recommendation — Validate token exchange and sender binding so delegated calls cannot be replayed or misused. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Delegated access depends on controlling token and secret lifecycle across hops. |
| AC-6 — Least Privilege | On-behalf-of access should preserve the caller's limited authority instead of expanding privilege. | |
| Recommendation — Manage delegated credentials and tokens through issuance, rotation, revocation, and expiration. Constrain delegated access to the minimum permissions and resource audience needed for the task. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | The term directly concerns how access is granted, bounded, and reviewed across systems. |
| Recommendation — Map delegated access paths to approved accounts and review them for unnecessary standing privilege. | ||
| OWASP ASVS | V8 — Authorization | The pattern depends on enforcing who may act for whom and under what scope. |
| Recommendation — Verify that the application enforces authorization on the acting principal and the delegated target resource. | ||
Practitioner Guidance
Why practitioners should care: On-behalf-of access is only valuable when delegation stays precise. If the downstream system cannot distinguish user authority from service execution, the control loses much of its security and governance value.
What to watch for: Check for broad token scopes, shared fallback accounts, and access paths that no longer preserve the original principal in logs or policy checks. Those are the usual signs that delegation has drifted into convenience-based impersonation.
Practitioner takeaway: Treat delegated access as a bounded trust relationship, not a convenience feature, and design it so every hop can still answer who acted, on whose authority, and for which resource.
Related resources from NHI Mgmt Group
- Guide: Agentic AI Identity Guide
- How should security teams handle delegated access when AI agents act on behalf of customers?
- How should security teams govern SaaS applications that access Microsoft 365 on behalf of users?
- How should security teams implement delegated authorization for on-behalf-of access in applications and identity flows?
- Who is accountable for access requests when users ask for access on behalf of others?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org