MCP security: how to secure Model Context Protocol servers and AI agents
The Model Context Protocol (MCP) has quietly become the USB-C of AI agents — one standard way to plug an agent into tools, data, and other systems. It's also one of the least-understood attack surfaces in modern software. When you connect an agent to an MCP server, you're letting an external system describe capabilities your agent will act on, and often handing it real power: file access, API calls, the ability to move data and money. Here's the complete security picture — what can go wrong, how, and how to lock it down.
What MCP actually exposes
An MCP server advertises tools to your agent — each with a name, a description, and a set of inputs. Your agent reads those descriptions and decides what to call. That's the whole trust model, and it has two soft spots: the descriptions are input your model acts on (not just documentation), and the tools often come from servers you don't control. Connecting an MCP server is closer to installing a browser extension with broad permissions than to calling an API.
The main attack classes
Tool poisoning (tool-spec injection): a malicious tool description carries hidden instructions the agent follows — the description is the payload, no software bug required. Prompt injection via tool outputs: data a tool returns (a webpage, a database row) contains instructions that hijack the agent. Over-broad scope and the confused deputy: a tool with more permission than it needs gets tricked into using it. Supply chain: a third-party server, or a dependency that ships one, is compromised. Read-then-exfiltrate chains: one tool reads sensitive data, another makes network calls, and the agent is steered to bridge them. And rug pulls: a server quietly changes a tool's behaviour after you approved it.
Why your existing security tools miss this
A code scanner looks at your code. Most MCP risk doesn't live in your code — it lives in your agent's runtime behaviour and in external servers' descriptions and outputs. That's a moving target a static scan can't see. This is the same blind spot that makes AI agent forensics necessary: prevention tools look at the surface, but the question with an agent is what it actually did at runtime.
How to secure MCP — a checklist
Pin and review the exact tools and servers your agent can use, and where they come from — treat adding a server like adding a dependency. Give each tool the minimum scope it needs. Isolate tools that read sensitive data from tools that can make network requests, so there's no read-then-exfiltrate path. Treat every tool description and every tool output as untrusted input, never as instructions. Require human approval for high-impact actions. And record what the agent did, so you can review and reconstruct it later.
The part most guidance skips: forensics
Every control above is prevention — and prevention sometimes fails, especially against an attacker who only needs to win once. When an agent does something unexpected through MCP, you need to answer a different question: what exactly did it do, and why? That's AI agent forensics — a tamper-evident, reconstructable record of the agent's prompts, tool calls, and outcomes. Without it, an MCP incident is a guessing game.
Where Opviva fits
Opviva is a security agent you talk to. Describe what you shipped and it secures the app around your agent — exposed secrets, missing access control, and public config are what turn a hijacked agent into a real breach, and a free scan finds those on your live app, proving each one is really exploitable before it opens the fix as a pull request you approve. And Opviva's Flight Recorder keeps the tamper-evident record of what your agent did over MCP, so when something slips through, you can reconstruct it instead of guessing. That's the proof mechanism behind everything Opviva does: it doesn't just flag a risk, it shows you the evidence, then fixes it, then keeps watching.
Frequently asked questions
What is MCP security?
MCP security is protecting AI agents that connect to tools via the Model Context Protocol. It covers the new risks MCP introduces — poisoned tool descriptions, prompt injection through tool outputs, over-broad permissions, and compromised third-party servers — plus recording what the agent did so incidents can be reconstructed.
Can an MCP server be hacked?
Yes. A malicious or compromised MCP server can poison tool descriptions to hijack your agent, exfiltrate data through tool calls, or change a tool's behaviour after you approved it. Because the agent acts on the server's descriptions and outputs, a hostile server is effectively giving your agent instructions.
How do I secure an MCP server?
Pin and review the exact tools and servers your agent uses, give each tool least-privilege scope, isolate data-reading tools from network-capable ones, treat all tool descriptions and outputs as untrusted input, require human approval for high-impact actions, and keep a tamper-evident record of what the agent did.