Notifications
Clear all
Topic starter
07/06/2026 7:56 pm
TL;DR: OIDC federation and workload identity remove client secrets from production MCP flows by validating signed identity assertions, claim-based trust and short-lived credentials instead of shared keys, according to Clutch Security. The governance shift is bigger than authentication: access review assumptions break when trust is proved by runtime claims, not static credentials.
NHIMG editorial — based on content published by Clutch Security: Part 2: Beyond Authentication for Production MCP Security
By the numbers:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
- 69% of organisations now have more machine identities than human ones.
Questions worth separating out
Q: How should security teams remove secrets from production MCP deployments?
A: Security teams should replace embedded client secrets with federated identity wherever the MCP server can validate signed claims from a trusted identity provider.
Q: Why do client secrets create risk in MCP environments?
A: Client secrets create risk because they are persistent, copyable, and often reused across pipelines, workloads, and downstream APIs.
Q: What breaks when MCP tool permissions are scoped too broadly?
A: Broad scoping breaks least-privilege governance because the same workload can invoke tools and reach resources far beyond its actual role.
Practitioner guidance
- Eliminate reusable client secrets from MCP paths Replace static client credentials with OIDC federation wherever the server and calling workload can validate signed claims.
- Bind tool access to workload context Scope MCP permissions to issuer, audience, subject, repository, branch, and environment claims so the same token cannot be reused outside its intended runtime.
- Remove token pass-through to downstream APIs Stop forwarding inbound tokens unchanged to other systems, because that collapses the trust boundary and creates confused-deputy risk.
What's in the full article
Clutch Security's full blog covers the operational detail this post intentionally leaves for the source:
- Exact claim-validation patterns for Azure Entra ID, GCP, AWS, and GitHub Actions trust relationships
- Checklist guidance for running MCP servers in isolated, containerised environments with restricted egress
- Operational steps for automating token lifecycle management and periodic scope audits
- Implementation detail on server reputation, version pinning, and supply-chain review for MCP deployments
👉 Read Clutch Security's production MCP security guide on OIDC federation and workload identity →
Production MCP security without secrets: is federation enough?
Explore further
07/06/2026 9:41 pm
Zero-secrets MCP is a governance model, not just an authentication pattern. Once identity is proven through federated claims, the security conversation shifts away from secret custody and toward trust-policy design. That matters because MCP servers sit at the intersection of AI clients, cloud workloads, and downstream APIs, which means a single access mistake can propagate quickly. Practitioners should treat federation as the baseline for how non-human access is governed, not as a feature add-on.
A few things that frame the scale:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to Astrix Security's The State of MCP Server Security 2025.
- In the same research, 53% of MCP servers expose credentials through hard-coded values in configuration files, which shows how quickly static trust becomes exposure.
A question worth separating out:
Q: Who is accountable for MCP access when identity is federated?
A: Accountability stays with the team that defines the trust policy and the resource owner that grants access, not with the identity provider alone. Federated identity changes how access is proven, but it does not remove governance obligations around scope, revocation, and monitoring. Organisations still need clear ownership for every MCP trust relationship.
👉 Read our full editorial: OIDC federation for production MCP security: why secrets disappear
