Security teams should replace embedded client secrets with federated identity wherever the MCP server can validate signed claims from a trusted identity provider. That means using short-lived tokens, explicit issuer and audience checks, and workload-bound policies instead of reusable credentials. The goal is to make the access path verifiable without creating a secret to store or rotate.
Why This Matters for Security Teams
MCP deployments fail for the same reason many modern integrations fail: the secret becomes the trust anchor. Once a client secret is embedded in a server config, a container image, or a developer workstation, it can be copied, replayed, and reused far beyond the original intent. The better pattern is workload identity plus short-lived assertions, which aligns with the direction described in the OWASP Non-Human Identity Top 10 and NHIMG’s Guide to the Secret Sprawl Challenge.
This matters even more in MCP because configuration files can become a high-volume exposure point. GitGuardian reported 24,008 unique secrets exposed in MCP configuration files in 2025 alone in The State of Secrets Sprawl 2026, showing that protocol adoption can outpace hardening. Security teams should treat secret removal as a control redesign, not a cleanup task. In practice, many teams discover the problem only after a leaked credential has already been reused across multiple environments, rather than through intentional review.
How It Works in Practice
The operational goal is to stop treating the MCP server as a place where reusable credentials live. Instead, the server should validate cryptographic proof of identity from a trusted issuer, then make an allow or deny decision based on the workload, audience, and request context. That usually means OIDC-backed workload identity, signed tokens with tight TTLs, explicit issuer and audience validation, and policy that scopes access to a specific agent, service, or runtime.
For agentic and automated deployments, the safest model is usually just-in-time credential provisioning. The agent or workload receives a token only for the task it is actively performing, and the token expires as soon as the task ends. This reduces blast radius and supports zero standing privilege. Where the MCP server supports it, tie authorisation to intent rather than a broad role. That approach is consistent with the direction of the OWASP Agentic AI Top 10 and the governance model in OWASP Agentic Applications Top 10.
- Replace embedded secrets with workload identity assertions, not shared service accounts.
- Issue short-lived tokens per session or per tool invocation, then revoke them automatically.
- Validate issuer, audience, expiry, and workload binding on every request.
- Use policy-as-code for runtime decisions so access follows the current task, not a static role.
NHIMG research on secrets exposure also shows why this matters operationally: the Analysis of Claude Code Security and Reviewdog GitHub Action supply chain attack both illustrate how automation can amplify credential exposure when trust is encoded in static artefacts. These controls tend to break down when the MCP server sits behind legacy middleware that only understands long-lived API keys or cannot evaluate claims at request time because the platform does not expose runtime identity context.
Common Variations and Edge Cases
Tighter credential controls often increase integration overhead, so organisations have to balance lower secret exposure against more complex identity plumbing. That tradeoff is real, especially when MCP deployments span on-prem systems, third-party gateways, and older services that were never built for federated identity.
Current guidance suggests a phased approach when full secret removal is not immediately possible. Some environments may need a temporary bridge with tightly scoped, short-lived secrets, but that should be treated as an exception with an explicit exit plan, not the target state. Where an MCP server cannot validate signed claims natively, place the trust decision in a fronting gateway or sidecar that can enforce token checks, then pass only the minimum context downstream. For high-risk agentic workflows, pair this with the OWASP Top 10 for Agentic Applications 2026 and NJIMG? No. Use the Ultimate Guide to NHIs — Static vs Dynamic Secrets to separate what must be ephemeral from what should never exist as a stored secret at all.
There is no universal standard for MCP secret removal yet, so security teams should prioritise measurable outcomes: fewer stored secrets, shorter token lifetimes, explicit claim validation, and revocation that is automatic rather than manual. The hard cases are multi-tenant MCP servers, air-gapped deployments, and vendor connectors that only support bearer tokens because those environments often force a compromise between secure design and product constraints.
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 OWASP Non-Human Identity Top 10 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 | A3 | Agentic misuse often stems from static credentials and weak runtime checks. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Directly addresses lifecycle control for non-human credentials and secrets. |
| NIST AI RMF | AI RMF supports governance for autonomous workloads and their access decisions. |
Define ownership, monitoring, and accountability for MCP identity decisions at runtime.
