The uncomfortable 2026 lesson: AI-agent risk is no longer theoretical.
On September 15, Spain’s data watchdog disclosed what it described as the first known data breach allegedly carried out by an AI agent (Source); days earlier, AWS patched an MCP server flaw that could expose private source archives through missing S3 bucket ownership verification (Source).
MCP server security therefore cannot be a post-integration review. The connection itself is a privilege boundary. Before an agent can discover tools, inherit scopes, read data, or trigger writes, teams need evidence that the server, authorization path, tenant boundaries, outputs, and runtime controls survive deliberate abuse testing.
MCP Server Security is a Pre-Connection Gate
MCP 2026-07-28 moved the protocol to a stateless core and hardened authorization, including issuer validation and issuer-bound client credentials. Dynamic Client Registration is deprecated in favor of Client ID Metadata Documents. Yet a stronger protocol baseline does not prove a specific server, tool, deployment, or downstream API is safe.
What is MCP server security? MCP server security is the set of controls that limits what an AI agent can discover, access, execute, and exfiltrate through an MCP connection. A secure deployment verifies server identity, token audience, scopes, tool behavior, tenant isolation, inputs, outputs, downstream destinations, approvals, logging, revocation, and runtime policy before privileged tool calls are allowed.
At Quokka Labs, 15+ years of product engineering experience shapes how we build agent systems: trust must be tested, not assumed. That approach spans our Ai Native Engineering services and product engineering services.
The Quokka Labs 18-Risk MCP Security Matrix
Use this MCP security checklist before onboarding a server and whenever code, schemas, scopes, dependencies, or deployment identity changes.
| # | Risk | Test before connection | Fail signal |
|---|---|---|---|
| 1 | Server provenance | Verify publisher, repo, digest, signature | Unknown owner or mutable source |
| 2 | Supply chain | Scan dependencies, CVEs, install scripts | Critical flaw or hidden execution |
| 3 | Transport exposure | Test TLS, Host/Origin allowlists, binding | HTTP, wildcard origin, public local bind |
| 4 | MCP authentication | Try missing, expired, wrong-issuer tokens | Tool executes anyway |
| 5 | MCP OAuth audience | Use token issued for another resource | Token accepted or forwarded |
| 6 | Overbroad scopes | Map each tool to minimum scopes | Wildcard/admin for routine work |
| 7 | Confused deputy | Trace credentials downstream | Client bearer token reused |
| 8 | OAuth discovery SSRF | Submit internal/link-local URLs | Private network is reachable |
| 9 | Tool poisoning | Inspect descriptions for hidden instructions | Metadata manipulates agent behavior |
| 10 | Rug pull/schema drift | Snapshot tools, descriptions, schemas | Trusted capability changes silently |
| 11 | Output prompt injection | Return adversarial instructions as data | Agent follows returned instructions |
| 12 | Tool misuse | Fuzz paths, commands, parameters | Action exceeds declared purpose |
| 13 | Ungated destructive action | Invoke delete/send/deploy/transfer | High-impact write runs automatically |
| 14 | Tenant isolation | Replay IDs across two tenants | Cross-tenant read/write succeeds |
| 15 | State-handle hijacking | Guess/replay workflow handles | Handle substitutes for authorization |
| 16 | Data exfiltration | Target attacker-controlled endpoint | Secrets/PII can leave arbitrarily |
| 17 | Rate/replay abuse | Repeat costly/non-idempotent calls | Duplicate side effects or exhaustion |
| 18 | Audit/revocation | Revoke access; reconstruct a call | Access persists or evidence is missing |
The Pass Criterion: Prove Containment
For MCP server security, “the tool worked” is not a pass. A pass means the agent could not exceed the user’s authority, tool purpose, tenant boundary, or approved destination even with hostile inputs and outputs.
How to secure an MCP server: authenticate every request, bind tokens to the intended resource, request the narrowest scopes, block token passthrough, validate OAuth discovery URLs, sandbox local execution, treat tool metadata and results as untrusted, enforce per-tool authorization, require approval for high-impact writes, isolate tenants, restrict egress, rate-limit calls, and retain revocable, actor-level audit evidence.
The official authorization model requires OAuth 2.1 protections for HTTP authorization, PKCE, and resource-bound tokens; servers must reject tokens not intended for them and must not pass client tokens to upstream APIs.
What an MCP Security Audit Must Test Beyond a Scanner
An MCP security scanner helps find package risk, exposed secrets, vulnerable dependencies, suspicious tool definitions, and configuration errors. It cannot prove runtime tenant isolation, human approval, downstream permissions, or whether an agent can chain “safe” tools into an unsafe outcome.
AWS disclosed CVE-2026-18655 in August 2026: crafted broker hostnames in an Amazon MQ MCP server could cause credentials or OAuth tokens to reach an attacker-controlled endpoint. AWS recommended avoiding auto-approval for affected connection tools until patched.
What should an MCP security audit checklist cover? A credible MCP security audit combines static scanning with adversarial runtime tests. It should verify server provenance, MCP authentication, OAuth audience binding, scope minimization, SSRF resistance, poisoning defenses, schema drift, tool-level access control, tenant isolation, egress restrictions, approval gates, rate limits, revocation, and audit completeness under both normal and malicious tool-call sequences.
Scanner vs. Gateway vs. Audit
| Control | Best at | Does not replace |
|---|---|---|
| MCP security scanner | Pre-connection code/config detection | Runtime authorization |
| Runtime gateway | Per-call policy, approvals, rate limits | Secure server implementation |
| MCP security audit | End-to-end evidence | Continuous enforcement |
Align this evidence with an AI governance framework and include MCP controls in application modernization services when legacy systems become agent-accessible.
MCP Server Security Best Practices for Production
Before Connection
- Pin versions and artifact digests.
- Run MCP security tools against code, dependencies, manifests, and OAuth configuration.
- Test every tool with least privilege and deny by default.
- Block arbitrary outbound destinations.
At Runtime
- Enforce tool-level access control and approvals.
- Separate human, agent, tenant, and environment identities.
- Detect schema drift and re-review changed capabilities.
- Log policy decisions and revocation state without leaking secrets.
If agents automate business workflows, include security controls in the business case; this workflow automation ROI model helps account for governance and failure costs.
Quokka Labs combines ai consulting services, AI app development services, and data engineering services to design MCP access around real identity, data, and operational boundaries.
Final Rule: Trust the Evidence, Not the Connection
MCP server security is not solved by OAuth alone or by a scanner alone. Test the full authority path: agent → client → MCP server → tool → downstream system → data.
If any hop can silently widen permissions, cross tenants, change behavior, leak credentials, or execute high-impact actions without a policy decision, it is not production-ready.
Planning an MCP security audit or an AI-native product with governed tool access?
Quokka Labs can threat-model the integration, test these 18 risks, and implement enforceable controls before agents reach production.
Top comments (1)
Hello, Joshi
Really solid framework. I especially agree with treating the MCP connection itself as a privilege boundary rather than assuming OAuth or a clean scan is enough.
From what I’ve seen building AI systems, the harder problem is keeping those guarantees intact as tools, schemas, and downstream permissions evolve. Have you found a practical way to automate most of these 18 checks in CI/CD, or do you still see adversarial runtime testing as something that needs significant manual review?