How do MCP-based AI systems change zero trust assumptions?

Why This Matters for Security Teams

MCP changes the zero trust conversation because the risk no longer sits only at the user login layer. The model may be inside the environment, but the connector becomes the real enforcement point for every delegated action, secret lookup, and downstream API call. That means trust has to be continuously re-established at runtime, not inherited from the session that launched the workflow.

This is why zero trust still applies, but in a different place: authentication, authorization, and revocation must be designed around machine-mediated delegation. The control question becomes whether the connector is allowed to do this specific thing, in this specific context, right now. That lines up with the NIST SP 800-207 Zero Trust Architecture emphasis on continuous verification, and with NHIMG guidance on the identity layer behind autonomous systems in the Ultimate Guide to NHIs — Standards.

Teams often overestimate the safety of internal placement and underestimate the blast radius of a connector with broad scope. In practice, many security teams encounter abuse only after a connector credential or tool permission has already been used outside its intended task.

How It Works in Practice

For MCP-based systems, the zero trust model should shift from “is this user allowed in?” to “is this connector, workload, and request allowed to proceed?” The identity primitive is the workload, not the person. Current guidance suggests using cryptographic workload identity, short-lived credentials, and policy evaluation at request time so the system can make decisions based on task, destination, data sensitivity, and context. NHIMG’s Guide to SPIFFE and SPIRE is useful here because it frames identity as machine-verifiable proof of what the workload is, not just where it sits.

In practice, that means an MCP connector should not carry a standing bearer token with broad reuse. Instead, it should obtain ephemeral credentials per operation, with tight TTLs and automatic revocation after completion. Authorization should be evaluated with policy-as-code at runtime, using tools such as OPA or Cedar where appropriate, rather than relying on static RBAC alone. That is especially important when a connector can chain actions across multiple tools, because the real risk is not a single call but a sequence of calls that expands privilege.

• Bind the connector to a workload identity and rotate away from long-lived static secrets.
• Issue JIT credentials only for the requested action and scope.
• Evaluate each tool call against current context, not a pre-approved workflow.
• Log every delegation, revocation, and downstream API call for auditability.

This also aligns with the OWASP view of agentic risk in the OWASP Agentic AI Top 10, because the connector can become the point where tool abuse, prompt injection, and over-privileged delegation converge. These controls tend to break down when MCP is layered onto legacy integration stacks that depend on shared service accounts and broad network trust, because the connector inherits historical privileges faster than teams can re-architect them.

Common Variations and Edge Cases

Tighter delegation controls often increase operational overhead, so organisations have to balance runtime assurance against latency, developer friction, and policy maintenance. Best practice is evolving, but there is no universal standard for how much context an MCP gateway should inspect before authorizing a call. Some environments will require very strict approval chains, while others can tolerate lighter controls if the connector is low-risk and heavily constrained.

One common edge case is internal tool-to-tool traffic. Security teams sometimes assume “internal” means safe, yet MCP connectors frequently sit between systems with very different trust levels. Another is secret handling: if the connector can retrieve tokens, certificates, or API keys, then zero trust must extend to secret issuance and revocation, not just network access. That concern is reinforced by NHIMG research on AI credential abuse in the LLMjacking threat pattern, where compromised NHIs are used to hijack AI workflows.

Finally, autonomous or semi-autonomous agents make the problem harder because their request patterns are dynamic. The safest assumption is that any tool-enabled workflow can change course, chain actions, or retry in ways a human reviewer would not predict. That is exactly why zero trust for MCP must be enforced per request, not per session.

Related resources from NHI Mgmt Group

• When is it appropriate to implement MCP in the context of AI systems?
• Why do AI systems complicate zero trust assumptions?
• How should security teams govern AI systems that use both MCP and A2A?
• Why does MCP change the way IAM teams think about AI agent access?