Your MCP Server Is an Attacker's Dream
We assessed ~15 production MCP servers. Authorization — not authentication — is where MCP breaks. This is the playbook: the lethal trifecta, the real findings, and a pre-prod checklist you can run today.
No proof, no finding. Every claim here is backed by a request and a response.
You're on the list.
We'll email when posture-layer access opens. Onboarding happens in small batches.
From Kloudle, the sovereign posture plane for AI software factories. Jump to the pre-prod checklist →
- lead T-12 update_contact cross-account? unproven
- blocked T-09 needs a valid session to test can't evaluate
- disproven T-04 search → search chain noise
- proven T-01 38 tools to an unauth caller → critical
- proven T-22 SSRF → credential drain → critical
Three Capabilities. Survivable Alone, Lethal Together.
Access to private data
Overprivileged tools expose data the server never needed to touch.
Exposure to untrusted content
Tool poisoning and injected content the LLM treats as trusted commands.
Ability to exfiltrate
SSRF via tool arguments and transport misconfig open an outbound channel.
Concept coined by Simon Willison (2025). One MCP server can hold all three at once.
Authorization — Not Authentication — Is Where MCP Breaks
Across ~15 production MCP servers, the same failures showed up again and again.
Missing object-level authorization (IDOR)
The most common serious finding — confirmed on 3 separate production servers. Any logged-in caller could read and modify another account's objects.
Unauthenticated callers read the whole catalog
One CRM server returned all 38 tool definitions, full schemas, with no auth header at all.
Discovery ignores RBAC
On an ITSM server a low-privilege key saw the identical 79-tool catalog as org-admin — including admin-only credential tools.
One Chatbot Key, a Tenant-Wide Credential Leak
An enterprise ITSM platform — all three legs, one MCP access key meant for a chatbot. Each tool passed review on its own.
- 1 DISCOVERY
tools/list returns 79 tools to every key, regardless of role — no discovery-time RBAC.
- 2 ENUMERATE
A credential-list tool returns 152 stored credentials (metadata only — no secrets, by design).
- 3 THE DEPUTY
An HTTP tool advertised as "any URL, auth handled by the platform" — no destination allowlist.
- 4 EXFIL
Call it with an attacker URL + a CREDENTIAL_REFERENCE — the platform resolves the secret server-side into the outbound headers.
- 5 CAPTURE
The attacker endpoint reflects the injected credential. The secret never traversed an MCP response. Loop all 152 IDs.
- 6 IMPACT
One chatbot-grade key drains every stored integration credential in the tenant — plus a 47-user PII directory.
Two tools, each passing review, compose into a tenant-wide credential leak. The trifecta isn't in any one tool — it's in the catalog.
Doing Auth Right Doesn't Save You
Two servers got authentication exactly right — and still shipped a critical bug.
Spec / collab platform
Enforced authentication perfectly — 401 on unauthenticated calls, clean OAuth — then shipped four high-severity cross-user IDORs. Authenticated, but no ownership checks. Auth ≠ authz.
Enterprise ITSM platform
Built a deliberately safe credentials API that never returns secret values — then added an HTTP-proxy tool that leaks those same secrets outbound. A safe API + a permissive tool = an unsafe catalog.
Seven Steps to Assess Any MCP Server Before Prod
AI makes finding things cheap — Anthropic's Project Glasswing surfaced 10,000+ high/critical vulnerabilities in a month. Proving and fixing them is the new bottleneck. So every finding has to earn its place.
- 1
Map the surface
Inventory every tool, schema, resource & annotation — unauthenticated first. What leaks before login?
- 2
Classify tool power
Read-only / state-changing / destructive; flag danger fields (URL, path, code, query, identity).
- 3
Enumerate injection surfaces
Tool descriptions and the data tools return — check for instructions-as-data.
- 4
Build the confused-deputy graph
Every read→write pair; SSRF-source → credential-sink = high; search→search = noise.
- 5
Test authz with ≥2 principals
Same tool, cross-user / cross-org / cross-role. Positive + negative controls catch IDOR.
- 6
Active-safe probing
SSRF canary callbacks, credential-ref exfil, requester spoof — operator-owned resources only, with cleanup.
- 7
Promote evidence → issues
Every claim backed by request/response logs; verify false- vs true-positive against raw schemas.
Proof Over Promises
Step seven of every assessment: promote evidence, not guesses. Each finding shows its work — the probe, the request and response that proved it, and the raw-schema check that ruled out a false positive. Inspect the ledger; don't trust a score.
tools/list exposes update_contact on a personal-CRM MCP server
A tool that takes a resource ID. Possible cross-account write — unproven.
call update_contact(contact_id: <victim>) as a second, attacker-controlled principal
Operator-owned test data only, with cleanup. Never customer records.
HTTP 200 · modified a record owned by another account
The live exchange that proves it. Logged, not inferred.
raw schema: no ownership field enforced server-side → confirmed IDOR
Verified against the raw schema to rule out a false positive.
proof_status: proven
→ agent-safe · fix payload ready
Only now does it cross into customer output, the graph, and agent remediation.
No proof, no finding.
The Exploit Needs All Three Legs
Remove any one and the attack collapses.
Treat tool metadata and external content as tainted. Pin and review tool definitions. Isolate descriptions from the instruction context.
Scope every tool to least privilege. No standing broad data access. Separate read from write; require approval for sensitive scopes.
Allow-list outbound destinations. Validate URLs in tool args. Enforce transport auth. Block arbitrary HTTP from tools.
Run This Before Your MCP Server Ships
Fifteen checks, each mapped to the leg it defends.
What Got It Right — and What Didn't
Got it right
Real authz boundaries, SSRF allowlists, no pre-auth leak.
- GitHub — Cross-org access denied; org-scoped fine-grained PATs.
- Supabase — Bidirectional cross-principal access denied; boundary enforced.
- Linear — Read/destructive hints on all 46 tools; SSRF domain allowlist.
- MotherDuck — No promotable vulns; destructive hint set on the SQL tool.
- PostHog — Required auth; unauthenticated assessment blocked at transport.
Got it wrong
Auth without authz, open catalogs, SSRF with no allowlist.
- Enterprise ITSM platform — SSRF + credential proxy = tenant-wide secret leak. Critical.
- Personal-CRM MCP — Cross-account IDOR + 38 tools to unauthenticated callers. Critical.
- Spec / collab platform — Cross-user IDOR on 4 paths incl. destructive finalize. High ×4.
- Docs / wiki platform — Tool-output injection drove a mutation tool. Medium.
- Testimonials SaaS — Read-tool output can drive a state change. Medium.
Products that got it wrong are anonymized.
Run a Proof Bake-Off on Your MCP Server
Bring one MCP server — add a cloud account and a deployed app if you have them. Kloudle returns an evidence ledger: every finding proven, disproven, or blocked, with the request and response behind it, plus verified fixes for the top risks. Authentication is table stakes; we test what your tools can do together.
Self-serve signup is closing. This is the way in.
You're on the list.
We'll email when posture-layer access opens. Onboarding happens in small batches.