Proposal: Security certification for MCP servers used by CrewAI crews

[edgarfloresguerra2011-a11y]

Security certification for MCP servers

CrewAI crews increasingly use MCP servers as tools. These servers execute arbitrary code on the user machine. How do we verify they are safe?

We built Sentinel — a 3-layer security audit that has certified 11,115+ MCP servers with signed SHA-256 certificates.

What Sentinel does

• L1.5: Metadata checks (AUTH, prompt injection, CORS, OAuth)
• L1.6: Static analysis (18 Semgrep rules + 18 secret patterns + OSV dependency check)
• L2: Docker sandbox with active MCP probing (adversarial inputs: path traversal, SSRF, SQL injection)

Results

• 11,115 servers certified
• Risk: 6 low, 10,831 medium, 125 high, 16 critical
• Each has a signed SHA-256 certificate: https://marketnow.site/verify

Proposal for CrewAI

Could CrewAI add a verify_security option when connecting MCP tools to crews?

from crewai import Agent, Crew
agent = Agent(role="Researcher", ...)
agent.connect_mcp(url="...", verify_security=True)

Links

• Transparency: https://marketnow.site/sentinel-transparency
• API: GET https://marketnow.site/api/audit-skill?certificate=1&skillId=mn-gen-00003
• Source: https://github.com/edgarfloresguerra2011-a11y/marketnow

Would the CrewAI community be interested in agent tool security?

[edgarfloresguerra2011-a11y]

Update: L2.5 gVisor sandbox now live

Since I opened this issue, I shipped L2.5: gVisor sandbox isolation for MCP server audits. gVisor is Google's userspace kernel — the MCP server never touches the host kernel directly.

Full audit pipeline:

• L1.5: Static analysis (dependency scan, license check, secret detection)
• L1.6: Pattern-based behavioral analysis
• L2 v2.0: Active MCP probe (60+ adversarial inputs)
• L2.5: gVisor sandbox (userspace kernel) — NEW
• L3 (Q1 2027): Firecracker microVM
• L4 (Q4 2026): Supply chain attestation (SLSA Level 3)
• L5 (Q3 2027): Third-party audit

Test case: Anthropic's official filesystem MCP scored 10/10 (low risk). Full audit JSON: https://github.com/edgarfloresguerra2011-a11y/marketnow/blob/master/_data/l2_results/mn-mcp-filesystem.json

If CrewAI wants to integrate Sentinel security checks before crews call MCP tools, I'd love to collaborate. The API is public: GET https://marketnow.site/api/audit-skill?certificate=1&skillId=<id>

[0xbrainkid]

The useful primitive here is probably not a boolean verify_security=True, but a pluggable trust policy for MCP tool admission. Different crews will have different acceptable risk: local filesystem tools, browser tools, payment tools, and remote hosted MCP servers should not all share the same threshold.

A shape that composes with CrewAI might be:

agent.connect_mcp(
    url="...",
    trust_policy=MCPTrustPolicy(
        providers=[SentinelProvider(), InternalAllowlistProvider()],
        min_score=70,
        require_signed_receipt=True,
        fail_mode="block",
    ),
)

The important part is preserving the receipt: provider name, server identity, package/hash, scan timestamp, result, and reason. Crews should be able to answer “why was this MCP server allowed to become a tool?” after the fact.

This also leaves room for behavioral reputation systems alongside static/security scans. Static certification says what the server package looked like at admission time; behavioral trust says what it has done across executions. For high-impact tool calls, both signals matter.

[mayank609]

@edgarfloresguerra2011-a11y This is a good approach for establishing trust before an MCP server is used. One thing I'd also think about is runtime behavior. A server can pass certification but still behave unexpectedly because of configuration drift, permission changes, or workflow context. Capturing which MCP tools were invoked, what inputs they received, and how their outputs influenced downstream agent decisions provides an additional layer of confidence that's valuable for production debugging and auditing.

[edgarfloresguerra2011-a11y]

@0xbrainkid @mayank609 — excellent feedback, both points are spot on.

@0xbrainkid — Pluggable trust policy:
You're right that a boolean verify_security=True is too coarse. Different crews need different thresholds. Our certificate already has the granularity you're describing:

{
  "overall_score": 8,
  "risk_level": "low",
  "layers_run": { "l15": true, "l16": true, "l2": true, "l25": true },
  "findings": {
    "network_attempts": 0,
    "fs_write_attempts": 1,
    "credential_leakage": 0,
    "seccomp_violations": 0
  }
}

A CrewAI trust policy could map to these fields:

agent.connect_mcp(
    url="...",
    trust_policy=MCPSecurityPolicy(
        min_score=7,
        allow_network=False,          # reject skills with network access
        allow_subprocess=True,         # allow for dev tools
        require_l25_sandbox=True,      # require gVisor audit
        allow_categories=["developer-tools", "data"]
    )
)

This composes with your per-crew risk model — a research crew can be more permissive than a production crew.

@mayank609 — Runtime behavior drift:
This is the gap we're most aware of. Certification is point-in-time; servers can drift. Our roadmap:

1. Weekly re-audits (LIVE): GitHub Actions re-runs Sentinel on every skill every Sunday. If a score drops, the certificate is revoked automatically.

2. Runtime telemetry (planned L3.5): agents report back what the server actually did — did it make unexpected network calls? Did it try to access paths outside its declared scope? This builds a runtime trust score that supplements the static audit.

3. Configuration drift detection (planned L4): compare the running server's hash against the certified hash. If they don't match, the certificate is invalid.

The audit + runtime monitoring combination is what closes the gap. Happy to collaborate on the CrewAI integration if there's interest.

Full methodology: https://marketnow.site/security
API: GET https://marketnow.site/api/audit-skill?certificate=1&skillId=<id>