Because the integration usually runs on service accounts, API keys, or delegated tokens that are broader than the task requires. When those credentials are embedded in a tool bridge, a single compromise can expose cloud access, source code, or internal data. The issue is not AI novelty. It is standing privilege hidden inside automation.
Why This Matters for Security Teams
MCP integrations become NHI risks because they turn a software connector into an execution path with real authority. The bridge often authenticates with service accounts, API keys, or delegated tokens that were meant for a bounded task but end up reused across prompts, tools, and environments. That creates standing privilege inside automation, which is exactly where compromise becomes expensive.
NHIMG’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which helps explain why these integrations are so frequently overexposed. The danger is not just credential theft. It is that an MCP tool bridge can quietly inherit access to source code, cloud APIs, internal systems, and data stores without the same scrutiny applied to a human administrator.
That is why current guidance increasingly treats MCP as an identity problem, not only an application-integration problem. The emerging question is whether the connector can be constrained to the exact action, context, and time window needed for the task. In practice, many security teams encounter the risk only after a tool has already been linked to production data or a secrets store.
How It Works in Practice
Secure MCP design starts by identifying the workload identity behind the integration, then narrowing what that identity can do at request time. Static IAM roles are usually too coarse for autonomous or semi-autonomous tool use because the access pattern is dynamic. A connector may need to read one repository, query one dataset, or call one internal API, but not all three on every run.
Best practice is evolving toward short-lived, just-in-time credentials and runtime policy checks. That means issuing ephemeral tokens for a single task, binding them to a specific workload identity, and revoking them automatically after completion. Where possible, teams should prefer cryptographic workload identity such as SPIFFE/SPIRE or OIDC-based federation over long-lived shared secrets. For authorization, policy-as-code tools such as OPA or Cedar can evaluate what the MCP session is trying to do, rather than relying only on pre-defined role membership.
That control stack usually needs four pieces:
- Unique workload identity for the connector, not a shared service account
- Short TTL credentials scoped to a single tool invocation or session
- Least-privilege access to each downstream system
- Continuous logging of prompt, tool call, and secret usage for investigation
This matters because MCP links often sit inside developer tooling, automation pipelines, and assistant workflows where access is chained across multiple systems. NHIMG’s 52 NHI Breaches Analysis shows how frequently exposed identities become the path into broader environments, while the OWASP Agentic AI Top 10 reinforces that tool use and excessive agency are now core attack surfaces. These controls tend to break down when teams reuse one MCP credential across many tools, environments, or tenants because the blast radius becomes difficult to contain.
Common Variations and Edge Cases
Tighter MCP control often increases integration friction, requiring organisations to balance developer speed against revocation, approval, and observability overhead. That tradeoff is real, especially in fast-moving engineering environments where teams want assistants to work across Git, cloud, and ticketing systems without repeated prompts or reauthentication.
There is no universal standard for MCP identity governance yet, so current guidance suggests starting with the highest-risk connectors first: anything that can read code, manage infrastructure, access secrets, or move data externally. Read-only integrations are not automatically safe if the token can later be exchanged for a broader session, and delegated access can still become overbroad when the upstream grant is too permissive.
Another edge case appears when the integration sits behind a human user’s session. That pattern can mask the true non-human identity risk because the tool bridge inherits the user’s trust, then acts faster and more broadly than the user intended. For governance, the right control is to separate human intent from machine execution and treat the MCP connector as an independently managed identity. NIST Cybersecurity Framework 2.0 supports this by pushing asset visibility, access control, and continuous monitoring, but implementation still depends on the organisation’s ability to inventory every connector and revoke it cleanly. The model breaks down most sharply when connectors are embedded in CI/CD or self-service developer platforms because secret sprawl and shared privileges make ownership 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 | MCP tool bridges are an agentic attack surface with excessive autonomy and tool abuse risk. | |
| CSA MAESTRO | MAESTRO addresses identity, authorization, and orchestration risk in agentic workflows. | |
| NIST AI RMF | AI RMF covers governance and accountability for autonomous systems using tool access. |
Constrain MCP agents to least-privilege tool use, runtime policy checks, and scoped session boundaries.
