MCP security is the practice of governing what agents can reach through the Model Context Protocol: which servers are permitted, which individual tools on those servers are enabled, what credential each call carries, and whether a call that bypasses the governed path succeeds or fails. It is a separate problem from securing the model, because the model is not what touches the data.
The surface MCP creates
MCP makes tools addressable by models, which is what makes it useful. It also means a server any agent can call is a path into whatever that server can reach — a database, a ticketing system, a file share, a payment API.
Four properties make the surface awkward. Servers are easy to stand up, so an inventory goes stale fast. Tool descriptions are read by the model as instructions, which makes them an injection vector rather than documentation. Credentials are frequently shared across every agent using a server. And a tool that behaved yesterday can behave differently today if its definition changed — see tool poisoning.
The four questions a control has to answer
Which servers. A registry of approved servers, with unsanctioned ones blocked rather than merely absent from a list.
Which tools. Server-level approval is too coarse. A server offering read and delete needs those governed separately, and deny must override allow so a permissive rule cannot defeat a restrictive one.
Whose credential. If every agent shares one token, the audit record cannot attribute a call, and revocation is all or nothing — see agent authority scope.
What happens off-path. This is the one that decides whether the control is real. If an agent can call a server directly and succeed, the gateway is a convenience. If an ungoverned call fails, it is a control.
How it differs from API security
An API gateway authenticates a caller and rate-limits a route. That is necessary and it is not sufficient here, because the caller is a model acting on instructions it read somewhere, and the question is not whether it is authenticated but whether this action is inside the authority of the human the agent is acting for.
The other difference is content. A tool response comes back into the model's context and is trusted there, so MCP security has to inspect what returns as well as what is requested — the failure mode described under indirect prompt injection.
Smartflow governs MCP traffic through an inline JSON-RPC gateway with per-server tool allowlists and denylists, where a denylist entry overrides an allowlist. See platform capabilities, APERION Shield for the local runtime case, and the AI agent governance guide.
Related terms
Model Context Protocol · Tool poisoning · Agent authority scope · Model allowlist and deny-list · Full glossary
Put this in the path of your own agents.
Policy enforced inline between your agents and every model and tool they reach, with a record bound to the human who owns it.
Request a Demo Read the docs