70 MCP servers were run in a sandbox to check real behavior
mcp-audit runs inside a sandbox and records which files they open and which internet connections they make while running. The official checks who published a server, but it does not check what the server actually does after someone runs it. can miss problems that only appear during use, such as a later version changing behavior, a server contacting an unrelated host, or a server reading files outside its expected area.
The tool starts each server inside a throwaway Linux container with Docker and uses strace to record and network connections. It also places a fake secret called a canary in the environment, so any attempt to read or send that secret can be seen. In a check of 70 , 67 showed no sensitive file reads and no unexpected network activity at startup.
Three servers opened outbound HTTPS connections at startup, but the connections matched their jobs, such as exchange access, GitHub fetching, or cloud and CDN access, and none touched sensitive files or the canary. bullmq-mcp read /etc/passwd at startup through a normal glibc user lookup, and the file contents did not leave the process. The current check only covers startup and idle behavior, not what happens when an AI agent makes .
Key points
- 70 were tested in an isolated environment.
- 67 servers showed no sensitive file reads or unexpected network activity at startup.
- Three servers made HTTPS connections that appeared to match their intended purpose.
- One server read /etc/passwd through a normal glibc lookup, and the data was not sent out.
- The audit does not yet test behavior during , where more risk may appear.