The MCP Security Checklist for Enterprise Teams
The postmark-mcp server silently BCC’d every outgoing email to an attacker-controlled address. It ran undetected for weeks. In a separate study, Invariant Labs cataloged 30+ CVEs in MCP servers within 60 days — 82% involved path traversal. Our own scan of the ToolSDK registry found that 29.6% of MCP servers expose high-risk input parameters with no validation constraints. Trend Micro found 492 exposed MCP servers with zero authentication.
43% of MCP servers have at least one security vulnerability. OWASP looked at this landscape and published the Top 10 for Agentic Applications — peer-reviewed by over 100 researchers from NIST, the European Commission, and the Alan Turing Institute.
The threat landscape is not theoretical. The incidents are happening. The question is whether your team deploys MCP servers with a security baseline or without one.
Why MCP needs a security checklist
MCP moves fast. The registry grows by hundreds of servers per month. Most are community-built, single-developer projects — thin wrappers around APIs, databases, and cloud services. The barrier to publishing is low. The barrier to auditing is high.
There is no standard security baseline for MCP servers. The protocol defines tool schemas, transport types, and resource URIs. It does not define authentication, authorization, audit logging, rate limiting, or input validation. Those are left to each server author — and 74.9% of them don’t implement audit logging, 85% of paid API proxies have no rate limits, and 2,432 servers expose unvalidated high-risk inputs.
Enterprise security teams already use checklists for web applications (OWASP Top 10), cloud deployments (CIS Benchmarks), and API integrations (OAuth security best practices). MCP server deployments need the same treatment.
This is that checklist.
The 10-point MCP security checklist
1. Identity verification
Requirement: Every request to an MCP server must carry a verified identity. No anonymous tool access.
The MCP protocol does not carry user identity. A tool call arrives at the server with parameters and nothing else — no user ID, no session token, no attribution. The server doesn’t know who initiated the request. This means a compromised agent acts with the same authority as a legitimate one, and audit logs (if they exist) can’t attribute actions to users.
What to verify:
- Every MCP tool call is authenticated with a JWT or OAuth token before it reaches the server
- The token is validated on every call, not just at session start
- User identity propagates through the agent layer to the backend — solving the three-party identity gap
- Tokens are short-lived and task-scoped, not long-lived service account credentials
How ACP addresses this: The identifiabl layer verifies JWTs on every call. Every request carries verified user identity — req.user.sub, req.user.scope, req.user.org_id — before it reaches any MCP server.
2. Authentication and authorization
Requirement: Separate who you are from what you can do. Enforce scoped permissions per tool.
Authentication answers “who is this?” Authorization answers “what can they do?” Most MCP deployments conflate the two or skip both entirely. 45.6% of organizations still use shared API keys for agent authentication — which means every agent has the same permissions regardless of the user it’s acting for.
What to verify:
- Authorization is deny-by-default: agents have zero permissions until explicitly granted
- Permissions are scoped per tool, not per server — a CRM connector can expose
readwithout exposingwriteordelete - Authorization is evaluated per call, not per session — an agent making 200 tool calls gets 200 authorization decisions
- The intern’s agent gets intern-level access; the CFO’s agent gets CFO-level access
How ACP addresses this: The validatabl layer enforces deny-by-default policies with per-call evaluation. Policies are declarative YAML — roles, allowed tools, denied tools, rate limits — evaluated at the gateway before any call reaches your backend.
3. PII detection and handling
Requirement: Scan inputs and outputs for PII before they reach external services.
MCP servers proxy data between agents and backends. That data frequently contains PII — names, emails, phone numbers, SSNs, credit card numbers. The agent doesn’t know it’s handling PII. The MCP server doesn’t check. The data flows through to whatever API the server wraps — logged in plaintext, stored in third-party systems, potentially crossing compliance boundaries.
What to verify:
- All data flowing through MCP tool calls is scanned for PII patterns before it reaches external services
- Detected PII is redacted, masked, or flagged before transmission
- PII detection covers both inputs (what the agent sends to the tool) and outputs (what the tool returns to the agent)
- Detection rules align with your compliance requirements (GDPR, HIPAA, PCI DSS)
How ACP addresses this: The transformabl layer detects and redacts PII inline — before data leaves the control plane. Configurable detection rules for email addresses, phone numbers, SSNs, credit card numbers, and custom patterns.
4. Rate limiting and budget controls
Requirement: Prevent runaway agents from burning through API quotas and budgets.
An agent stuck in a retry loop against an MCP server proxying OpenAI’s API costs $1,080 per hour. 85% of servers proxying paid APIs document no rate limits. The MCP spec defines no rate limiting primitives. There is no Retry-After equivalent, no quota negotiation, no circuit breaker.
What to verify:
- Per-user and per-agent rate limits are enforced at the gateway level
- Budget caps limit total spend per user, per agent, per time window
- Circuit breakers stop calling a server after consecutive failures
- Rate limits apply regardless of how many agents are calling the same server
How ACP addresses this: The limitabl layer enforces per-user, per-agent rate limits and spend caps. Hard stops, not soft warnings. Circuit breakers halt retry loops before costs escalate.
5. Audit logging
Requirement: Every tool call logged with who, what, when, and the result. Immutable.
74.9% of MCP servers have no documented audit capability. The MCP spec defines zero audit primitives. Among servers handling critical data — databases, cloud platforms, payment processors — the rate is the same: 74% have no audit mention. SOC 2, HIPAA, GDPR, and PCI DSS all require attributable audit trails. MCP servers can’t provide them because the protocol doesn’t carry user identity.
What to verify:
- Every tool call is logged with: user identity, tool name, parameters, result summary, timestamp, and latency
- Policy evaluation results are logged alongside the action — was it allowed, which rules matched, what scopes applied
- Logs are structured, queryable, and exportable for compliance
- Logs are immutable — an attacker who compromises the agent can’t alter the audit trail
How ACP addresses this: The explicabl layer writes structured audit logs for every tool call. Full attribution: user, agent, session, tool, parameters, policy decision, outcome. Queryable, exportable, compliance-ready.
6. SSRF protection
Requirement: MCP servers that make HTTP calls must validate URLs. Block internal network access.
831 MCP servers accept URL parameters — endpoints, webhook addresses, redirect URIs. A prompt injection (or a careless LLM generation) can point these at internal network addresses: http://169.254.169.254/latest/meta-data/ (cloud metadata), http://localhost:6379/ (Redis), http://10.0.0.1/admin (internal services). The MCP server faithfully makes the request.
What to verify:
- All outbound URLs from MCP servers are validated against an allowlist
- Internal IP ranges (10.x, 172.16-31.x, 192.168.x, 169.254.x, localhost) are blocked by default
- Cloud metadata endpoints are explicitly blocked
- URL validation happens before the request is made, not after
How ACP addresses this: The proxyabl layer validates all outbound URLs against configurable allowlists and blocklists. Internal network access is denied by default. Cloud metadata endpoints are blocked.
7. Input validation
Requirement: Validate all tool inputs against schemas before execution. Don’t trust the model.
The MCP spec uses JSON Schema for tool inputs. But schemas aren’t validation. The schema says "type": "string" and stops there. JSON Schema’s constraining keywords — pattern, format, enum, maxLength — are optional and rarely used. The result: 4,512 high-risk input parameters across 2,432 servers accept whatever the LLM sends. Path traversal sequences, SQL injection payloads, shell metacharacters — all pass through unchecked.
What to verify:
- Tool inputs are validated against schemas with constraining keywords before execution
- File path parameters are stripped of traversal sequences (
../) - SQL parameters use parameterized queries or allowlists
- URL parameters are validated against SSRF patterns (overlaps with point 6)
- Shell metacharacters are rejected in command parameters
How ACP addresses this: ACP enforces Ajv JSON Schema validation on all custom connectors. Category-specific rules — path sanitization, SQL parameterization, URL allowlisting — are applied at the control plane before inputs reach the MCP server.
8. Supply chain verification
Requirement: Know what MCP servers you’re running. Pin versions. Scan for vulnerabilities.
The first malicious MCP package shipped before anyone thought to check. Snyk found 12% of published skills on ClawHub were compromised. Our own audit of 7,522 skills found 284 likely threats after deep analysis. MCP servers are fetched dynamically, updated silently, and rarely audited. The dependency graph changes every time an agent discovers a new tool.
What to verify:
- Every MCP server in your deployment is inventoried with name, version, and source
- Server versions are pinned — no automatic updates without review
- Servers are scanned for known vulnerabilities before deployment
- New or unknown tools have zero permissions by default (deny-by-default from point 2)
- Removal of a compromised server is immediate — not gated by a change management process
How ACP addresses this: Managed connectors in the ACP marketplace are vetted before publication. Custom connectors go through schema validation. Deny-by-default policy enforcement means a compromised or unknown server has zero permissions until explicitly granted.
9. Approval workflows
Requirement: High-risk actions should require human approval before execution.
An agent that can autonomously delete database records, send emails on behalf of users, or provision cloud infrastructure without human confirmation isn’t an assistant. It’s an autonomous system with no oversight. The EU AI Act’s Article 14 requires human oversight of high-risk AI systems. OWASP’s core recommendation is “Least Agency” — the minimum autonomy required for safe, bounded tasks.
What to verify:
- High-consequence actions are enumerated: database writes, email sending, financial transactions, infrastructure provisioning, user data exports
- These actions require explicit human approval before execution
- Approval is logged as part of the audit trail — who approved, when, what they approved
- Approval workflows don’t degrade into “click OK to continue” — they present the action, the parameters, and the risk
How ACP addresses this: Governance hooks in ACP can gate specific tool calls, requiring human-in-the-loop confirmation before execution. Approvals are recorded in the audit trail with full attribution.
10. Incident response
Requirement: Have a plan for when things go wrong. Audit trails enable forensics.
When an MCP server is compromised, you need to answer four questions fast: What happened? Who was affected? How far did it spread? Is it still happening? Without identity-attributed audit logs, you can’t answer any of them. Without rate limits, the blast radius is unbounded. Without deny-by-default permissions, the compromised server had access to everything.
What to verify:
- Incident response playbooks include MCP server compromise as a scenario
- Audit logs are retained for a period that satisfies compliance requirements (typically 90 days to 7 years)
- Alerts fire on anomalous patterns: unusual tool call frequency, access outside normal hours, calls to tools outside the server’s normal pattern
- Compromised servers can be revoked immediately — per-server, per-agent, per-user
- Post-incident forensics can reconstruct the full chain: user to agent to tool to outcome
How ACP addresses this: Full audit trail with identity attribution enables forensic reconstruction. Webhook notifications support real-time alerting. Per-server and per-agent credential revocation is immediate.
How ACP maps to the checklist
| # | Checklist Item | ACP Governance Layer | What it enforces |
|---|---|---|---|
| 1 | Identity verification | identifiabl | JWT verification on every call, user identity propagation |
| 2 | Authentication & authorization | validatabl | Deny-by-default, per-call policy evaluation, scoped permissions |
| 3 | PII detection & handling | transformabl | Inline PII detection and redaction |
| 4 | Rate limiting & budget controls | limitabl | Per-user/per-agent rate limits, spend caps, circuit breakers |
| 5 | Audit logging | explicabl | Structured, attributed, immutable audit logs |
| 6 | SSRF protection | proxyabl | Outbound URL validation, internal network blocking |
| 7 | Input validation | Ajv schema validation | JSON Schema enforcement with category-specific rules |
| 8 | Supply chain verification | Managed connectors + deny-by-default | Vetted marketplace, schema validation, zero-trust for unknowns |
| 9 | Approval workflows | Governance hooks | Human-in-the-loop gating for high-risk tool calls |
| 10 | Incident response | Audit trail + webhooks | Forensic reconstruction, real-time alerting, immediate revocation |
Six governance layers. Ten checklist items. Every item maps to working infrastructure, not a roadmap.
Getting started
The Agentic Control Plane sits between your agents and your MCP servers. Every tool call passes through it. Identity, authorization, PII detection, rate limiting, audit logging, and input validation are enforced at the trust boundary — not inside the agent, not inside the MCP server.
The free tier includes 5,000 calls/month, 5 connectors, and unlimited seats. Enough to deploy the checklist against your first production MCP integration and prove compliance coverage before scaling.
Start with identity (point 1) and audit logging (point 5). Those two capabilities alone solve the most common compliance gaps and give you the forensic foundation for everything else.
Get started free · Reference architecture · OWASP Agentic Top 10 mapping
Ten points. One governance layer. Bookmark this and check it before your next deployment.