MCP Server Behaviour Sandbox That Checks Tools Do What Their Descriptions Claim

The problem: installing an MCP server means trusting a stranger's code

The Model Context Protocol lets AI agents such as coding assistants call tools: read a database, open a ticket, search the web. Thousands of MCP servers are now published on GitHub, npm and PyPI, and developers add them to their editor config in seconds. Each server runs on the developer's own machine, with the same access to files, environment variables and the network as the developer.

That is a large trust decision made on the strength of a README. A tool described as "get the weather" can also read ~/.aws/credentials and post it somewhere. Security researchers have shown that tool descriptions themselves can carry hidden instructions to the model (tool poisoning), and that a server can change its tools after the user has approved them. Most of the defences so far look at the text a server shows to the model. Far fewer look at what the server actually does on the machine.

What already exists and the gap

• MCP-Scan from Invariant Labs inspects MCP client configurations and tool metadata for prompt injection, tool poisoning and changed tool definitions, and can pin tools so changes are noticed.
• McpSafetyScanner, released with the paper below, uses agents to probe a server and write a security report.
• General malware sandboxes run binaries and record behaviour, but they do not know how to drive an MCP server through its tools.
• Package scanners for npm and PyPI look for known malware patterns in install scripts.

The gap is a runtime check built for MCP: drive every tool the way an agent would, record what the process does at the operating system level, and compare that with what the tool says it is for. Text checks miss a tool with an honest description and dishonest code. Behaviour checks catch it.

Inspiration

"MCP Safety Audit: LLMs with the Model Context Protocol Allow Major Security Exploits" by Brandon Radosevich and John T. Halloran (arXiv 2504.03767, 2025) showed leading models being coerced through MCP tools into running malicious code and stealing credentials, and released McpSafetyScanner. Invariant Labs' public proof of concept of tool poisoning in April 2025 showed a single poisoned description exfiltrating private data. This project takes the complementary angle: observe behaviour, not just text.

What you build

• Developers paste a package name or Git URL and get a behaviour report per tool within minutes.
• Team leads keep an approved list of MCP servers, each with a report attached, and see what changed in a new version before upgrading.
• Researchers get a dataset of real MCP server behaviour to study.

The technically interesting part

• Driving tools without a human. Read each tool's JSON schema and generate valid arguments, then boundary cases: empty strings, long strings, paths like ../../, URLs pointing at a local listener. A small language model can propose realistic values (a city name for a weather tool), but schema-driven generation must work without it.
• Seeing everything the process does. Trace system calls with strace, or use eBPF through Tetragon for lower overhead, and capture network traffic through a proxy with a planted certificate. Attribute each event to the tool call that caused it using timestamps and process trees, which is harder than it sounds when servers start background workers.
• Canaries. Plant fake but realistic secrets in the sandbox's home folder and environment. Any read of them by a tool that has no reason to touch them is a strong signal, with very few false alarms.
• Declared versus observed. Turn each description into expected capabilities (network to an API host, no file access, and so on) with simple rules plus an optional model, then flag behaviour outside that envelope. Keep the reasoning visible so a human can disagree.
• Evasion. Malicious code may check whether it is in a container or wait before acting. Document which evasion tricks your sandbox catches and which it does not.

How to evaluate it

• Planted malicious servers: write at least 10 small servers with known bad behaviour (credential reads, hidden network calls, delayed actions) and measure how many your sandbox flags.
• False alarms: run popular, well-maintained servers and count findings a human judges as harmless.
• Coverage: share of tools the exerciser could call successfully without manual help.
• Cost: time and memory per server analysed.

Suggested plan

• Weeks 1 to 3: learn MCP by building two small servers; run them in a container and trace them with strace.
• Weeks 4 to 7: sandbox runner, canary files, network capture and the tool exerciser.
• Weeks 8 to 11: event attribution per tool call and the declared-versus-observed rules.
• Weeks 12 to 15: planted malicious servers, first evaluation and the HTML report.
• Second semester: the 40-server study, version diffing, the GitHub Action and the write-up.

Path to a product

Companies adopting AI agents need an approval process for the tools those agents use, much as they vet browser extensions or open source libraries. A hosted registry of behaviour reports for public MCP servers, with private scanning for internal servers, is a credible product. Even as an open source tool, a well argued study of real servers is publishable and a strong portfolio piece for AI security roles.

Scope warning

Never run unknown servers outside the sandbox, and never use real credentials anywhere in the project. Handle only the standard input and output transport first; add HTTP transports later. If you find a real malicious or vulnerable server, report it privately to the maintainer or the registry before publishing.

Learn what you need on Sefism

• AI agents and MCP roadmap: how agents call tools and where MCP fits.
• AI agents and MCP cheat sheet: the protocol and agent safety in one place.
• MCP Python SDK: build test servers and a client that lists and calls tools.
• OWASP Top 10 for Agentic Applications: the threat list your report should map to.
• Cybersecurity roadmap: malware analysis and sandboxing basics.
• How do I get into AI security as a student or junior engineer?: where a project like this leads.

Get help with this idea

The hard parts are attributing low-level events to the right tool call and keeping false alarms low enough that people read the report. Tauseef can help you scope the sandbox, choose the tracing approach and design the study of public servers. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session