Use a broker or proxy that injects credentials after the agent has formed its request, rather than placing secrets in the agent’s environment. That allows the agent to authenticate to services without ever seeing the real value, which narrows the blast radius of prompt injection and malicious ingestion.
How brokers and proxies change the credential problem in agent workflows
The key design shift is that the agent asks for an action, but it does not hold the secret needed to carry it out. A broker or proxy can add credentials at the point of execution, which keeps tokens, keys, and passwords out of the agent runtime while still allowing the workflow to complete. That separation is especially useful when prompts, retrieved content, or downstream tools may be untrusted.
Done well, this pattern reduces the chance that a prompt injection, poisoned document, or compromised plugin can simply read out a usable secret. It also makes it easier to rotate, scope, and revoke access centrally because the agent is no longer the long-term storage location for the credential.
Where credential exposure usually happens in agentic systems
Credential exposure is rarely just about a secret being stolen from a vault. In agent workflows, leakage often happens because the secret is placed in environment variables, tool configs, logs, prompt context, cached traces, or intermediary services that the agent can inspect or influence. Once the agent can see the secret, so can anything that can steer the agent.
This is why secret handling should be treated as an access design issue, not only a storage issue. If the agent can request a task without ever receiving the real credential, you remove several common failure paths at once: prompt-based disclosure, accidental echoing, downstream exfiltration, and overbroad reuse across tools or environments. NHIMG’s Guide to the Secret Sprawl Challenge is a useful companion for understanding how quickly exposed credentials multiply when they are copied into too many places.
In practice, the strongest pattern is least exposure by default: the agent sends intent, the broker resolves identity and privilege at execution time, and the target service receives a narrowly scoped, short-lived credential or assertion. That is materially safer than embedding persistent secrets in the agent environment and hoping the model never surfaces them.
How to apply the pattern without creating a new control gap
Brokered injection only helps if the broker is trusted to enforce policy, not merely to forward secrets. The broker must decide which action is allowed, which credential can be used, and how much privilege is appropriate for that specific request. Where possible, use short-lived, task-scoped access and keep the credential outside the model’s prompt, memory, and tool outputs.
- Prefer ephemeral tokens or delegated access over static API keys.
- Bind the injected credential to one service, one operation, or one session where feasible.
- Keep secrets out of logs, transcripts, and debug traces generated by the agent stack.
- Separate request formation from credential resolution so the model cannot copy or modify the secret itself.
That separation also helps with incident response. If the workflow is compromised, you can revoke the broker’s ability to mint or inject access without having to assume every agent prompt, cache, or conversation history is contaminated. For teams building around machine or service credentials, NHIMG’s Ultimate Guide to NHI and the OWASP Non-Human Identity Top 10 both reinforce why secret handling, rotation, and overprivilege need to be designed together.
Risk and Threat Considerations
When credentials live inside the agent environment, any successful prompt injection, malicious retrieval, or tool compromise can turn into direct secret disclosure. The danger is not only theft of one value, but reuse of that value across multiple systems, which widens blast radius and can turn a low-grade agent compromise into broader account abuse.
Failure mechanism: The agent is exposed to a secret it does not need for reasoning, then mirrors, leaks, or reuses it through prompts, logs, context windows, tool calls, or downstream integrations.
Impact: Attackers can authenticate as the workflow, pivot into connected services, and persist through long-lived or overprivileged credentials unless the broker limits scope and lifetime.
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, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while OWASP ASVS and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Agent workflows can expose secrets through prompts, logs, or tool outputs. |
| NHI-05 — Overprivileged NHI | Brokered injection should limit how much access the workflow can use. | |
| NHI-07 — Long-Lived Secrets | Static credentials in agent workflows persist long enough to amplify compromise. | |
| Recommendation — Keep secrets out of the agent runtime and inject them only at execution time. Scope injected access to the minimum privilege needed for the task. Replace persistent secrets with short-lived tokens or delegated access. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent workflows fail when identity and privilege are usable by the model itself. |
| Recommendation — Separate request generation from credential resolution and execution. | ||
| OWASP ASVS | V6 — Authentication | The pattern depends on keeping authenticators out of the application or agent context. |
| V8 — Authorization | The broker must enforce which actions a request may perform. | |
| Recommendation — Use strong server-side credential handling instead of exposing secrets to the client runtime. Authorize each agent action before any credential is injected. | ||
| MITRE ATT&CK | T1552 — Unsecured Credentials | Agent workflows are vulnerable when secrets are accessible in memory, files, or configs. |
| Recommendation — Hunt for and eliminate exposed credentials in agent tooling and supporting services. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Brokered credential injection is an IAM control pattern for machine access. |
| Recommendation — Centralize issuance, scoping, and revocation of credentials used by agent workflows. | ||
Practitioner Guidance
What to verify: Confirm that the model runtime never receives the raw credential, including through system prompts, tool metadata, retrieval results, or debug output. If the agent can print, store, or replay the secret, the control is weaker than it looks.
Decision rule: If a workflow needs access to production systems, use brokered, short-lived, policy-checked injection by default. If the task cannot tolerate that constraint, treat it as a higher-risk design and require explicit review of privilege scope, revocation speed, and auditability.
Common mistake: Teams often hide a secret in an environment variable and assume that makes it safe. In agentic systems, that still places the credential inside a process the model can influence through prompts, tool output, or chained actions.
Practitioner takeaway: The goal is not to make agents credentialless in every case, but to ensure the credential is introduced only at the moment of use, with the smallest possible scope and the easiest possible revocation path.
Related resources from NHI Mgmt Group
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 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org