Because they multiply credentials, authorization rules, and telemetry points across many connected systems. That creates identity sprawl, uneven privilege management, and weak visibility. The governance problem is not the protocol itself, but the number of independently managed trust relationships it introduces.
Why This Matters for Security Teams
MCP servers change the IAM problem because they sit at the boundary between an agent, a tool, and the systems that tool can reach. Each server can introduce a new trust relationship, a new secret, and a new authorization path. That means security teams are no longer governing one application identity and one set of entitlements, but many small control planes that may drift independently.
The risk is not limited to access sprawl. When an MCP server can broker calls into databases, ticketing systems, code repositories, or cloud APIs, it becomes a concentration point for privilege and telemetry. If governance is weak, a compromise can expose more than one workload. NHI Management Group’s 2024 Non-Human Identity Security Report found that 88.5% of organisations say their non-human IAM practices lag behind or are merely on par with their human IAM efforts, which is a strong signal that many teams are not yet ready for this level of distributed trust.
This is why MCP should be treated as an identity architecture issue, not just an integration pattern. The governance task is to define who or what can call the server, what the server can do on behalf of the caller, and how that delegation is monitored end to end. In practice, many security teams encounter MCP-related overreach only after a server has already been connected to several systems and inherited more privilege than intended.
How It Works in Practice
In practice, MCP servers often act as intermediaries for agentic workflows: an AI agent requests a tool action, the MCP server translates that request, and the downstream system sees the server’s identity rather than the original agent context. That translation is where IAM and NHI programmes can lose fidelity. If every server uses long-lived static secrets or broad API tokens, the result is a permanent trust bridge that is hard to inspect and even harder to revoke cleanly.
Current guidance suggests designing MCP access around workload identity and short-lived delegation. For example, an MCP server should authenticate with a cryptographic workload identity, while the agent session should receive only task-scoped privileges through NIST Cybersecurity Framework 2.0 aligned access governance. Where possible, use JIT credential issuance, narrow TTLs, and policy checks at request time rather than static allowlists that are defined once and forgotten. This is consistent with the direction described in the OWASP Agentic AI Top 10, which emphasises runtime misuse paths and tool access abuse.
Practically, teams should map each MCP server to a named owner, a bounded purpose, a documented secret source, and a revocation path. Pair that with central logging for every delegated action, including the original request context, so later reviews can answer whether the server acted within its intended scope. NHI Management Group’s Top 10 NHI Issues is useful here because it frames the broader challenge of secret sprawl, privilege drift, and missing visibility across machine identities.
These controls tend to break down when MCP servers are deployed as shared internal utilities across many teams, because ownership becomes diffuse and revocation decisions are delayed by dependency concerns.
Common Variations and Edge Cases
Tighter control over MCP servers often increases operational overhead, requiring organisations to balance faster integration against stronger identity discipline. That tradeoff becomes visible in federated environments, where different teams expose different servers, use different token issuers, or attach inconsistent logging standards.
Best practice is evolving for agent-to-server delegation. There is no universal standard for this yet, so teams should avoid assuming that a single PAM or RBAC layer will solve the problem. Static roles work poorly when an agent can chain tools, change intent mid-session, or request a sequence of actions that only becomes risky in combination. For that reason, many programmes are moving toward intent-aware authorisation, policy-as-code, and per-request evaluation, especially where MCP servers reach sensitive systems like source control or production data.
Edge cases are common in hybrid estates, cross-tenant deployments, and environments that already rely on shared service accounts. In those settings, the safer pattern is to treat MCP as a privileged integration tier: segment it, issue short-lived credentials, and make every trust relationship explicit. For deeper background on the broader NHI landscape, the Ultimate Guide to NHIs and 52 NHI Breaches Analysis both show how quickly machine trust can expand beyond original design assumptions.
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, OWASP Non-Human Identity Top 10 and CSA MAESTRO define the specific risk controls and attack patterns relevant to this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | MCP servers enable tool abuse and delegated action risks central to agentic security. |
| OWASP Non-Human Identity Top 10 | NHI-01 | MCP servers create new non-human identities and secrets that must be governed. |
| CSA MAESTRO | TA-03 | MAESTRO addresses agent trust boundaries and runtime control of autonomous tool use. |
Limit tool scope, validate intent at runtime, and log every delegated agent action.
