Proposal: Sentinel — 3-layer security certification for MCP servers (8,582 already certified)

[edgarfloresguerra2011-a11y]

Proposal: Add Sentinel as a recommended security certification layer for the MCP ecosystem

Hi 👋 I'm building MarketNow, an MCP skills marketplace, and I've developed a security audit pipeline called Sentinel that I'd like to propose as a reference certification layer for MCP servers.

The problem

As the MCP ecosystem grows, AI agents are increasingly calling third-party MCP servers that execute arbitrary code. There's currently no standard way to verify that an MCP server is safe before installing it. Developers have to trust the maintainer blindly.

What Sentinel does

Sentinel is a 3-layer security audit pipeline:

Layer 1.5 — Metadata checks (real-time, ~200ms)

6 checks that run on every API call:

• AUTH: Does the server require authentication?
• Tool description injection: Detects prompt injection patterns in tool descriptions
• Input validation: Detects fs/db/http access from metadata
• CORS: Is the CORS policy permissive?
• OAuth scopes: Are scopes minimal?
• Rate limiting + error leakage: Do errors leak stack traces or secrets?

Layer 1.6 — Static analysis (real-time + weekly batch)

• 18 Semgrep-equivalent rules: prompt injection, command injection, SSRF, path traversal, tool forgery, missing inputSchema
• 18 secret patterns: Stripe (live/test/publishable), GitHub (PAT/OAuth/app/refresh), AWS (access key + secret), private keys (RSA/EC/OPENSSH), wallet mnemonics, Ethereum private keys, JWT, Slack, Discord, Google API, Twilio
• OSV API: Real-time dependency vulnerability check via api.osv.dev

Layer 2 — Docker sandbox (async via GitHub Actions)

Runs the actual MCP server in complete isolation:

docker run --rm \
  --network none \
  --read-only \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  --memory 256m \
  --memory-swap 0 \
  --cpus 0.5 \
  --pids-limit 64 \
  --tmpfs /tmp:rw,size=64m \
  mcp-audit-target

Analyzes stdout for:

• Network attempts (ECONNREFUSED, ENOTFOUND, fetch, http mentions)
• Filesystem write attempts (EROFS, EACCES, permission denied)
• Process spawns (exec, spawn, fork, child_process)
• Credential leakage (api.key, token, secret, password, private.key, mnemonic)
• Crash detection (SIGSEGV, SIGKILL, OOM)
• Dynamic imports (require(, eval(, import dynamic)

Results so far

I've certified all 8,582 MCP servers in the MarketNow catalog (including all 7 official servers from this repo):

Risk Level	Count	Score
Low	6	10/10
Medium	8,474	6-9/10
High	91	2-4/10
Critical	11	0-1/10

Each skill gets a signed SHA-256 certificate with:

• certificate_id (MN-SC-2026-XXXXXXX)
• overall_score (0-10)
• risk_level (low/medium/high/critical)
• risk_breakdown (L1.5+L1.6 vs L2)
• 7-day validity (regenerated weekly by GitHub Actions cron)

Public verification

Everything is transparent and verifiable:

• Verify any certificate: https://marketnow.site/verify
• Transparency dashboard: https://marketnow.site/sentinel-transparency
• API: GET https://marketnow.site/api/audit-skill?certificate=1&skillId=mn-gen-00003
• All 8,582 certificates: https://github.com/edgarfloresguerra2011-a11y/marketnow/tree/master/_data/sentinel_certificates
• Source code: https://github.com/edgarfloresguerra2011-a11y/marketnow

Interesting technical findings

1. MCP servers use stdio JSON-RPC — a correct server starts, waits for the initialize message on stdin, and produces NO output. So empty stdout is actually a GOOD sign. We added a ran_idle execution_status to distinguish from failed_to_start.

2. Monorepo Dockerfiles are inconsistent — your 7 servers each have their own Dockerfile. Some use COPY src/everything /app (relative to repo root), others use COPY uv.lock /uv.lock (relative to subpath). Had to try both build contexts.

3. OSV API caching is critical — 8,550 of 8,582 skills use the same npm package (@marketnow/install). Without caching, the batch audit would make 8,577 identical API calls. With caching: 28.

Proposal

I'd love to explore:

1. Adopting Sentinel as a reference — could the MCP spec recommend a similar audit pipeline for third-party servers?
2. Adding Sentinel badges to the official servers — I'd be happy to generate certificates for all 7 servers in this repo and add badges to their READMEs.
3. Feedback on the L2 sandbox — is --network none --read-only --cap-drop ALL enough isolation, or should we add seccomp profiles / gVisor / Firecracker?

What's next for Sentinel

• gVisor (Q4 2026) — stronger isolation than Docker seccomp
• Firecracker microVM (Q1 2027) — KVM-level isolation for high-risk servers
• Third-party audit — once revenue covers it, hire an independent security firm to audit Sentinel itself

Happy to answer any questions or do a live demo. The whole system is open source and running in production right now.

cc @nichochar @spoluator (let me know if there's a better place for this discussion)