It prevents the agent from directly holding the downstream service token, which reduces the blast radius if the agent logic is compromised. The server can retrieve scoped credentials on the user’s behalf while keeping the sensitive token outside the agent runtime. That is a stronger control boundary than passing secrets into the model or its tool layer.
Why on-behalf-of changes the security boundary
On-behalf-of matters because it separates who is acting from what secret is held. The AI agent can initiate the action, but the downstream service token stays in the server or broker that can enforce policy, scope, and expiry. That is a materially safer boundary than letting the agent runtime carry a reusable token through prompts, tools, memory, or logs.
The practical effect is that compromise of the agent logic does not automatically become compromise of the downstream service account. On-behalf-of also supports narrower scoping per user, per action, or per resource, which makes it easier to revoke, audit, and rotate access without redesigning the whole agent.
For AI agents, this is the difference between delegated execution and secret exposure. The more you keep the downstream credential outside the model and its tool layer, the less likely an attacker, a prompt injection chain, or a misbehaving tool can turn one agent failure into broad service access.
How on-behalf-of compares with passing a token into the agent
Passing a downstream token into the agent makes the agent runtime part of the trust boundary for that credential. That expands blast radius because the token may be copied into traces, cached in memory, forwarded to tools, or reused outside the original user intent. On-behalf-of avoids that pattern by making the server exchange or retrieve credentials only when a request is actually needed.
This distinction matters most when the agent can call sensitive APIs, operate across tenants, or act on behalf of multiple users. A bearer token inside the agent is a standing capability. An on-behalf-of flow turns access into a controlled transaction, which is easier to constrain to the current user, current task, and current authorization decision.
It also improves revocation logic. If a token is embedded in agent state, revoking access means chasing copies and cached sessions. If the server holds the sensitive token, the control point is centralized and the agent remains a requestor rather than a token custodian.
What changes in agent architecture and governance
On-behalf-of pushes the sensitive part of authorization into a server-side component that can authenticate the user, verify the agent request, and exchange or mint the downstream credential under policy. That lets teams apply stronger controls around delegation, consent, audience restriction, and token lifetime. It also gives security teams a clean place to log who approved the action, which resource was targeted, and what scope was issued.
This is especially important for agentic systems that chain tools or cross multiple systems. The right design is not “the agent has access,” but “the agent can request access on the user’s behalf under explicit policy.” A broker or backend can enforce that distinction consistently, rather than relying on every prompt path, tool wrapper, or plugin to behave perfectly.
In practice, on-behalf-of is one of the simplest ways to keep least privilege meaningful in an agentic workflow. Without it, developers often drift into broad client credentials or long-lived bearer tokens just to make the system work, and that convenience quietly erodes the control boundary.
Risk and Threat Considerations
When agents hold downstream tokens directly, compromise of the agent runtime can expose the entire delegated access path. That creates a classic bearer-token risk: the token becomes valuable anywhere it is copied, observed, or replayed, including logs, memory, and tool outputs.
Failure mechanism: The agent receives or stores a reusable token, then a prompt injection, tool abuse, memory leak, or code-path compromise causes that token to be disclosed or reused outside the intended request.
Impact: Attackers can impersonate the delegated session, expand access beyond the original task, and reuse the token until expiry or revocation, often with less visibility than a direct account takeover.
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 sets 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 controls agent delegation and privilege scope. |
| ASI02 — Tool Misuse | Token exposure through tools is a core agent misuse path. | |
| Recommendation — Enforce per-action delegated access and keep agent privilege narrowly scoped. Restrict tool-mediated access so tools never receive reusable downstream tokens. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | On-behalf-of relies on safer token handling and delegated authentication flows. |
| Recommendation — Use delegated auth flows that avoid placing long-lived credentials inside the agent. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | The downstream service must authenticate machine-to-machine delegated access correctly. |
| AC-6 — Least Privilege | On-behalf-of is primarily about reducing delegated privilege and blast radius. | |
| Recommendation — Authenticate service-to-service requests with scoped, auditable credentials. Grant only the minimum scope needed for the current user action. | ||
Practitioner Guidance
What to verify: Confirm that the agent never receives a downstream bearer token unless the token is short-lived, audience-bound, and strictly necessary for the request path. The safer pattern is a brokered exchange where the server, not the model runtime, controls the credential.
Decision rule: If the agent can complete the workflow by requesting scoped access per action, prefer that design over embedding a reusable secret in the agent context. If the token would unlock multiple downstream systems, treat it as a high-risk design smell.
Common mistake: Treating “the agent is acting for the user” as a reason to hand the agent the same token the backend would use. Delegation should narrow trust, not copy the full trust of the user session into the model layer.
Practitioner takeaway: The security win is not just delegation, it is keeping the sensitive credential outside the agent runtime so compromise of the agent does not become compromise of the delegated authority.