Scope
This guide focuses on secrets management for environments where AI agents access enterprise systems through Model Context Protocol (MCP) servers. You'll find guidance for securing credentials, API keys, and tokens that MCP servers use to connect AI assistants to your databases, APIs, and internal tools.
This isn't a general secrets management guide. It assumes you already rotate credentials and use a secrets manager. The new challenge: AI agents now act as autonomous identities that can request, use, and potentially leak secrets without direct human oversight.
Key Concepts
MCP Server: An intermediary service connecting AI assistants to external tools and data. Introduced by Anthropic as an open standard, MCP servers translate AI requests into API calls, database queries, or file operations.
Agent Identity: Unlike a service account that executes predefined tasks, an AI agent interprets natural language instructions and decides which operations to perform. When you give an agent access to an MCP server, you're granting it decision-making authority over whatever that server can reach.
Prompt Injection Surface: Any user input that influences agent behavior becomes a potential attack vector. If an attacker can manipulate the prompts your agent receives, they can potentially redirect it to exfiltrate secrets or execute unauthorized commands.
Requirements Breakdown
Your existing compliance frameworks don't explicitly address MCP servers yet, but several requirements apply:
PCI DSS v4.0.1 Requirement 8.3.2: Restrict access to authentication credentials to only those with explicit need. An AI agent with broad MCP access violates this if it can reach secrets it doesn't actively use.
NIST 800-53 Rev 5 IA-5: Authenticator management controls require you to protect credentials from unauthorized disclosure. Configuration files containing plaintext secrets fail this control, regardless of whether a human or agent uses them.
ISO 27001 Control 5.15: Access control to information and systems must enforce least privilege. MCP servers that grant agents access to entire secret stores instead of specific credentials create compliance gaps.
Vulnerabilities MCP Introduces
MCP servers create three new exposure paths that traditional secrets management doesn't address:
Configuration file leakage: MCP servers typically read connection details from JSON or YAML files. If these files contain plaintext credentials, they're readable by anyone with filesystem access, including the AI agent itself, which can be instructed to read and repeat file contents.
Over-permissioned agent access: When you configure an MCP server to connect to your secrets manager, you choose what the server can retrieve. The risk: granting access to an entire vault because it's simpler than scoping to specific secrets. Now your agent can request any credential in that vault through natural language.
Command injection via untrusted servers: CVE-2025-6514 demonstrated that connecting to a malicious MCP server can trigger OS command injection through mcp-remote, potentially leading to remote code execution. If your agent connects to third-party MCP servers, their vulnerabilities become yours.
Implementation Guidance
Centralize Secret Storage
Move every credential your MCP servers use into a secrets manager. This isn't optional when AI agents are involved. You need a single control plane where you can:
- Audit which secrets each agent accessed
- Rotate credentials without updating configuration files
- Revoke access immediately if an agent behaves unexpectedly
Tools like Keeper Secrets Manager or HashiCorp Vault provide APIs that MCP servers can query at runtime instead of reading static files.
Scope Agent Permissions Granularly
For each MCP server, document:
- Which specific secrets it needs (not which vault or folder)
- Why the connected agent needs each credential
- How often those credentials get used
Then configure your secrets manager to return only those specific items. If your agent needs database read access, it gets the read-only credential, not the admin password that happens to live in the same folder.
Implement Short-Lived Credentials
Static API keys that never expire are dangerous when agents use them. Configure your MCP servers to:
- Request time-limited tokens from your secrets manager
- Refresh tokens before expiration
- Never cache credentials longer than necessary
If your secrets manager supports it, issue credentials that expire after 1-4 hours. When an agent session ends, those credentials become worthless.
Validate MCP Server Sources
Before connecting an agent to any MCP server:
- Verify the server's code if it's open source
- Run it in a sandboxed environment first
- Monitor its network connections for unexpected destinations
- Review its dependencies for known vulnerabilities
Don't trust that a server is safe because it appears in a marketplace or registry. The mcp-remote vulnerability showed that even widely-used servers can introduce critical risks.
Monitor Agent Secret Access
Your SIEM should track:
- Which agents requested which secrets
- When requests occurred (watch for after-hours access)
- How many secrets an agent accessed in a session
- Failed authentication attempts from agent identities
Alert when an agent requests secrets it hasn't used before or accesses significantly more credentials than its baseline pattern.
Common Pitfalls
Treating agents like service accounts: Service accounts follow predictable patterns. Agents don't. If you grant an agent the same broad access you'd give a trusted service, you've created an unpredictable attack surface.
Assuming prompt injection only affects output: Attackers don't just want to manipulate what agents say, they want to control what agents do. If your agent can access secrets, prompt injection can potentially redirect it to exfiltrate those credentials.
Relying on network segmentation alone: You might isolate MCP servers in a protected network segment, but agents can still be instructed to read configuration files or dump environment variables containing secrets.
Skipping rotation because "agents need stable credentials": This is backwards. Because agents are harder to audit than traditional applications, you need faster rotation, not slower.
Quick Reference Table
| Security Control | Traditional Apps | MCP-Connected Agents |
|---|---|---|
| Credential storage | Secrets manager or config files | Secrets manager only (no static files) |
| Permission scope | Role-based (broad categories) | Secret-specific (individual items) |
| Credential lifetime | 90 days typical | 1-4 hours recommended |
| Access monitoring | Periodic review | Real-time alerting required |
| Trust model | Verify server code | Verify server + validate agent behavior |
| Rotation frequency | Quarterly | Daily or per-session |
| Network controls | Segment by environment | Segment + validate MCP server sources |
Start with one MCP server. Move its credentials to your secrets manager, scope permissions to specific secrets, and implement monitoring. Once you've validated the pattern works, expand to other agents. Don't wait until you're running dozens of MCP servers to discover you can't track which agent accessed what.
