Credential exposure becomes much easier, especially through prompts, logs, and debugging paths that were never designed to hold secrets. Once tokens are visible in those layers, the organisation has widened the attack surface and weakened the separation between authorization logic and model execution.
Why client-side token passthrough breaks the trust boundary
Once an agent token is allowed to travel through the client or the model, the token is no longer confined to the authorization path that issued it. It becomes part of the conversational and operational environment, which means every intermediate layer that can read, store, echo, or transform that content can also expose it.
This is why token handling must be treated as a boundary problem, not just a transport problem. The moment a token is visible to prompts, chat history, debug traces, or tool transcripts, the system has created additional places where access can be copied, replayed, or mishandled.
For systems that use delegated access, the distinction matters because the model should not become a de facto bearer-token relay. The Model Context Protocol: Authorization specification is useful here because it frames tokens as audience-bound credentials for the resource server rather than free-form context that can be passed through the client stack.
What fails operationally when tokens are visible to prompts and logs
Token visibility breaks several controls at once. Secret handling assumptions fail, logging hygiene fails, and the model boundary starts to overlap with authorization state. That overlap is dangerous because prompts and observability pipelines are usually optimised for retrieval and debugging, not for credential secrecy.
It also creates a hidden persistence problem. A token that enters a prompt, error payload, or diagnostic capture may outlive the session that produced it, so the exposure can continue long after the original interaction ended. The practical consequence is not just leakage, but a wider blast radius for anyone with access to transcripts, traces, or support tooling.
One useful way to think about this is that the organisation has moved from controlled authorization data to broad-readable operational data. That is precisely why the RFC 8707: Resource Indicators for OAuth 2.0 approach matters: it keeps tokens scoped to the intended resource instead of allowing them to circulate as generic proof of access.
When token passthrough is embedded in model workflows, even a well-meaning debugging step can become an exposure path. The RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP) model is relevant because it reduces the usefulness of a stolen token by binding it to the legitimate client's proof of possession.
Why the separation between authorization and model execution matters
Authorization logic should decide what the agent may do, while model execution should decide what the model can infer, compose, or call next. If a token crosses that line, the model becomes part of the access-control pathway, which makes it harder to reason about privilege, auditability, and revocation.
That separation is especially important for delegated flows, where the token may represent a user, an agent, or a service. A safer pattern is to keep the model on a need-to-know basis and let a dedicated authorization layer perform the token exchange or downstream call on its behalf. The RFC 8693: OAuth 2.0 Token Exchange specification supports that design by formalising delegation without exposing the original credential more widely than necessary.
That same principle also explains why token material should not be carried in free-text channels. If the client or model can reflect the token back into output, then the system has turned an access credential into content, and content is far easier to search, copy, export, and retain than a protected credential stream.
Risk and Threat Considerations
When tokens pass through the client or the model, the main risk is credential exposure through channels that are routinely broader than the original authorization boundary. That can turn a single delegated credential into a reusable secret across prompts, logs, tickets, and troubleshooting workflows.
Failure mechanism: The token is copied into intermediate text, cached output, or diagnostic telemetry, where it can be retrieved by users, operators, plugins, or downstream systems that were never meant to hold authentication material.
Impact: An attacker or careless insider can replay the token, impersonate the agent or user, and extend access beyond the intended session or target resource.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses 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 |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Controls token lifecycle and exposure risk for agent credentials. |
| AC-6 — Least Privilege | Limits what a leaked token can do if it is exposed through client or model paths. | |
| AU-9 — Protection of Audit Information | Logs and traces can become credential-exposure channels when tokens pass through them. | |
| Recommendation — Use IA-5 to restrict, rotate, and retire agent tokens before they reach logs or prompts. Apply AC-6 so any token exposed in the workflow has minimal usable privilege. Apply AU-9 to prevent audit data from retaining secrets embedded in model workflows. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Directly addresses secrets exposed through prompts, logs, and other handling paths. |
| NHI-07 — Long-Lived Secrets | Tokens that move through model paths often persist longer and become harder to control. | |
| NHI-10 — Human Use of NHI | Passing agent tokens through client or model layers often leads to unsafe human-visible handling. | |
| Recommendation — Eliminate secret leakage by keeping agent tokens out of prompts, logs, and debug output. Replace long-lived agent tokens with short-lived credentials and timely rotation. Prevent humans from copying or reusing agent tokens during debugging or support. | ||
Practitioner Guidance
What to verify: Confirm that no production token, refresh token, or long-lived bearer credential can appear in prompts, chat transcripts, application logs, or model traces. If the workflow must carry an access artefact, verify that it is audience-restricted, short-lived, and unusable outside the intended call path.
Decision rule: If the model or client can see the credential, treat that path as part of the attack surface and redesign it before relying on post hoc redaction. If the credential can also authorize other systems, escalate immediately because the blast radius is no longer limited to the original agent interaction.
Common mistake: Teams often try to solve this by masking secrets after the fact, but masking does not remove exposure from memory, telemetry, retries, exception dumps, or copied transcripts. The safer design is to keep the token out of model context entirely and use controlled delegation instead.
Practitioner takeaway: The critical question is not whether the token was encrypted in transit, but whether it ever became readable material inside a layer that was built to process language, not protect credentials.
Related resources from NHI Mgmt Group
- What breaks when an agent process stores model and GitHub tokens in its environment?
- What breaks when AI agent requests do not pass through a centralized enforcement point?
- What breaks when an AI agent can leave a test environment and contact real developers?
- What breaks when agent access is handled only through login controls?
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 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org