Testing infrastructure
How isolated testing works
MCPVault runs package-based Tester, verification and Monitor checks on a dedicated worker, separate from the directory application. This reduces what an untrusted package can reach while we check whether it starts and lists its tools.
What a check tells you
We start the package, complete the MCP initialization handshake and request its tool inventory. We do not invoke the listed tools. A complete inventory means the server answered the listing request; it does not prove that each tool works, that its descriptions are accurate, or that every client configuration will work. Starting a package can still execute its own startup code.
How execution is contained
Each job runs in a disposable container as an unprivileged user, with a read-only base filesystem and limited temporary storage. Memory, CPU, process count and runtime are capped. Application files, database credentials, SSH keys and the host Docker socket are not mounted into the container.
Where a package can connect
Network rules outside the package block private networks, cloud metadata services, the worker host and peer containers. The application host’s public address is also blocked. Public IPv4 web connections on ports 80 and 443 remain available, along with DNS through a designated resolver. Other UDP traffic and IPv6 are blocked. This is restricted internet access, not an offline environment.
Credentials and your own machine
An owner-configured check may receive the credentials needed for that check. The package can read those credentials and may send data over permitted public connections. Use narrowly scoped test credentials. Our isolation applies to checks run by MCPVault; it does not follow a package when you install it in Claude, Cursor or another client on your own machine.
Checks on the safeguards
Before enabling the worker on 9 September 2026, we tested public npm and Python access, blocked private and metadata destinations, redirects, changing DNS answers and peer-container access. We repeated acceptance after a reboot. Missing acceptance or a changed network policy makes the worker refuse execution. Infrastructure interruptions are retried or shown as an interrupted test, not treated as evidence that the package failed.
What verification does not promise
These protections reduce risk; they do not eliminate software or kernel vulnerabilities. A verified badge is evidence of the recorded protocol check, not a malware-free guarantee. Our static security profiles provide a separate view of code signals and dependency advisories. Read the report date, review the package and consider its permissions before using it. Older reports describe the environment recorded at the time; they are not retroactively certified by this rollout.