Cedar WASM integration for MCP server governance (protect-mcp)

[tomjwxf]

We built a Cedar WASM integration for governing AI agent tool calls in the MCP (Model Context Protocol) ecosystem.

What we built

protect-mcp is a transparent stdio proxy that wraps MCP servers with runtime policy enforcement. It supports three policy engines — JSON presets, external PDP (OPA/Cerbos), and local Cedar evaluation via @cedar-policy/cedar-wasm.

# Run with Cedar policies
npx protect-mcp --cedar ./policies/ --enforce -- node mcp-server.js

How Cedar is used

Each .cedar file in the policy directory is loaded and evaluated locally via WASM. The evaluation context maps MCP tool calls to Cedar authorization requests:

• Principal: the agent identity (from signed manifests)
• Action: the MCP method (tools/call)
• Resource: the specific tool being called (read_file, execute_command, etc.)

Example policy:

// Block command execution — prevents Clinejection (CVE-2025-6514)
// @incident("Clinejection: 437K developer environments compromised")
// @controls("OWASP-MCP-03")
forbid(
  principal,
  action == Action::"execute_command",
  resource
);

// Allow reads, constrain writes
permit(
  principal,
  action == Action::"read_file",
  resource
);

Every Cedar evaluation decision (permit/forbid) produces an Ed25519-signed receipt — a structured, content-addressed JSON record that can be independently verified offline. The receipt format is specified in an IETF Internet-Draft.

Why this might be interesting to the Cedar community

• Cedar policies running locally via WASM for real-time AI agent governance
• Policy evaluation results are cryptographically signed (not just logged)
• Maps OWASP MCP security controls to Cedar policies
• Works with Claude Desktop, Cursor, VS Code — any MCP stdio client

Links

• npm: https://npmjs.com/package/protect-mcp
• Cedar evaluator source: https://github.com/tomjwxf/ScopeBlindD2/blob/main/packages/protect-mcp/src/cedar-evaluator.ts
• Example Cedar policies: https://github.com/tomjwxf/ScopeBlindD2/tree/main/packages/protect-mcp/policies
• Trace visualizer: https://scopeblind.com/trace

Happy to answer questions about the integration or contribute documentation if useful.

[lianah]

Thank you for sharing this with the Cedar community. The github links don't seem to work though. Is it possible to share a new link? I was also curious whether you are using a Cedar schema for this, and if yes how are you generating it?

[tomjwxf]

@lianah — thanks for flagging, the repo was private which caused the 404s. The source is now public:

Cedar evaluator: https://github.com/scopeblind/scopeblind-gateway/blob/main/src/cedar-evaluator.ts
Example Cedar policies: https://github.com/scopeblind/scopeblind-gateway/tree/main/policies/cedar
On schema: we're not using a Cedar schema currently — schema is passed as null to the WASM evaluator. The entity model maps MCP concepts directly:

Principal: agent identity (from signed manifests)
Action: MCP method (tools/call, resources/read)
Resource: specific tool name (read_file, execute_command)
I've been considering auto-generating a schema from the MCP server's tools/list response at startup, since each server advertises its available tools. Would that be a reasonable approach, or does the Cedar team recommend static schemas for this kind of use case?

[lianah]

Thank you for the updated links, it works now!

We actually published a tool that auto-generates a Cedar schema from the MCP tool descriptions. It's very similar to your approach, in that it creates an action for each MCP tool. It also creates entities for the tool inputs so you can write policies that say things like "don't call read file with files starting with foo*".
You need to provide it a schema stub, that defines your principal entity (in your case the agent identity that it sounds like you can already auto-generate) and any additional context e.g. time of day if you want to restrict access during certain hours.

In general, we strongly recommend using a static schema with Cedar when possible. It gives you validation: you can check your policies are well-typed against the schema which rules out large classes of runtime errors. Having a schemas also lets you do policy analysis to help detect bugs in your policies.

[tomjwxf]

@lianah thanks, this is exactly what I needed. Auto-generating a Cedar schema from MCP tools/list at startup is what I had in mind, so knowing there's already a published tool for this is great.

The schema stub approach makes sense for our use case. The principal entity would be the agent identity (we derive this from signed manifests- an Ed25519 public key or a tenant slug). For context, time-of-day and request origin (local vs remote) are the two I'd add first.

The tool input entities are particularly interesting, being able to write policies like "permit read_file but only for paths under ./workspace/" is a common request from users hardening their MCP setups. We currently handle that with JSON policy args matchers, but Cedar schema validation would catch malformed policies before runtime.

Could you share a link to the schema generation tool? I'd like to integrate it and move from schema: null to validated schemas. Happy to contribute back if we find MCP-specific patterns that would be useful as examples.

[lianah]

Sure, here is the schema generation tool: https://github.com/cedar-policy/cedar-for-agents/tree/main/rust/cedar-policy-mcp-schema-generator
Let us know if you have any feedback.

[tomjwxf]

@lianah -- done! I integrated the schema generation into protect-mcp (v0.5.2, just published).

What I built: cedar-schema.ts -- a TypeScript schema generator that takes MCP tools/list responses and produces Cedar schemas. No Rust dependency, so it ships as part of the npm package.

It maps JSON Schema types to Cedar types (string -> String, integer -> Long, boolean -> Bool, array -> Set, object -> Record), generates per-tool actions with typed input context, and passes the schema to @cedar-policy/cedar-wasm's isAuthorized() -- replacing schema: null.

This enables policies like:

permit(principal, action == Action::"read_file", resource)
when { context.input.path like "./workspace/*" };

I followed the cedar-for-agents conventions (per-tool actions as children of a blanket MCP::Tool::call, @mcp_principal/@mcp_resource compatible stubs). 22 tests.

I also opened a PR to add this as an integration example in cedar-for-agents: cedar-policy/cedar-for-agents#63

Source: https://github.com/scopeblind/scopeblind-gateway/blob/main/src/cedar-schema.ts
Tests: https://github.com/scopeblind/scopeblind-gateway/blob/main/src/cedar-schema.test.ts

[tomjwxf]

@lianah -- quick update: the protect-mcp integration was merged into Microsoft's Agent Governance Toolkit today (PR #667). The integration uses Cedar WASM for runtime policy enforcement on every MCP tool call, with the schema generation approach we discussed here.

Thought you'd want to know -- Cedar is now the default policy engine in both the ScopeBlind and Microsoft AGT stacks for agent governance. The cedar-for-agents PR (#63) is still open if you get a chance to review.

Microsoft AGT PR: microsoft/agent-governance-toolkit#667