MCP and Zero Trust: Verifying Every AI Agent Tool Call
MCP provides only a communication convention and does not solve trust; five zero trust checkpoints are needed to supplement every tool call.
The article argues that while MCP provides a standardized channel for AI agents to interact with external tools, its default assumption of trustworthy participants directly conflicts with the core zero trust principle of "never trust, always verify." The author maps NIST's seven zero trust principles to the MCP request path, identifying that the spec only covers message formats, tool discovery, and invocation semantics, while identity systems, policy engines, logging pipelines, and anomaly detection must be built at the platform layer. The article proposes five checkpoints every tool call should pass: identity verification, authorization decisions, context validation, result integrity, and audit logging—missing any one renders zero trust meaningless. The conclusion is that security investment cannot be deferred; checks must be embedded in the request path rather than remediated after the fact.
MCP Request Path's Trust Gap
AI agents are moving from demos to production, and the more capable they become at invoking external tools, the blurrier the security boundary gets. The Model Context Protocol (MCP) provides a standardized channel for agent-tool interaction, but the protocol itself does not solve the trust problem. Mapping NIST's seven zero trust principles onto the MCP request path reveals which capabilities the spec provides, which you must build yourself, and the five checkpoints every tool call should pass.
Trust Gaps Along the MCP Request Path
MCP defines how agents discover, invoke, and receive tool results, but it assumes participants are trustworthy by default. The request path typically includes: the agent initiates a call, the client forwards it, the server executes the tool, and the result is returned. Along this chain, identity, permissions, and context can all be forged or abused. The core assumption of zero trust is "never trust, always verify," which directly conflicts with MCP's default assumption.
According to the original analysis, the MCP spec provides a communication convention, not a security policy. An agent can invoke any registered tool, and a server can return arbitrary content. Without an additional verification layer, a hijacked agent or a malicious tool can move laterally within the system.
Model Context Protocol (MCP) is a standardized protocol proposed and open-sourced by Anthropic in late 2024, designed to unify how large language models interact with external tools and data sources. It uses a client-server architecture: the MCP client is embedded in the agent host and is responsible for establishing connections with MCP servers; servers encapsulate a tool or data source, exposing capabilities such as tool lists, resources, and prompt templates. The protocol defines message formats based on JSON-RPC 2.0 and supports semantics such as tool discovery (tools/list) and tool invocation (tools/call). Understanding this architecture helps clarify where trust gaps originate—MCP only specifies how messages are encapsulated and routed, not how the caller's identity is proven or how server capabilities are constrained, so identity forgery, tool impersonation, and result tampering all occur outside the protocol's semantics.
Mapping the Seven NIST Principles
NIST's seven zero trust architecture principles include: all data sources and computing services are considered resources; all communication is secured regardless of location; session-level access control; dynamic policy determines access; continuous monitoring of asset integrity; strict identity verification and authorization; and data collection for improving security posture. Mapping these principles one by one onto the MCP request path identifies which parts the spec covers and which are blank spots.
For example, Principle One requires treating all tools as resources, meaning each tool call needs an independent authorization decision rather than relying on network location. Principle Three requires session-level control, and MCP's session model needs additional mechanisms to bind identity to permissions. Principles Five and Seven involve continuous monitoring and logging, which typically fall outside the protocol's scope and require platform-layer implementation.
NIST Zero Trust Architecture comes from Special Publication SP 800-207 issued by the U.S. National Institute of Standards and Technology. Its core proposition is: no implicit trust should be granted based on network location (such as internal vs. external networks), and all access requests must undergo explicit verification and least-privilege authorization. The seven principles in this document form design guidelines for implementing zero trust, covering treating all resources uniformly, protecting all communication end to end, session-level access control, dynamic policy decisions, continuous monitoring of asset integrity, strict identity verification and authorization, and using log data for posture improvement. Unlike traditional perimeter defense models, zero trust separates the Policy Decision Point (PDP) from the Policy Enforcement Point (PEP), with the former centrally evaluating context before issuing authorization decisions. Applying this framework to the MCP request path essentially means inserting similar decision and enforcement stages between the agent and the server, rather than relying on the protocol's default assumption of mutual trust.
Five Checks Every Call Should Pass
The original article proposes that every AI agent tool call should pass five checkpoints to implement zero trust. These checks cover identity, authorization, context, data integrity, and auditability.
Identity verification: Confirm the identity of the agent initiating the call and the end user, rather than merely trusting client declarations. Authorization decision: Determine based on policy whether the agent has the right to invoke the tool and what scope of operations is allowed. Context validation: Check whether call parameters are consistent with the current task and session to prevent parameter injection or privilege escalation. Result integrity: Verify that the content returned by the tool has not been tampered with and conforms to the expected format. Audit logging: Record key events along the call chain for later tracing and posture analysis.
These five checks are not built into the MCP spec and must be implemented at the agent framework or gateway layer. The original article emphasizes that missing any one of them renders zero trust meaningless.
The Boundary Between Building and the Spec
Understanding what MCP provides and what must be built is a prerequisite for implementing zero trust. The spec provides message formats, tool discovery, and invocation semantics, but identity systems, policy engines, logging pipelines, and anomaly detection all need to be designed independently. The mapping diagram in the original article shows that among the seven principles, only a few map directly to spec features; most require platform capabilities to fill in.
For teams building AI agent systems, this means security investment cannot be deferred. Embedding zero trust checks into the MCP request path—rather than remediating after the fact—is the only way to keep agents controllable when invoking tools. The protocol is the channel; trust must be established through verification at every layer.
Policy engine is a core component in implementing zero trust, responsible for making allow, deny, or degrade decisions before each tool call based on identity, role, call parameters, session context, and risk signals. In the MCP context, policy engines are typically deployed as sidecar services or gateway plugins between the client and server, receiving call metadata and returning authorization results. Its relationship with the MCP spec is complementary rather than substitutive: the spec is responsible for expressing call intent in a structured way, while the policy engine applies rules to that structured request. A common engineering practice is to use a declarative policy language (such as Open Policy Agent's Rego) to describe "which agent, in what context, can invoke which tools with which parameter ranges," thereby decoupling policy from code and facilitating auditing and gradual adjustments. Without this layer, MCP tool calls degrade into unconstrained remote calls.
One-line Summary
MCP only provides a communication convention and does not solve trust; five zero trust checkpoints are needed to supplement every tool call.
Paragraph Summary
The article points out that while MCP provides a standardized channel for AI agents to interact with external tools, its default assumption that participants are trustworthy directly conflicts with the core zero trust principle of "never trust, always verify." The author maps NIST's seven zero trust principles one by one onto the MCP request path, identifying that the spec only covers message formats, tool discovery, and invocation semantics, while identity systems, policy engines, logging pipelines, and anomaly detection must all be built by the platform layer. Based on this, the article proposes that every tool call should pass five checkpoints: identity verification, authorization decision, context validation, result integrity, and audit logging—missing any one renders zero trust meaningless. The conclusion is that security investment cannot be deferred; checks must be embedded in the request path rather than remediated after the fact.
Related articles
WorkBuddy Step-by-Step Guide: Build Your Own AI Agent Work Assistant
WorkBuddy step-by-step guide: starting from the limits of chat models like Doubao, learn to build your own AI Agent work assistant for batch local file processing and automation—no programming required.
Building a Local Knowledge Base with LangChain-Chatchat + DeepSeek on Windows
This article, based on a Bilibili tutorial, details the full workflow of building a local knowledge base on Windows using LangChain-Chatchat and DeepSeek, including Anaconda environment setup, Ollama model management, mirror acceleration, and common error solutions, helping you quickly implement RAG Q&A.
Bilibili DeepAgents Practical Tutorial: From LangChain Basics to Agent Development
Bilibili DeepAgents tutorial practical analysis: from LangChain framework basics to agent development, covering the core path of building large model applications, including code implementation and learning advice, suitable for AI application development beginners.