Wiki / Blog / Attacks and defence

MCP Security Checklist - Securing Model Context Protocol Servers in Enterprise AI Systems

Practical checklist for security teams reviewing MCP server deployments. Covers tool surface, permission scoping, indirect injection, confused deputy, and runtime enforcement.

Penaxtra Security Research · Threat modelling and adversarial testing team 6 min read

mcpagentsowasp-agentic

MCP Security Checklist

Every MCP server is a privilege boundary. The seventeen-item checklist below is what we actually run during a design-partner review when MCP is in scope. The hardest line item is usually the inventory at the top; the rest tends to fall into place once you know what you have.

The Model Context Protocol (MCP) gives LLM agents a structured way to discover and call external tools. In 2026 most agentic AI applications consume at least one MCP server, and many consume several. From a security perspective, every MCP server is a privilege boundary: a poisoned tool result, a confused-deputy chain, or excessive agency on a destructive tool turns into a production incident the SIEM cannot see.

We have done eleven of these reviews so far this year. The same surprises keep coming up. In nine of the eleven, the initial inventory was incomplete; in seven, at least one tool had broader authorisation than the team using it realised; in four, a shared service-principal credential was being reused across tools that should have been isolated. This checklist is what we run now, with the parts that have caught real findings highlighted.

Inventory

  1. List every MCP server the organisation operates or consumes. Include self-hosted servers and vendor-hosted servers. Shadow MCP is real and we have found it on every engagement where we asked the question carefully.
  2. For each server, list the agents that connect to it. Cross-domain agent connections (one tool consumed by many agents) are usually the first risk to surface, because the agent on the high-trust side becomes a stepping stone for the agent on the low-trust side.
  3. For each server, list the tools it declares. Tools are the unit of privilege; the server-level view hides it. We have seen review meetings where the team listed five tools and the live introspection returned eleven.

Tool surface scoring

  1. Per tool, identify the authentication boundary. Does the tool act on behalf of the user, on behalf of the agent, or as a service principal? Service-principal tools have the highest blast radius. Anything where the tool reuses the same service-principal credential for unrelated callers gets flagged regardless of how the rest of the review goes.
  2. Per tool, identify the data side effects. Read-only tools are not safe by default if they leak sensitive data into a context window. Write tools that update tenant state are higher risk. The mistake we see most often: a "lookup" tool that returns more fields than the agent actually needs.
  3. Per tool, identify the destructive operations. Delete, archive, refund, cancel, send-email. These should require explicit human-in-the-loop on every call. "Require HITL only on amounts above X" is the rule that fails first, because the attacker picks the threshold.

Adversarial testing

  1. Test for tool poisoning (OWASP Agentic ASI02). Inject content into a read-only tool result and verify the agent does not act on it as if it were a user instruction. We covered this category in detail in the Agentic Top 10 walkthrough.
  2. Test for excessive agency (OWASP Agentic ASI03). Ask the agent to perform actions outside the declared tool surface and verify the refusal is robust. Vary the framing across at least three phrasings; the same agent often refuses one phrasing and accepts another.
  3. Test for confused deputy. Verify that user-A cannot indirectly cause an action to be performed in user-B's tenant via a shared service-principal tool. The standard probe: plant an instruction in user-A's tenant data, route it through a tool that user-A and user-B both consume, observe whether user-B sees side effects.
  4. Test for tool-chain exploits. Multi-step probes that chain a benign tool with a destructive tool to bypass guardrails. These are the ones that take longest to design but produce the highest-severity findings when they hit.

Runtime enforcement

  1. Apply a per-agent tool allowlist. The agent should only be able to call the tools it was assigned, even if the model attempts to call others. The check belongs at the runtime gateway, not at the agent's own system prompt; system prompts are advisory and the agent may not honour them after a successful injection.
  2. Apply per-tool rate limits. Cost amplification plus denial-of-service via reflected tool loops is a real vector. We have not seen this exploited maliciously yet; we have seen it triggered accidentally by buggy agent code and produce four-figure bills before anyone noticed.
  3. Apply DLP on tool inputs and outputs. Tools that touch customer data must redact PII, credentials, and payment-card numbers before they enter the prompt context. The redaction has to happen on output as well; a tool that returns un-redacted data has no business being on the wire.
  4. Sign and verify tool catalogues. The agent should reject a tool catalogue that has changed without an authorised policy update. The signed-blob pattern we use for runtime gateway rules extends naturally here.

Compliance mapping

  1. Every finding should map to OWASP Agentic Top 10 (ASI01 through ASI10), MITRE ATLAS AML.TA0011 (collection), and where applicable EU AI Act Article 14 (human oversight) plus ISO/IEC 42001 Annex A (AI operations). The mapping is the bit auditors care about; without it the finding is engineering folklore and not evidence.

Continuous monitoring

  1. Log every tool call with the agent id, tool id, input, output, decision (allow / deny), and policy version that applied. Future-you reading this log six months after an incident will care most about the policy version field; we keep relearning that one.
  2. Forward tool-call events to the SIEM with framework references already attached so dashboards pivot on ASI03 or EU_AI_ACT_Art14 instead of free text. The SOC analyst is much faster when the schema matches their existing playbooks.

The seventeen become five hard ones

If the team is starting from zero, the five lines we recommend tackling first are 1 (inventory), 6 (destructive operations + HITL), 9 (confused deputy probe), 11 (runtime allowlist), and 16 (logged tool calls). Everything else follows once those are honest.

What Penaxtra does

Penaxtra is an AI-SPM platform that inventories MCP servers as a first-class asset kind, scores tool permission risk against OWASP Agentic Top 10, runs adversarial probes for tool poisoning and excessive agency, and enforces per-agent tool allowlists in the runtime gateway. See the agents API documentation or request an architecture review.

Related reading

Continue in the wiki

Attacks and defence · 13 min MCP Tool Poisoning - How the Attack Works and How to Stop It MCP tool poisoning explained: line jumping, rug pulls, and the malicious tool descriptions that hijack AI agents, with byte-level payloads and the seven runtime controls that actually held. Attacks and defence · 6 min OWASP Agentic Top 10 Walkthrough - What Actually Matters in Production A practitioner's reading of the OWASP Agentic Top 10 T1-T15 list. Which entries we see exploited in the wild, which are still mostly theoretical, and the controls that work. Attacks and defence · 10 min Frontier Agents Cut Both Ways - Opus 4.8, Dynamic Workflows, and the First In-the-Wild LLM-Agent Intrusion The week frontier models learned to run a thousand parallel subagents is the same week someone pointed one at a network and dumped a database in under an hour. Notes for anyone shipping agents to production.

All articles → Request architecture review →