Use a credential broker or proxy so the agent can make authorised requests without ever handling the underlying tokens, API keys, or certificates. The agent should submit a request, and the broker should attach credentials on the outbound path. That keeps secret custody outside the agent runtime and reduces exfiltration risk from prompt injection or malicious content.
Why This Matters for Security Teams
AI agents are useful precisely because they can take action, chain tools, and operate at machine speed. That same autonomy makes direct secret exposure a high-consequence design flaw: once a token, API key, or certificate lives inside the agent runtime, prompt injection, malicious content, logging, and tool misuse all become viable paths to exfiltration. Current guidance from the OWASP Agentic AI Top 10 and NIST AI Risk Management Framework both point toward reducing unnecessary authority and constraining the agent’s blast radius.
NHI Management Group research shows why the issue is urgent: in The State of Secrets Sprawl 2026, AI-related credential leaks surged 81.5% year-over-year in 2025, and 24,008 unique secrets were exposed in MCP configuration files alone. That is the practical risk profile security teams are designing against, not a theoretical one. In practice, many security teams encounter secret exposure only after an agent has already copied a credential into a prompt, trace, or downstream tool call rather than through intentional review.
How It Works in Practice
The safest pattern is to keep the agent “credential blind” and move authorization into a broker, proxy, or execution gateway. The agent submits an intent, such as “read this ticket,” “open this repository,” or “call this API with these parameters,” and the broker decides whether to approve it and attaches the required credential on the outbound path. That preserves utility while keeping secret custody outside the model, orchestration layer, and prompt history.
In practice, this usually combines four controls:
- Ephemeral tokens with short TTLs, so each task gets a narrow credential window.
- Workload identity for the agent runtime, so the system knows what is making the request without embedding long-lived secrets in the agent.
- Policy-as-code for runtime authorization, so access is evaluated at request time rather than assumed from a static role.
- Broker-side logging and revocation, so suspicious requests can be blocked or terminated without waiting for the agent to finish.
This model aligns with CSA MAESTRO agentic AI threat modeling framework and the OWASP Non-Human Identity Top 10, both of which emphasize reducing standing privilege and governing machine identities as first-class subjects. The design also fits the recommendation in Guide to the Secret Sprawl Challenge: centralize issuance, reduce spread, and automate revocation rather than letting credentials proliferate across agent memory, files, and prompts.
Static IAM fails here because agents do not behave like humans with stable job functions. A single agent may browse, summarize, query, and act in one workflow, then pivot to a different tool chain minutes later. If the agent runtime ever sees the credential, the secret can be copied into a conversation, embedded in a tool request, or captured by an upstream plugin. These controls tend to break down when agents are allowed direct shell access or unrestricted MCP tool execution because the broker can no longer reliably mediate every outbound secret-bearing request.
Common Variations and Edge Cases
Tighter secret isolation often increases orchestration overhead, requiring organisations to balance developer speed against stronger control and more policy logic. Best practice is evolving, but current guidance suggests that not every agent needs the same level of isolation. A read-only retrieval agent may only need brokered access to a single API, while a transactional agent that can send email, modify records, or trigger infrastructure changes may need stronger approval gates, step-up policy checks, and tighter token lifetimes.
One common edge case is multi-agent workflows. If agents hand work to each other, the broker should authorize the workflow boundary, not each model message, otherwise secrets can leak between agents through shared context. Another edge case is systems that cache tool outputs for convenience. If those outputs contain credential material, the cache becomes part of the secret attack surface. NHI Management Group’s analysis in Analysis of Claude Code Security shows why AI-assisted development environments need extra scrutiny: the surrounding workflow, not just the model, often becomes the leakage path.
For teams implementing this pattern, the practical test is simple: if the agent can retrieve, print, or reuse the credential directly, the design is too permissive. If the agent can only request an action and the broker enforces the secret, the architecture is moving in the right direction.
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 CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Agentic systems need runtime limits on tool use and secret exposure. |
| CSA MAESTRO | M2 | MAESTRO addresses agent threat paths, including secret handling and tool abuse. |
| NIST AI RMF | GOVERN | AI RMF governance is needed to assign ownership for agent secret custody. |
Centralize credential issuance and enforce brokered access for every agent action.
Related resources from NHI Mgmt Group
- How should security teams manage permissions for AI agents?
- How should security teams govern AI agents that use OAuth access?
- How should security teams limit the risk from AI agents that have access to production systems?
- How should security teams use AI in secret scanning without creating new blind spots?
