IAM teams should inventory every MCP connection as a governed identity relationship, not a one-off developer convenience. The controls that matter are entitlement minimisation, approval for sensitive tools, periodic recertification, and clean offboarding. Without that discipline, MCP adoption simply multiplies machine identities faster than governance can catch up.
Why This Matters for Security Teams
MCP turns model access into a live identity relationship, which means every connector can become a new path to data, tools, and downstream systems. The IAM risk is not the protocol itself but the way teams treat each connection as a disposable integration instead of a governed NHI. NHIs already outnumber human identities by 25x to 50x in modern enterprises, and uncontrolled MCP growth only widens that gap. NHI Mgmt Group highlights the same pattern in its Ultimate Guide to NHIs, especially where visibility and lifecycle controls are weak.
This matters because MCP connections often carry broad tool access, long-lived secrets, and weak ownership. That combination is exactly how unmanaged service accounts and API keys become breach enablers. Security teams also have to account for the fact that agentic workflows can chain actions across multiple systems faster than human reviewers can reason about them. The practical risk is not just sprawl, but privilege accumulation that remains hidden until audit or incident response. Current guidance suggests using identity governance on every MCP relationship, not just on the underlying human developer account. In practice, many security teams encounter MCP sprawl only after a connector has already inherited production access and no one can say who approved it.
How It Works in Practice
IAM teams keep MCP from becoming unmanaged sprawl by treating each connection as a workload identity with a defined owner, purpose, scope, and expiry. That starts with inventory: every MCP server, client, and tool binding should be recorded as an identity relationship, then mapped to the business function it serves. The objective is to replace hidden trust with explicit lifecycle control, similar to the governance model described in the NHI Lifecycle Management Guide.
Operationally, the control pattern is straightforward:
- Assign each MCP connection a named owner and approval path.
- Minimise entitlements so the connector only reaches the tools it actually needs.
- Use just-in-time, short-lived credentials instead of static shared secrets.
- Require recertification for sensitive tools and revoke dormant connections quickly.
- Log tool invocation, token issuance, and revocation events for review.
That approach aligns with the direction set by the OWASP Agentic AI Top 10, which emphasizes tool misuse and over-privileged agent behavior, and with the NIST Cybersecurity Framework 2.0, which expects identity governance to be continuous rather than episodic. For MCP specifically, the best practice is evolving toward policy-driven authorization at request time, not blanket access granted at setup. This is where dynamic review matters: a connector used for read-only retrieval should not silently inherit write access later.
Controls tend to break down when MCP is embedded directly into developer tooling and no one maintains a separate asset inventory, because the connection starts behaving like invisible infrastructure instead of a governed identity.
Common Variations and Edge Cases
Tighter MCP governance often increases onboarding friction, requiring organisations to balance developer velocity against the cost of hidden privilege growth. That tradeoff is real, especially when teams want rapid experimentation with multiple models, tools, and environments.
There is no universal standard for MCP governance yet, so current guidance suggests using NHI lifecycle controls as the baseline and adapting them to agentic workflows. For low-risk read-only use cases, a shorter approval path may be acceptable if the connector remains tightly scoped and time-bound. For production systems that can trigger writes, approve transactions, or access customer data, the bar should be much higher: separate ownership, stronger recertification, and stricter secrets handling. The 52 NHI Breaches Analysis is useful context here because it shows how often identity failures are lifecycle failures, not just authentication failures.
One common edge case is shared MCP infrastructure across teams or environments. That model can reduce duplication, but it also makes attribution and offboarding difficult when a connector is reused beyond its original purpose. Another is ephemeral agent workflows, where credentials must exist only for the duration of a task. In those cases, static recertification alone is insufficient; runtime policy and automatic revocation become the real control points. Mature teams keep one rule in mind: if the connector cannot be explained, owned, and revoked quickly, it is already an unmanaged NHI.
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 | Agent tool misuse and over-privilege are central to MCP sprawl risk. |
| OWASP Non-Human Identity Top 10 | NHI-01 | MCP connectors should be governed as distinct non-human identities. |
| NIST AI RMF | AI risk governance is needed for autonomous MCP-enabled workflows. |
Apply AI RMF governance to define accountability, oversight, and lifecycle controls for MCP use.
