MCP security is the practice of controlling which tool servers your AI agents connect to, what those servers can do with the agent’s credentials, and what gets logged. Register every server, verify its source, scope tokens to the narrowest permission, sandbox local servers, and review tool-call logs on a fixed schedule.
An AI agent is only as safe as the servers it plugs into. Each Model Context Protocol (MCP) server is code that your agent trusts to read files, query databases or call APIs on its behalf, and it inherits the access the agent hands it. Most security programs review the model and the prompt. Few review the third-party server that a developer connected on a Tuesday afternoon with a one-line config change. That server now sits inside your trust boundary with no owner, no review and no log.
Why are MCP servers a governance problem, not just an engineering detail?
An MCP server exposes tools and data to a model through a standard protocol. Every connection creates a new trust boundary between the agent, the server and whatever system the server touches. Three facts make this a governance issue.
First, connection is cheap. A developer can add a community server in minutes, which is exactly how unapproved servers appear. The OWASP MCP Top 10 names this risk directly as MCP09:2025, “Shadow MCP Servers”, and lists “Lack of Audit and Telemetry” as MCP08:2025. Second, servers hold credentials, so a weak one becomes a path to everything the token reaches. Third, servers shape what the model sees, which opens the door to manipulation. OWASP’s list of ten risks also covers tool poisoning, command injection, prompt injection through context and supply chain attacks. The OWASP project currently carries a beta status, so treat the list as a shared vocabulary that will keep evolving, and verify current text before you cite it in a policy.
If you already run a Shadow AI program, you have the right muscle. Our Shadow AI guide covers discovery of unapproved AI tools; MCP servers are the same problem one layer down.
Which attacks does the MCP specification itself warn about?
The MCP project publishes a Security Best Practices page that lists attack classes and the controls it expects. The page sits in the draft version of the specification, so check it again before you rely on specific wording. It is written for implementers, but a security or governance lead can use it as a checklist of questions to put to any vendor or internal team.
| Attack class | What goes wrong | Control the specification expects |
|---|---|---|
| Confused deputy | A proxy server with a static client ID lets an attacker skip user consent via a cached consent cookie | Per-client consent stored server-side, exact redirect URI matching |
| Token passthrough | The server accepts tokens not issued to it and forwards them downstream | The server must not accept tokens that were not explicitly issued for it |
| Server-side request forgery (SSRF) | A malicious server steers the client to internal addresses such as the 169.254.0.0/16 cloud-metadata range | HTTPS only, block private and link-local IP ranges, egress proxy |
| Local server compromise | A one-click install runs a hidden startup command with the user’s privileges | Show the exact command, require explicit approval, sandbox the process |
| State handle hijacking | An attacker guesses a workflow or cart ID and acts on another user’s state | Bind handles to the authenticated user, use random, expiring handles |
| Scope inflation | A token carries broad scopes such as files:* and becomes costly to lose | Start with minimal scopes and step up only when needed |
Token passthrough deserves special attention from governance teams. The specification explains that it breaks accountability: downstream logs show a different identity than the server that forwarded the request, so an investigator cannot tell who did what. That is an audit-trail failure, not only a security bug.
How do tool poisoning and prompt injection change the risk?
A model reads a tool’s name and description to decide when to call it. A malicious or compromised server can write that description to steer the model: to prefer its own tool, to pass along data the user never meant to share, or to call a second tool with side effects. OWASP lists this as MCP03:2025 “Tool Poisoning” and, separately, MCP06:2025 “Prompt Injection via Contextual Payloads”. The principle is simple. Anything the server returns, including its own description, is untrusted input to the model.
Three controls follow from that principle. Pin each server to a specific version so a silent update cannot change a tool description overnight. Re-review the tool list whenever the version changes. Require human approval before the agent calls any tool that writes data, sends messages or spends money. Our AI audit trails guide explains why those approvals need to land in a record someone can retrieve later.
What are the five controls that govern an MCP server?
The five controls below take a server from “someone connected it” to “we approved and monitor it”.
1. Register every server. Keep one register with six fields per server: name, owner, source (vendor or repository), pinned version, transport (local stdio or remote HTTP), and the systems and data it can reach. Sweep for servers you do not know about by checking client configuration files, developer machines, your identity provider’s OAuth grants and your API gateway.
2. Vet before you connect. Check who maintains the server, how recently it changed, what it depends on, and what permissions it requests. This is the supply chain risk OWASP lists as MCP04:2025. A community server with one maintainer and no release history gets a different answer than a vendor server under contract.
3. Scope credentials to the task. Use one credential per server and per agent. Avoid wildcard or catch-all scopes. The specification recommends a minimal starting scope set with step-up when a privileged operation first needs it, and it tells implementers to read its guidance alongside the IETF’s OAuth 2.0 security best practices (RFC 9700). A “search my drive” server needs read access to one folder, not write access to the whole drive.
4. Sandbox local servers. A local server runs with the privileges of the person who launched it. Run it in a container or restricted profile, limit its file-system and network access, and refuse any one-click setup that hides the command it will execute.
5. Log and review. Record every tool call with the agent identity, server, parameters, result and any human approval. The specification also recommends logging scope-elevation events with correlation IDs. Review the logs on a schedule, not only after an incident.
Who should approve a new MCP server?
Approval should scale with what the server can reach. The matrix below is illustrative; adjust the tiers to your risk appetite.
| Server class | Example reach | Approver | Review cadence |
|---|---|---|---|
| Read-only, public data | Documentation search | Team lead | Annual |
| Read internal data | Wiki, ticket history | Security review | Every 6 months |
| Write or send | CRM updates, email | Security plus system owner | Quarterly |
| Execute or move money | Shell access, payments | Security, owner and CISO | Quarterly, with a live drill |
Every row needs a named owner. A server with no owner is a server nobody patches.
Where does MCP governance fit in NIST AI RMF and ISO/IEC 42001?
No major framework has an MCP-specific chapter, so you map the controls to the structure you already use. This section states general principles; verify current text before citing any clause.
NIST AI RMF organizes work into Govern, Map, Measure and Manage. Put the server register and approval matrix under Govern and Map, since both describe who owns a component and what it touches, and put log review and drills under Measure and Manage. For teams certifying against ISO/IEC 42001, the same register supports asset inventory and supplier control expectations in an AI management system.
In the EU, the AI Act has no MCP rule, but its requirements for robustness and cybersecurity of high-risk systems (Article 15) are the natural home for these controls when an agent supports a high-risk use case. Verify current text for your specific use case. Our AI regulations overview maps the EU, NIST and US state requirements side by side for US and Canadian teams that operate across borders.
What can you do this week?
- Search developer machines, client configs and OAuth grants for MCP servers, and list each one with an owner.
- Mark every server that can write, send or execute, and pause any that has no owner.
- Pin versions and record the current tool list for each server you keep.
- Replace shared or wildcard credentials with one scoped credential per server.
- Turn on tool-call logging and pull one week of logs to confirm they identify the agent, the server and the parameters.
Key takeaways
- Treat every MCP server as third-party code inside your trust boundary, with an owner, a source and a pinned version.
- The specification’s own attack list (confused deputy, token passthrough, SSRF, local compromise, scope inflation) doubles as a vendor questionnaire.
- Approval depth should follow what a server can reach, and every tool call should leave a log an auditor can read.
Next step: See how Fruggr discovers unapproved AI tools and builds a single inventory, including agent connections.
FAQ
MCP security is the set of controls that govern how AI agents connect to Model Context Protocol servers: which servers are approved, what credentials they hold, how they are sandboxed, and how their activity is logged and reviewed.
It is an MCP server connected to an agent or client without security or governance approval. OWASP lists it as MCP09:2025. Discovery through client configurations, OAuth grants and gateway logs is the first control.
Token passthrough happens when an MCP server accepts a token that was not issued to it and forwards it to a downstream API. The specification forbids it because it bypasses security controls and blurs accountability in logs.
The AI Act has no MCP-specific provision. Its obligations attach to AI systems and their use cases, so MCP controls support requirements such as cybersecurity for high-risk systems. Verify current text for your use case.
Start with a sweep of client configuration files, developer machines and OAuth grants, then register each server with an owner, source, version, transport and reach. Pause anything that has no owner.
This article was drafted with AI assistance and reviewed by our editorial team before publishing.