Pillar guide · MCP Security
MCP Security and Governance: The Complete Guide
The Model Context Protocol standardised how AI systems reach tools and data. It did not standardise who is allowed to use them. This guide covers the protocol, its real attack surface and the controls that belong around it.
The short answer
MCP security is the practice of controlling what an AI model can do through Model Context Protocol servers — authenticating the caller, scoping which tools it may invoke, validating parameters, treating tool output as untrusted input, and recording every execution. The protocol itself is a capability and transport standard; it does not decide who may call what, and it does not stop a model from being talked into calling something it shouldn’t.
What MCP is, precisely
The Model Context Protocol is an open standard for connecting AI applications to external capabilities. A host application runs an MCP client, which connects to one or more MCP servers. Each server advertises what it offers — tools it can execute, resources it can read, prompt templates it provides — and the client makes those available to the model.
Its value is exactly its uniformity: one integration pattern instead of a bespoke connector per system. That is also the source of its risk profile. A single standard interface makes it trivially easy to expand what a model can reach, and expansion is usually additive — teams add servers, rarely remove them, and almost never inventory the total capability surface they have assembled.
What the protocol does and does not define
Defined by MCP
- ›Tool, resource and prompt discovery
- ›Message format and transport
- ›Parameter schemas for tool calls
- ›Capability negotiation between client and server
Left to the implementer
- ›Who the caller is and how strongly that is proven
- ›Which tools that caller may use, and with what values
- ›Approval for high-consequence executions
- ›Rate limits, tenancy isolation and audit
The MCP attack surface
Five categories cover most of what goes wrong in practice. None of them are exotic; all of them are consequences of connecting a non-deterministic caller to real systems.
The server can do more than the use case needs
A server built to look up orders is given a database credential that can also update and delete them. The model now holds capability nobody intended to grant, and the only thing preventing misuse is that it hasn’t been asked yet.
Third-party servers run with your credentials
Installing a community server is a supply-chain decision. Its tool descriptions influence the model, its code handles your tokens, and an update can change both without review.
Long-lived secrets in local configuration
Server configs commonly hold static API keys on developer machines. They rarely rotate, rarely scope down, and are invisible to the systems that are supposed to track access.
The server acts with more authority than the requester
If a server uses one service account for every caller, a low-privilege user’s request executes with the service account’s privileges. Per-caller authorization has to survive the hop.
Nobody can reconstruct what was executed
Application logs show a chat session; target systems show a service account. Neither answers which agent invoked which tool with which parameters, or why it was permitted.
Why prompt injection is the hard one
The other four risks are configuration problems with known fixes. Indirect prompt injection is structural. A model reads content — a support ticket, a web page, a document, the output of another tool — and that content contains instructions. The model has no reliable way to distinguish data it was asked to process from instructions it was asked to follow.
MCP amplifies this because tool output flows back into context and tool descriptions themselves are model-visible text. An attacker who can influence any content the agent will read is attempting to steer the agent’s next tool call.
The realistic conclusion
There is no prompt that reliably immunises a model against injected instructions. So the control cannot live in the prompt. It has to live outside the model, where a request for an out-of-scope action is refused regardless of how persuasive the reasoning that produced it was. Injection resistance is an architecture property, not a model property.
Seven controls that belong around MCP
1. Authenticate the caller
Short-lived, verifiable identity per agent and per session. Not a shared key in a config file.
2. Scope tools per identity
Discovery should return only the tools that identity may use. Unlisted capability is capability that cannot be talked into existence.
3. Validate parameters
Bound the values, not just the tool name. A transfer tool with no amount ceiling is a different tool at 10 and at 10 million.
4. Treat tool output as hostile
Content returned from any external system is untrusted input, whatever the system’s reputation.
5. Approve consequential calls
Irreversible, financial and externally visible executions hold for a human decision.
6. Rate-limit and isolate
Per-identity ceilings contain runaway loops. Tenant isolation contains everything else.
7. Audit at the choke point
One record per execution, written where enforcement happens — not assembled later from three partial logs.
MCP server vs MCP gateway
An MCP server exposes tools from one system. A gateway sits in front of many servers as a single enforcement and routing point. The difference matters at the moment you have more than two servers: seven controls implemented seven times drift apart, and the weakest implementation sets your actual security posture.
Policy duplicated in every server. Each team implements auth its own way. Adding a server means re-implementing the same controls, and revoking an agent means touching every one.
One identity model, one policy set, one audit stream, one place to revoke. Servers stay simple and stay focused on the capability they actually provide.
Built on this thinking
Two products cover the two halves of this problem
Barzel Central Gateway is the single enforcement and routing point in front of your MCP servers. BarzelVault is the action-level permission, approval and audit layer that decides what passes through it.
A practical review checklist
Eight questions to ask about any MCP deployment. If more than two answers are unclear, capability is running ahead of control.
- 01Can you list every MCP server your agents connect to, and who approved each one?
- 02For each server, what is the widest action its credential permits — not the widest it is meant to use?
- 03Does each agent have a distinct identity, and can you revoke one without affecting the others?
- 04Which tool calls require human approval, and how was that boundary chosen?
- 05Are parameter values bounded, or only tool names permitted?
- 06If a tool returned text instructing the agent to exfiltrate data, what would stop the next call?
- 07Can you produce every tool execution from last Tuesday, with parameters and decisions, in one query?
- 08Are denied attempts recorded — and does anyone review them?
Frequently asked questions
Is MCP secure by default?
No, and it does not claim to be. MCP defines how a client and server exchange capabilities. Authentication strength, authorization granularity, approval and audit are the implementer’s responsibility.
What is the biggest MCP security risk?
Indirect prompt injection combined with over-broad tool scope. Untrusted content returned by one tool can influence the model into calling another tool it should never have been able to reach.
Can prompt engineering prevent injection?
Not reliably. Instructions in the prompt compete with instructions in the content. Enforcement has to sit outside the model, where an out-of-scope action is refused regardless of the model’s reasoning.
What is the difference between an MCP server and a gateway?
A server exposes tools from one system. A gateway sits in front of many servers as a single enforcement and routing point, applying identity, policy, rate limits and audit consistently across all of them.
How do you audit MCP tool calls?
Record every invocation at the enforcement point rather than inside individual servers: caller identity, server and tool, parameters, policy decision, approver if any, result status and timestamp — including denials.
Go deeper on MCP security
Six articles that take one section of this guide each and work it through in detail.
Sources and further reading
Primary specifications and standards this article relies on. Where a claim is our own judgement rather than something a standard states, the article says so in the text.
- 01 · MCP project Model Context Protocol — specification ↗ The normative spec, including capability negotiation and authorization.
- 02 · Anthropic / MCP project Model Context Protocol — official documentation ↗ Primary source for protocol structure, transports and tool definitions.
- 03 · OWASP GenAI Security Project OWASP GenAI LLM Top 10 (2026) ↗ Current consensus list of LLM application risks, including prompt injection and excessive agency.
- 04 · NIST SP 800-207: Zero Trust Architecture ↗ Where the policy-enforcement-point and policy-decision-point separation comes from.
- 05 · MITRE MITRE ATLAS ↗ Adversarial technique taxonomy for AI-enabled systems.
- 06 · Simon Willison Prompt injection — ongoing series ↗ The most consistently updated practitioner record of this attack class.
Last reviewed 18 August 2026. External links open in a new tab; we do not control their content.
Try it against a real server
To inspect what a real MCP server advertises — tools, resources, prompts — without signing up for anything, you can point a client at a public one. Barzel Scripture Intelligence is free and public at scripture-intelligence-server.mcpize.run — no signup, no key, 54 tools. A tools/list call takes about a minute and confirms your client works before you point it at anything that governs production. Setup is in the reference.
Reference documentation
Want the specification rather than the argument?
Transport, auth, capability enumeration and refusal semantics for every Barzel server.
Dev free · 10,000 calls/mo · paid plans from $199/mo on the MCPize marketplace
Written by
Mark Alex
Founder of Real Biz Digital and architect of the Barzel ecosystem — five MCP servers published and callable in public. Software developer, technology entrepreneur and mechatronics engineer, working across AI agent governance, MCP security, AI infrastructure, FinOps and intelligent operations.