MCP connections pull live data and tool access into one session, which expands the effective blast radius beyond a single application. The risk is not just the server itself, but the combination of credentials, scopes, and downstream systems it can reach. That creates a broader governance boundary than traditional point-to-point integrations.
Why This Matters for Security Teams
MCP changes the identity question because it turns a single integration into a live, tool-using session that can reach data, APIs, and downstream systems in real time. That means the security boundary is no longer just the application server or the model endpoint. It is the combination of workload identity, delegated scopes, secrets, and the tools exposed through the protocol.
For engineering teams, the practical risk is blast radius. If an MCP connection is over-permissioned, a model or agent can chain actions across systems in ways that are hard to predict with traditional IAM reviews. NHI guidance already shows why this matters: the Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is a strong signal that static permissions routinely outgrow their intended scope. Current guidance from OWASP Agentic AI Top 10 and the NIST Cybersecurity Framework 2.0 both point toward tighter access governance, but MCP makes that governance runtime-dependent rather than a one-time setup task.
In practice, many security teams encounter MCP risk only after a connector has already been granted broad access to production systems, rather than through intentional identity design.
How It Works in Practice
MCP is best understood as a control plane for model-to-tool interaction, not just a transport layer. When an AI assistant or agent connects through MCP, it may inherit access to file systems, ticketing platforms, source control, internal APIs, or observability tools. That makes the identity primitive more important than the integration itself. The key question becomes: what workload is this, what is it allowed to do right now, and how long should that permission exist?
Best practice is evolving toward workload identity, short-lived secrets, and runtime authorization. In mature setups, the agent or tool process authenticates with a cryptographic workload identity, then receives just-in-time access only for the task at hand. That access should be ephemeral, scope-limited, and automatically revoked when the session ends. This is why static RBAC often falls short. A role can describe a job function, but it cannot easily model an autonomous request that changes with context, tool output, or chained actions.
- Use workload identity as the primary trust anchor, not embedded API keys.
- Issue short-lived credentials per task, not long-lived tokens for the whole agent.
- Evaluate authorization at request time using policy as code.
- Log tool invocation, scope elevation, and downstream calls as separate events.
- Revoke access when the task ends, not on a quarterly review cycle.
NHI research reinforces the operational reality. The 52 NHI Breaches Analysis and the Top 10 NHI Issues both show how compromised machine identities and excessive privilege turn ordinary integrations into high-impact incidents. That is why MCP governance should be designed around least privilege, session scoping, and continuous verification, not just connector approval. These controls tend to break down when the MCP server brokers many upstream systems under one shared token because the platform can no longer distinguish safe tool use from privilege chaining.
Common Variations and Edge Cases
Tighter MCP governance often increases operational overhead, requiring organisations to balance developer speed against stronger session controls and secret handling. That tradeoff becomes more visible in fast-moving engineering environments, where teams want frictionless tool access and security teams want narrow, auditable permissions.
One common edge case is shared infrastructure. If multiple agents, services, or developer workflows reuse the same MCP endpoint, identity isolation becomes harder and revocation becomes less precise. Another is nested delegation, where the model invokes a tool that then calls additional systems. Current guidance suggests treating this as a new trust boundary at each hop, but there is no universal standard for this yet. The safest approach is to constrain each hop with its own policy and audit trail.
Security teams should also be cautious about assuming that a successful authentication event equals a safe connection. MCP can still expose excessive privilege if the underlying token has broad scopes or long TTLs. The risk is especially high when secrets are stored outside a secrets manager, when connectors are reused across environments, or when humans and agents share the same backend role. For teams formalising this model, OWASP Agentic AI Top 10 and the NIST Cybersecurity Framework 2.0 are useful starting points, but they need to be translated into runtime controls for MCP, not just policy language.
That guidance breaks down in highly distributed environments where MCP brokers many services and ownership of each downstream permission is unclear.
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 CSA MAESTRO 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 | A01 | MCP widens agentic attack paths through tool chaining and overbroad access. |
| CSA MAESTRO | T1 | MAESTRO addresses agent autonomy, orchestration, and tool-use governance. |
| NIST AI RMF | GOVERN | AI RMF governance applies to accountability and oversight of autonomous tool access. |
Assign ownership, review runtime decisions, and require auditability for every MCP-connected agent.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
