What is the difference between proxying delegated access and giving an AI agent the user’s access token directly?

Why This Matters for Security Teams

The distinction is not academic. When an AI agent is given the user’s access token directly, the token becomes part of the agent’s runtime surface and can be copied, replayed, logged, or chained into other tool calls. Proxying delegated access keeps the credential in a trusted control plane and lets the agent submit intent, which is safer for monitoring, revocation, and policy enforcement. That difference matters most when agents act across SaaS, data, and code systems where one overbroad token can span multiple blast radii.

This is why current guidance from the OWASP Agentic AI Top 10 and NIST AI Risk Management Framework increasingly treats agent permissions as a runtime governance problem, not a static login problem. NHIMG has documented how token exposure and reuse create durable compromise paths, including the CoPhish OAuth Token Theft via Copilot Studio case, where the issue was not just access but where trust boundaries failed.

In practice, many security teams discover token misuse only after an agent has already reused the credential in ways no human session ever would.

How It Works in Practice

Proxying delegated access means the agent asks for an action and a trusted intermediary decides whether that action is allowed, then executes it or issues a tightly scoped, short-lived credential. The agent should not see the underlying long-lived token unless there is a very specific, bounded reason. That is a better fit for autonomous systems because agent behaviour is dynamic, not pre-scripted, and static RBAC often cannot express what the agent is trying to do at the moment of the request.

In mature deployments, the control plane evaluates policy at request time using context such as task type, destination system, user approval, sensitivity of the resource, and risk score. This is where CSA MAESTRO agentic AI threat modeling framework and OWASP Non-Human Identity Top 10 both align with operational best practice: keep identity separate from execution, and issue authority only for the task window. Workload identity primitives such as SPIFFE, OIDC-backed workload tokens, or service-issued session credentials are better than passing user tokens into the agent because they prove what the workload is, not just what it borrowed.

• Use intent-based authorization for each tool call, not a blanket session grant.
• Keep user credentials in the broker, vault, or gateway rather than the agent runtime.
• Issue short-lived, task-scoped credentials only when the request passes policy.
• Log the approved intent, not the secret, so audit trails stay useful without expanding exposure.

NHIMG research on the LLMjacking pattern shows how quickly exposed credentials can be abused once they leave a trusted boundary. These controls tend to break down in legacy automations that expect a single, durable user token because the architecture assumes human session behaviour, not autonomous tool chaining.

Common Variations and Edge Cases

Tighter delegation often increases engineering overhead, so organisations must balance convenience against containment. There is no universal standard for how much context a proxy should evaluate yet, especially for multi-agent workflows, human-in-the-loop approvals, or cross-domain SaaS integrations. Best practice is evolving, but the direction is consistent: minimise credential exposure and maximise runtime control.

Some teams use a hybrid model where the proxy issues a short-lived token to the agent after policy checks, while others keep all privileged actions behind an API gateway or approval broker. That choice depends on whether the target system supports granular scopes, revocation, and usable audit logs. For high-risk actions, the safer pattern is to proxy the operation rather than hand out access at all. For lower-risk read-only tasks, ephemeral delegated access may be acceptable if the token is narrowly scoped and automatically expires.

Edge cases appear when agents need to act offline, across air-gapped systems, or inside brittle vendor APIs that do not support fine-grained delegation. In those environments, organisations should treat direct token sharing as an exception requiring explicit risk acceptance, compensating monitoring, and rapid revocation. NHIMG’s analysis of Salesloft OAuth token breach underscores why durable tokens become a liability once an attacker or agent can reuse them outside the original trust assumption.

Related resources from NHI Mgmt Group

• What is the difference between governing human access and governing AI agent access?
• What is the difference between human identity governance and AI agent governance?
• What is the difference between OAuth and token exchange for AI agent access?
• What is the difference between delegated user access and machine authority for AI agents?