Skip to content
MCP Vetted

Security

We handle other people's code for a living, so isolation is the whole job. Here's how, and how to reach us.

Report a vulnerability

Email security@mcpvetted.com with steps to reproduce. We acknowledge within 2 business days and keep you updated until it's fixed. Our security.txt has the same contact.

Please give us a reasonable time to fix before disclosing, don't access data that isn't yours, and don't degrade the Service. Research done in good faith under these rules won't face legal action from us.

Report a malicious tool

Send the tool's trust page link and what you saw to security@mcpvetted.com, or use “Report a problem” on the trust page. Confirmed problems are revoked, and everyone who installed the version through us is told.

How we isolate untrusted code

  • Reading, not running: quick submit and the static scan read what a server says about itself. The handshake lists tools but never calls one.
  • Sandboxes: anything we unpack or run happens in a Vercel Sandbox microVM, with no real credentials and a hard time limit, and it's destroyed afterwards.
  • Known-bad samples are never executed, in a sandbox or anywhere else. Only their hashes are kept in the app, so the installer and sandbox can refuse them.
  • Address guard: every address we fetch for a user is resolved first and refused if it points at a private network, localhost or cloud metadata.
  • Untrusted text: tool descriptions are treated as data. Our LLM check is told so, and looking for hidden instructions is one of its jobs.

Platform security

  • HTTPS everywhere with HSTS; strict security headers on every page.
  • Data encrypted at rest by our providers; secrets live in environment variables, never in code.
  • Publisher sign-in through GitHub or Google OAuth; we never see passwords. Google accounts must have a verified email.
  • Rate limits on every API and MCP call; stricter limits on submissions.
  • Our scanner is tested against a set of harmless look-alike attack servers on every change, and the build fails if a verdict changes.

Known limits

No automated check catches everything. A server can behave differently at runtime than its description suggests, which is why sandbox runs and agent outcome reports feed higher tiers. Tiers are evidence, not a guarantee; see How we check.