Use federation and token exchange so the MCP server does not store reusable cloud keys. The access path should rely on short-lived tokens, explicit audience mapping, and scoped cloud roles, with the IdP acting as the source of user identity and the cloud provider enforcing authorisation.
Why This Matters for Security Teams
mcp server deployments tend to accumulate service account because every tool, environment, and tenant gets its own credential path. That pattern looks manageable early on, but it quickly creates opaque access, stale permissions, and hard-to-audit secrets. NHI Management Group’s research on the The State of MCP Server Security 2025 shows how common this drift has become, with only 18% of deployments implementing any form of access scoping for tool permissions. When the same server can reach multiple systems, reusable keys become a standing privilege problem rather than a simple authentication detail.
The more important issue is that MCP is often used by agentic workloads that change behaviour at runtime. Static service accounts do not express intent, so they end up being over-permissioned to avoid breaking workflows. That is exactly the kind of access sprawl highlighted in Ultimate Guide to NHIs — Key Challenges and Risks and in the OWASP Agentic AI Top 10, where uncontrolled tool access becomes a primary failure mode. In practice, many security teams discover service-account sprawl only after a token is reused outside its intended path or a single mis-scoped MCP server exposes more systems than anyone expected.
How It Works in Practice
The practical answer is to stop treating the MCP server as a credential vault and instead make it a federation boundary. The server should authenticate to cloud services through token exchange, short-lived credentials, and explicit audience mapping, so each request is tied to a specific identity, task, and destination. This is the same design logic underlying modern NHI governance: a workload proves what it is, receives only the minimum token needed, and loses that token quickly. The AI Agents: The New Attack Surface report shows why this matters for agentic systems, because autonomous behaviour can expand access far beyond the original request path.
Security teams should prefer a model where the IdP issues the user identity, the MCP server exchanges that identity for a scoped workload token, and the cloud provider enforces the final authorisation decision. That means no shared cloud keys in config files, no long-lived refresh tokens on disk, and no generic “server-admin” role reused across environments. Real-time policy evaluation also matters here: current guidance suggests policy-as-code enforcement is better than pre-defined access lists when MCP servers broker multiple tools and tenants. The NIST SP 800-53 Rev 5 Security and Privacy Controls and the OWASP Top 10 for Agentic Applications 2026 both reinforce the need for least privilege, scoped access, and continuous control. A short checklist is usually the best operational starting point:
- Use federation and token exchange instead of stored cloud keys.
- Bind tokens to a narrow audience and a single MCP workflow.
- Issue short-lived credentials per task, not reusable server secrets.
- Map each tool to a scoped cloud role, not a shared administrative role.
- Log token issuance, exchange, and revocation events for auditability.
These controls tend to break down when the MCP server must support many legacy tools that cannot validate audience-scoped tokens or when downstream platforms only accept static API keys.
Common Variations and Edge Cases
Tighter credential scoping often increases integration effort, requiring organisations to balance security gains against tool compatibility and operational overhead. That tradeoff is real, especially in mixed environments where some MCP-connected systems support OIDC or workload identity while others still depend on legacy secrets. Best practice is evolving, but there is no universal standard for this yet, which is why the strongest pattern is to isolate legacy exceptions rather than let them define the whole deployment.
One common edge case is multi-tenant MCP infrastructure, where a single server brokering requests for different teams can accidentally collapse identity boundaries. Another is ephemeral agent tooling, where short-lived tasks still need enough privilege to complete chained actions without opening broad standing access. In those cases, the safer design is to combine workload identity with fine-grained policy evaluation and revocation at completion, rather than extending token lifetime. The NHIMG Analysis of Claude Code Security is a useful reminder that tool-driven automation becomes risky as soon as permissions outlive the task. The right question is not how many service accounts the MCP server has, but whether any of them can persist beyond the exact workflow that created them.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Short-lived secrets and rotation directly reduce MCP service-account sprawl. |
| OWASP Agentic AI Top 10 | A3 | Agent tool access must be scoped because autonomous actions can expand beyond intent. |
| CSA MAESTRO | IAM-01 | MAESTRO emphasizes identity boundaries and least privilege for agentic integrations. |
| NIST AI RMF | AI RMF applies to runtime governance of autonomous systems and their access decisions. | |
| NIST CSF 2.0 | PR.AC-4 | Least privilege and access management are central to avoiding credential sprawl. |
Replace reusable MCP keys with federated, short-lived credentials and revoke them after each task.
Related resources from NHI Mgmt Group
- How do security teams decide whether to use OIDC federation or service-account keys for MCP access?
- How should security teams handle hardcoded credentials in MCP server deployments?
- How can organizations secure their MCP server credentials?
- How should security teams authenticate AI agents in enterprise environments?
