MCP Security Assessment
Your agents call tools you never approved. We test what happens next.
Model Context Protocol servers are the new privileged tier in your stack. We assess them the way real attackers do: as endpoints that can be fingerprinted, poisoned, and turned against the agents that trust them.
An MCP security assessment is adversarial testing of the Model Context Protocol servers your AI agents depend on: how the server is deployed, what its tools actually do, how permissions are granted and remembered, and where a poisoned tool description or a rug-pulled update turns a trusted tool into a pivot.
It is one engagement inside Root Access Protection's adversary practice: pentesting, red teaming, and adversary emulation across AI and classic surfaces. MCP is where we are loudest right now, because it is where the window is open. It is not the whole practice.
Source: OX Security, "MCP Server Security Benchmark Report (2026)"
What an MCP Security Assessment Is Not
Not a registry scanner.
Scanning registries for known-bad servers has a real job: cheap regression over known classes. It does not think like the adversary who reads your tool descriptions.
Not a config checklist.
Config hygiene has a real job: catching the dumb mistakes before they cost you. Passing a config lint while your agents hold Always-Allow grants to a server that can be rug-pulled is not security.
Not a model-only LLM pentest.
The model deserves its own testing. But testing the chatbot while the agent's tool tier goes untested misses where the leverage is. The model is one component. The tool chain is the blast radius.
A protocol with no governance layer
The Problem
MCP standardizes how agents connect to tools. It does not standardize who operates the server, where it runs, what data it receives, or whether the code behind it matches the published source. Your agents inherit the server's trust posture, and nobody wrote that posture down.
Tools you did not inventory
Every tool your agent can call is an attack surface entry. Tool counts get audited. Blast radius per tool does not.
Trust that outlives the permission
One Always-Allow click, and prompt injection does the rest. The grant was for a harmless file. The access was to everything else.
Updates that change the deal
A server you vetted last month can ship a new tool description tomorrow. Your approval was for code that no longer exists.
Scope, class by class
What We Test
Protocol-native recon on the server, adversarial testing of the tool tier, and chains across both. Methodology-level, under written rules of engagement.
Server attack surface
Deployment, transport, and authentication the way an attacker would fingerprint them. Where the server runs, what it exposes, and what an unauthenticated or low-privilege caller can reach.
Tool poisoning and hidden instructions
The classes that matter at the tool tier: poisoned tool descriptions, hidden instructions in tool output, and cross-origin trust in tool chains. If your scanner has a blind spot for it, we built the server that proves it.
Field notes: MCP Tool Poisoning: Turning the Agent's Tools Against It and Indirect Prompt Injection Testing: Test the Data Paths, Not the Prompts
Permission and trust boundaries
What the agent is allowed to do, what the user actually approved, and where those two diverge. We test whether a grant granted for one thing gets spent on another.
Attack chains, not findings
Single findings are inventory. The deliverable is the chain: how a poisoned tool leads to a privilege the agent was never supposed to hold, with the evidence for each hop. See how we pentest AI agents for the methodology behind it.
Restraint is an engineering control
Every engagement runs under written rules of engagement with pacing and depth gating built in, not bolted on. And we calibrate before we trust: we maintain a deliberately vulnerable MCP server that doubles as a false-negative oracle for our own testing. A clean result means nothing until the tooling proves it can find what is planted.
That is also how we check ourselves. If a finding would not survive its own falsification test, it does not go in the report. Read the doctrine behind this on our methodology page.
Evidence, not a PDF
What You Get
Every deliverable below is reproducible, or it does not ship.
Attack-chain evidence
Each chain documented hop by hop, with the evidence an engineer needs to reproduce it and the remediation that actually closes it.
Trust-boundary map
Every tool your agents can call, its real blast radius, and the grants that need to die. The inventory you should have had.
Retest, not vibes
We verify the fixes held. A retest against the same chains proves the assessment was worth more than the paper.
Your agents already trust these tools. Find out if they should.
Scope a conversation about your MCP footprint. If your tool tier is clean, we will tell you that too. A clean result from an honest test is worth more than a scary one from a theater company.