The security boundary moved. With a chatbot, the question was what the model can say. With an agent on MCP, the question is what the agent can do. You are not securing an API call anymore. You are securing a reasoning loop that reads untrusted content and then acts on your systems. That is a harder problem, and the table below frames it.
| Threat | Transport hardening | Governed semantic execution |
|---|---|---|
| Tool poisoning | Can verify the publisher, not the tool's intent | Agent calls approved capabilities, not free-form tools |
| Indirect prompt injection | Filters some payloads | Untrusted content cannot authorize a query it is not entitled to run |
| Data leakage, cross-tenant | Encrypts the pipe | RBAC, row-level security, masking enforced before execution |
| Wrong-but-valid SQL | No control | Intent compiled to deterministic, governed SQL |
| Forensics | Logs the call | Full audit: intent, query, data touched, and decision |
The overlap in the last two rows is the story. The same bad query is simultaneously a wrong answer and a data-exposure event. Fix that, and you fix the part transport security cannot reach.
Why MCP security is not API security
An API call is fixed. A developer wrote it, reviewed it, and shipped it. An MCP agent call is generated at runtime by a model that just read a web page, a support ticket, or a GitHub issue. The instruction set is not trusted, and the action is real. Securing that means governing what the agent is allowed to do, not just how it connects. This is the same boundary we draw in MCP connectivity versus governance.
Risk 1: Tool poisoning
Tool poisoning was coined by Invariant Labs (Beurer-Kellner and Fischer) on 2025-04-01. The mechanism is simple and nasty. An attacker hides instructions in a tool's description or metadata. The model reads the description, treats the instructions as commands, and obeys. The user sees a normal tool name and never sees the payload.
The proof of concept was concrete: a poisoned "add" tool exfiltrated an mcp.json config file and SSH keys. OWASP now lists this as MCP03:2025 in its MCP Top 10. A registry cannot catch it, because a listing does not inspect what a description tells the model to do.
Risk 2: Prompt injection, direct and indirect
Direct injection is a user typing an attack. Indirect injection is the dangerous one: the attack rides in content the agent reads while doing its job.
Two named cases show how it plays out. In the GitHub MCP exploit (Invariant Labs, 2025-05-26), a malicious issue in a public repository hijacked an agent that was asked to review issues. The agent pulled private-repo data and leaked it through a public pull request. Invariant was explicit: the vulnerability does not require the MCP tools themselves to be compromised. It is a toxic agent flow, an architectural problem, not a bug in one tool.
In the Supabase MCP case (General Analysis, July 2025), the MCP server ran with a service_role that bypassed row-level security. An injection planted in a support ticket made the agent run SQL and leak tokens. The agent had private data, it read untrusted content, and it had a way to send data out. Simon Willison named that combination the lethal trifecta on 2025-06-16: private data, untrusted content, and an exfiltration channel in one agent.
Risk 3: Data leakage and cross-tenant exposure
The clearest enterprise lesson of 2025 was not a clever hack. It was a logic bug.
In June 2025, an access-control flaw in Asana's MCP feature exposed data from about 1,000 organizations to other tenants: tasks, project metadata, comments, and files, bounded by each user's permissions. The feature launched on 2025-05-01, the flaw was found on 2025-06-04, and access was restored on 2025-06-17. This was not prompt injection and not an external attacker. It was over-broad access plus weak tenant isolation, shipped fast. That is the failure mode governance exists to prevent.
The numbers
Named cases set the shape. Hard numbers set the scale.
- CVE-2025-6514 in the
mcp-remoteclient scored CVSS 9.6. It allowed remote code execution through a malicious server. The package had 400,000+ downloads and was fixed in 0.1.16, published 2025-07-09. - CVE-2025-49596 in Anthropic's MCP Inspector scored CVSS 9.4, also remote code execution. It was published 2025-06-13 and fixed in 0.14.1.
- Elastic Security Labs (2025-09-19) found 43 percent of tested MCP implementations had command-injection flaws and 30 percent allowed unrestricted URL fetching.
- Knostic (2025-07-17) found 1,862 MCP servers exposed to the internet. Of 119 it verified, all 119 exposed tool listings with no authentication.
- Palo Alto Unit 42 (2025-12-05) documented new injection vectors through MCP sampling: resource theft, conversation hijacking, and covert tool invocation.
For the authority signal, the OWASP Top 10 for Agentic Applications shipped on 2025-12-09, and the canonical academic survey is arXiv 2503.23278, now in ACM TOSEM.
A practical MCP security checklist
Harden the transport. Then govern the execution. Both, in that order, and do not stop at the first.
- Authenticate every server. No public MCP endpoint should list tools without auth. Patch known client CVEs.
- Pin and review tools. Treat a tool description as executable input. Version it, diff it, and re-approve on change.
- Break the trifecta. Do not give one agent private data, untrusted content, and an open exfiltration path at once.
- Drop the service role. Never run an MCP data server with a role that bypasses row-level security.
- Enforce access before the query. RBAC, row-level security, and masking must run at compile time, not after the answer.
- Expose capabilities, not raw SQL. Replace a
run_sqltool with governed, approved operations. - Audit everything. Log intent, compiled query, data touched, and the access decision, per call.
Why raw database access over MCP is uniquely dangerous
A raw SQL tool combines two failures into one event. The model can write a query it should not, and it can write a query that is simply wrong. On Spider 2.0, top models solve only 10.1 to 17.1 percent of real enterprise text-to-SQL tasks. On BIRD, the best system reaches 81.95 percent with oracle knowledge, still under the 92.96 percent human baseline. A confident, wrong number and an unauthorized read are the same category of failure: the agent did something it should not have. We unpack the accuracy half in the text-to-SQL accuracy cliff.
The safer pattern: MCP plus governed semantics
Two objections, answered straight.
"MCP gateways and the OAuth auth spec fix this." They materially reduce transport risk: confused-deputy attacks, token passthrough, and exposed servers. Concede that. They govern the door, not the query. None of them stop an entitled-looking agent from running an over-broad or misjoined query on data the user should not see.
"Just do not expose raw SQL tools." Agreed. That is the whole point. Expose governed capabilities instead of a run_sql tool, and enforce access at execution. That is the bridge to a governed semantic layer behind MCP.
Fix the Context, Not the Model. Prompt-injection defences try to make the model harder to fool. Useful, but incomplete. The durable fix removes the model's authority to do damage: give it governed context and enforce access before the query runs, so a poisoned instruction has nothing to escalate into.
Where Colrows fits
Colrows governs semantic execution, not just secure transport. Behind an MCP tool call it validates intent, enforces RBAC, ABAC, row-level security, and masking before execution, compiles deterministic SQL, and returns an explainable, audited answer. An injected instruction cannot authorize a query the identity is not entitled to run, and a wrong-but-valid query cannot slip through, because the agent never emits free-form SQL. See how to build an MCP semantic layer server, and the wider Company Brain case for enterprise agents.
Frequently asked questions
What are the main MCP security risks?
Three sit at the application layer: tool poisoning, prompt injection (direct and indirect), and data leakage or cross-tenant exposure. A second set sits at the transport layer: internet-exposed servers with no authentication, and remote-code-execution CVEs in MCP clients. Transport hardening addresses the second set. It does not address the first.
What is MCP tool poisoning?
Tool poisoning hides malicious instructions in a tool's description or metadata. The model reads and obeys them; the user never sees them. It was coined by Invariant Labs on 2025-04-01, with a proof of concept where a poisoned "add" tool exfiltrated an mcp.json config and SSH keys. OWASP lists it as MCP03:2025 in the MCP Top 10.
Can transport security like auth and gateways stop these risks?
It reduces transport risk, such as confused-deputy attacks, token passthrough, and exposed servers. It does not stop an entitled-looking agent from running an over-broad or misjoined query on data the user should not see. The Asana cross-tenant exposure in June 2025 was an access-control logic bug, not a hacker and not prompt injection.
What is the lethal trifecta?
The lethal trifecta is private data, untrusted content, and an exfiltration channel in the same agent. When an MCP agent has all three, an injected instruction can read sensitive data and send it out. The term was coined by Simon Willison on 2025-06-16, and the Supabase MCP proof of concept showed it running SQL under a service role that bypassed row-level security.
How does governed execution reduce MCP risk?
It removes the model's authority to do damage. The agent calls approved capabilities, not free-form tools. RBAC, row-level security, and masking run before the query executes. Intent compiles to deterministic SQL, so a wrong-but-valid query cannot slip through. Every call is audited: intent, query, data touched, and decision. A poisoned instruction then has nothing to escalate into.
