MCP and Agent Security
Securing MCP Servers: A Practical Guide
Securing an MCP server comes down to controlling three things: who is allowed to talk to it, what it is allowed to do, and which inputs it trusts. An MCP server is not a harmless plugin. It is a program that runs with full access to the agent's systems, data, and keys. That is exactly why every MCP server shifts an application's attack surface so significantly.
- Authenticate on every transport, never trust loopback, and check host and origin exactly (DNS rebinding).
- With OAuth, pin the authorization server and the origin of the metadata, and scope down to the minimum needed.
- Treat untrusted content and tool metadata as data, never as instructions (prompt injection and tool poisoning).
- Give every tool least privilege, and gate destructive and outbound actions behind confirmation.
- Never log, mirror, or forward secrets, and restrict outbound fetches to a host allowlist (SSRF).
- Ship safe defaults: no 0.0.0.0 bind, no wildcard allowlist, no shipped default keys.
Why an MCP server is a security risk
The Model Context Protocol (MCP) connects AI agents to tools, data, and APIs. The MCP server sits at exactly that seam: it accepts requests from the agent, calls real systems in the background, and returns the results. Two properties make it delicate. First, it runs with the operator's privileges and credentials, so a compromised server acts with full authority. Second, the model cannot reliably tell a legitimate user instruction apart from injected content that arrives through a data source, which is what makes indirect prompt injection possible.
The common vulnerability classes
The OWASP MCP Top 10, the first open security framework built specifically for MCP, has become the shared reference here. The overview below orders the classes by how often they show up in practice, and deliberately names no specific vulnerable products.
| Class | The core of the problem |
|---|---|
| Missing transport authentication | An endpoint with no auth, trusting that it only listens on loopback. Any local process, or a web page via DNS rebinding, then drives the tools with the operator's credentials (confused deputy). |
| Broken OAuth trust anchor | MCP uses OAuth 2.1. If the authorization server or the protected resource metadata is not pinned to a fixed origin, an attacker can redirect the token flow or force an overly broad scope. |
| Indirect prompt injection and tool poisoning | Tools return untrusted content or manipulated tool descriptions. Injected instructions reach the server's own writing or executing tools. |
| Over-broad permissions | A tool can do far more than the use case needs, for example the whole file system or arbitrary SQL. A single mistake then escalates to full access. |
| Secret and credential leakage | Tokens end up in logs, get mirrored, or are forwarded unchecked to a foreign destination. The reverse channel over sampling and elicitation belongs here too. |
| SSRF and unfiltered fetches | A tool loads a caller-supplied URL with no host allowlist and no block on internal addresses. |
| Insecure defaults | A 0.0.0.0 bind, a wildcard allowlist, DNS rebinding protection off, shipped default signing keys. The attack needs no exploit, just the unchanged default. |
| Denial of service | Unauthenticated session exhaustion or unbounded decompression takes the server down. |
The concrete hardening
Each class has a structural countermeasure. The checklist below is the core of the hardening work.
Control access
- Authenticate at every transport entry point, with a per-installation secret on every route.
- Bind to 127.0.0.1 by default, check host and origin exactly against an allowlist, and turn on DNS rebinding protection.
- With OAuth, pin the origin of the authorization server and the metadata, intersect the requested scope with the actual entitlement, and validate the token's audience.
Distrust inputs
- Clearly mark untrusted tool output as data, and never interpret it as instructions.
- Gate destructive and outbound tools behind explicit confirmation, and separate read rights from action rights.
- Serve server-initiated sampling and elicitation requests only with explicit user consent, never auto-filled with private context.
Limit the blast radius
- Scope every tool to the minimum of its use case, with no universal do-anything tool.
- Restrict outbound fetches to a scheme and host allowlist, block loopback, link-local, and internal ranges, and turn redirects off.
- Never log, mirror, or forward secrets, and broker calls on the host side so secrets never sit with the unvetted code.
- Start safe by default, enable risky modes only on explicit opt-in, and refuse to start in an obviously insecure combination.
How to check whether an MCP server is genuinely secure
Ticking off a checklist is not the same as knowing the controls hold. A pure pattern scanner finds the known-bad, but many MCP risks live in the design of capabilities and trust boundaries, not in known code patterns. Reliable security therefore needs two layers: a static check against defined invariants, and a dynamic check that backs each finding with an executed proof rather than merely assuming it. That discipline, verifying every individual finding before reporting it, is what separates a reliable report from a list of false alarms.
Is your MCP server reliably secure?
In a free initial call, we name the one property your product depends on and whether it is demonstrable. Every finding comes with a proof of concept, not a guess.
Book a free callCyberSec42 is an independent technical security assessment, not an accredited certification body.
Frequently asked questions
Is an MCP server a security risk?
Yes, as soon as it is not secured. An MCP server runs with full access to the operator's systems and credentials. Without authentication, least privilege, and protection against prompt injection, a compromised or misconfigured server can act with full authority.
How do I secure an MCP server?
Control three things: access (authentication on every transport, host and origin checks, OAuth pinning), permissions (least privilege per tool, confirmation for destructive actions), and inputs (treat untrusted content as data, prevent SSRF and secret leaks). Start safe by default.
What is the OWASP MCP Top 10?
The OWASP MCP Top 10 is the first open security framework built specifically for the Model Context Protocol. It lists the ten most critical risk classes for MCP servers and serves as a shared reference for developers and security teams.
Is a scanner enough to check an MCP server?
No, a scanner alone is not enough. Pattern scanners find known code patterns, but many MCP risks live in permission design and trust boundaries. The check only becomes reliable with an invariant-based analysis and an executed proof per finding.
Does my MCP server need a penetration test?
If the server has access to production data, systems, or credentials, yes. Ahead of the first large enterprise customer in particular, a reliable security assessment is often a procurement requirement.