Teams should keep secrets out of the agent environment and retrieve them only at call time from a managed vault. That approach reduces secret persistence, narrows exposure if a tool is abused, and gives security teams a clearer place to enforce rotation, revocation, and audit.
Why This Matters for Security Teams
Secrets exposed to AI agents and MCP tools are not just a credential hygiene issue. They become an execution risk because agents can chain tools, repeat actions quickly, and surface tokens into logs, prompts, or downstream systems. Current guidance suggests treating agent access as a live control problem, not a static secrets-storage problem, especially when tool permissions change by task.
That is why NHI Management Group treats secret handling as part of the agentic attack surface, not an afterthought. Research from AI Agents: The New Attack Surface report shows that 80% of organisations report AI agents have already performed actions beyond intended scope, including revealing access credentials. When an agent can reach secrets, the blast radius is shaped by runtime behaviour, not just by who created the tool. Related NHIMG analysis of Guide to the Secret Sprawl Challenge shows why fragmented secret storage makes containment and audit harder.
In practice, many security teams discover secret exposure only after an agent has already copied, reused, or leaked a token through an MCP workflow, rather than through intentional design.
How It Works in Practice
The safest pattern is to keep secrets out of the agent runtime and fetch them only at call time from a managed vault. The agent should receive a short-lived credential or scoped token only for the specific tool action it needs, then lose access immediately after the task completes. That approach aligns with OWASP Agentic AI Top 10, which highlights prompt and tool abuse as a core risk, and with NIST AI Risk Management Framework, which pushes teams toward context-aware risk treatment.
For MCP tools, that usually means the tool server never stores long-lived API keys in the agent session. Instead, the agent requests access through a broker, the broker checks policy, and the vault issues a just-in-time secret with tight TTL and narrow scope. In mature setups, the secret is also bound to workload identity, so the system can verify what the agent is before granting what it may do. NHIMG’s Moltbook AI agent keys breach illustrates how exposed agent keys can scale into broad compromise when they are reused across workflows.
- Use a vault or secrets broker as the only retrieval point.
- Issue per-task, short-lived credentials rather than static tokens in prompts or configs.
- Scope secrets to one tool, one action, or one environment whenever possible.
- Log retrieval, use, and revocation events separately for auditability.
- Revoke on task completion, not on a calendar rotation alone.
This guidance breaks down in legacy MCP deployments where tools expect embedded static credentials and cannot be refactored to call a vault or policy engine at request time.
Common Variations and Edge Cases
Tighter secret controls often increase integration overhead, requiring organisations to balance safer runtime access against developer friction and tool latency. There is no universal standard for how every agent framework should broker secrets yet, so current guidance suggests choosing the least persistent option that still supports the workflow.
One common edge case is human-in-the-loop operation. If an agent drafts a request and a person approves execution, the secret still should not be exposed to the agent prompt or memory. Another is multi-agent pipelines, where one agent hands work to another. In those environments, secrets should stay attached to the calling workload identity and be re-evaluated at each hop rather than shared laterally. NHIMG research on Shai Hulud npm malware campaign and Reviewdog GitHub Action supply chain attack shows how quickly secrets spread when automation and trust boundaries are loose.
Best practice is evolving for agentic systems that need delegated access to SaaS, cloud APIs, or internal MCP tools. For those cases, use runtime policy checks, short TTLs, and explicit revocation hooks, then map the control set to the CSA MAESTRO agentic AI threat modeling framework and OWASP Non-Human Identity Top 10. These controls tend to break down when agents are allowed to cache credentials locally, because local persistence defeats revocation and expands post-compromise exposure.
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 | Agent/tool abuse is central to secret exposure in MCP workflows. |
| CSA MAESTRO | TA-2 | MAESTRO addresses agentic tool access and runtime control boundaries. |
| NIST AI RMF | AI RMF guides contextual risk treatment for autonomous agent access. |
Apply AI RMF governance to define secret handling, audit, and accountability for agents.
