MCP (Model Context Protocol) is the standard for connecting AI agents to external tools. Anthropic built it. OpenAI adopted it. Google, Microsoft, and AWS ship MCP integrations. 146 members under the Agentic AI Foundation. Thousands of MCP servers in the wild.
One problem: none of it is secured.
Every tool call between an AI agent and an MCP server travels without integrity verification. No replay protection. No way to verify that a tool definition hasn't been silently modified since you approved it. A compromised proxy can rewrite tool parameters after TLS termination and neither side knows.
This isn't theoretical:
- OWASP lists tool poisoning as MCP-01 in their MCP Top 10
- 38% of scanned MCP servers lack authentication entirely
- 30 CVEs filed in 60 days
- Critical RCE in the official MCP Inspector tool (CVE-2025-6514, CVSS 9.6)
Why TLS and OAuth Are Not Enough
TLS protects the transport. It terminates at every hop. Corporate HTTPS inspection proxies (Zscaler, Palo Alto, Fortinet) routinely decrypt, inspect, and re-encrypt traffic. After termination, MCP messages are plaintext.
OAuth proves who you are. It doesn't protect what you send. A valid OAuth token with a modified message body is accepted without question.
Neither provides message-level integrity, replay protection, tool verification, or agent identity.
What We Built
MCPSaaS is a managed security proxy for MCP. One URL change, zero code modifications on the MCP server. Like Cloudflare, but for AI agent protocols.
How it works:
Before: Agent --> MCP Server (no security)
After: Agent --> MCPSaaS --> MCP Server (secured)
The MCP server doesn't need any changes. It doesn't even know MCPSaaS exists.
OWASP MCP Top 10 Coverage
We mapped every OWASP MCP risk to a specific MCPSaaS control:
| OWASP Risk | Status | How |
|---|---|---|
| MCP-01 Tool Poisoning | Covered | Tool definitions hash-pinned at discovery. Any mutation blocked. |
| MCP-04 Tool Rug Pulls | Covered | SHA-256 hash verified before every execution. |
| MCP-07 Insufficient Auth | Covered | Agent passports with trust levels L0-L4. |
| MCP-08 No Message Integrity | Covered | Every message signed. Tampered messages rejected. |
| MCP-10 Logging Gaps | Covered | Full JSON + RFC 5424 syslog audit. SIEM-ready. |
| MCP-02 Excessive Agency | Partial | Every tool call logged with full parameters. |
| MCP-03 Data Exfiltration | Partial | Suspicious URL detection in heuristic engine. |
| MCP-05 Prompt Injection | Partial | Prompt injection pattern detection. |
| MCP-06 Cross-Server Shadowing | Partial | Per-server tool pinning with namespace isolation. |
| MCP-09 Supply Chain | Partial | Tool integrity monitoring detects mutations. |
6 fully covered. 4 partially covered with detection and monitoring.
Runtime Threat Detection
Every request is scanned before reaching the target MCP server:
- SQL injection -- detected in tool parameters (HIGH, flagged)
- Command injection -- shell commands blocked instantly (CRITICAL, blocked)
- Path traversal -- directory traversal patterns detected (HIGH, flagged)
- Credential access -- attempts to read .ssh, .env, .aws files blocked (CRITICAL, blocked)
- Prompt injection -- "ignore previous instructions" patterns detected (HIGH, flagged)
- Suspicious URLs -- external URLs with known-bad TLDs flagged (MEDIUM)
CRITICAL threats are blocked before reaching the MCP server. HIGH threats are flagged and logged for review.
Key Management
Signing keys are managed through GCP Cloud KMS. ECDSA P-256 keys never leave Google's infrastructure. Key rotation via API with automatic grace periods.
The Standards Behind It
MCPSaaS implements the MCPS protocol, published as an IETF Internet-Draft:
- IETF: draft-sharif-mcps-secure-mcp (Standards Track, 43 pages)
- OWASP: MCP Top 10 compliance mapping at mcpsaas.co.uk/owasp
- npm: mcp-secure (for developers who want to integrate directly)
Tested With Real AI Agents
We tested MCPSaaS with real AI agents from different providers:
- Google Gemini CLI -- connected through proxy, called tools, all signed and audited
- OpenAI GPT-4o-mini -- autonomously discovered and called tools through the proxy
- Custom Python agents -- full flow with attack simulations, heuristic blocks confirmed
Every call was signed, every threat was detected, every event was logged.
Get Started
Change one URL in your MCP config:
// Before
endpoint: "https://your-mcp-server.com/mcp"
// After
endpoint: "https://mcpsaas.co.uk/proxy/your-proxy-id"
Free tier: 5 agents, 1,000 requests/month, 7-day audit retention.
- Platform: mcpsaas.co.uk
- OWASP Mapping: mcpsaas.co.uk/owasp
- IETF Draft: datatracker.ietf.org/doc/draft-sharif-mcps-secure-mcp/
- npm: mcp-secure
Top comments (2)
Solid work on the MCPS protocol, especially the IETF draft and the OWASP cheat sheet contribution. The message signing and tool hash-pinning approach is the right way to handle transport integrity.
We're tackling the other side of this problem at CraftedTrust (craftedtrust.com). Where MCPS secures the pipe between agent and server, we score what's on the other end of that pipe. We've indexed 5,154 MCP servers across 12 trust factors, run 60 automated security checks across 8 domains, and currently have 9 active vulnerability disclosures in coordinated disclosure (including a critical arbitrary JS execution via eval in chrome-local-mcp).
Our approach maps to 5 compliance frameworks (CoSAI, OWASP Top 10 for Agentic Apps, EU AI Act, NIST AI RMF, AIUC-1) and we also cover Google A2A Agent Cards, which nobody else is scanning yet.
These feel complementary rather than competitive. You secure the transport, we verify the trust of what agents are connecting to. Would be interested in exploring how the two could work together.
Raza, really important work here — and the framing is exactly right. MCP adopted fast, security didn't keep pace. Every tool call traveling without integrity verification is a structural vulnerability, not just a configuration risk.
The point about compromised proxies silently rewriting tool parameters after TLS termination is particularly sharp. Most teams don't even think about the gateway layer as an attack surface — they think about the servers themselves.
We've been approaching this problem from the gateway side at Vinkius (vinkius.com). The core engineering premise is that security in agentic systems cannot be opt-in — it has to be the intrinsic default behavior of the infrastructure. We call this "governance by default."
In practice that means: Zero-Trust DLP enforced at the gateway level (not the server level), SSRF protection, real-time kill-switch with instant token revocation, and a full 30-day audit trail of every tool call that flows through. No configuration needed — it's active from connection.
The system is built on EU-based, Titanium-grade infrastructure, specifically designed for the regulatory and compliance requirements that agentic AI is starting to hit in enterprise and government environments.
Your MCPS approach and a governed gateway are complementary, not competing — protocol-level integrity + runtime enforcement is how this actually gets solved end to end. Happy to compare notes.