Hi - I came across protect-mcp and your IETF draft (draft-farley-acta-signed-receipts) via your HN comment on the "30 CVEs in 60 days" thread. Read the draft front-to-back; the policy_digest design is the right primitive - it lets a receipt be matched back to the exact authorization rule that produced it without trusting the gateway.
I've been working on what looks like the static-emission complement: https://github.com/razukc/capgate is a pure-TS compiler that reads an MCP server manifest with declared capabilities (e.g. fs:read,write:/workspace/**, net:connect:api.github.com:443, exec:spawn:chromium?nestedSandbox=true) and emits concrete sandbox policies — bwrap argv, egress allowlist rules, env injection lists. No execution, no signing, no runtime enforcement. Literally a function manifest → policy artifacts.
How they compose: declare-before-execute (capgate) gives you a contract about what a tool is allowed to touch; sign-after-execute (your receipts) gives you a record of what it actually did. The policy_digest is the join key.
The draft notes that Cedar integration is supported but manifest-to-Cedar workflows are left to implementers — that's the gap I think capgate could plausibly fill. Two concrete questions:
- Digest stability. Would it be useful if capgate emitted a policy_digest-compatible hash at compile time over the normalized capability set, so a downstream gateway can include it in receipts without re-deriving anything? Happy to pin the canonicalization to whatever the draft expects (RFC 8785 / the digest scheme in §4) so the artifacts interop cleanly.
- Manifest → Cedar lowering. Capgate's IR is intentionally smaller than Cedar (a flat capability grammar, no policy combinators), but the lowering capgate IR → Cedar policy document is mechanical for the cases the grammar covers. Would there be value in capgate shipping a lowerToCedar adapter alongside lowerToBwrap, so teams running protect-mcp can author manifests and get Cedar policies + sandbox argv from the same source? If you've already got a preferred Cedar shape in protect-mcp, I'd rather match yours than invent one.
- SIG-SAFE-MCP. OpenSSF's SIG-SAFE-MCP is cataloging MCP threat techniques and looking for canonical mitigations. The signed-receipts draft seems like the obvious upstream answer to several of them. Have you considered presenting it at one of their bi-weekly meetings?
No pitch and no ask — just want to check whether the abstractions point at each other before I write either side into a public post.
Happy to take this off-channel if useful.
— Raju
Hi - I came across protect-mcp and your IETF draft (draft-farley-acta-signed-receipts) via your HN comment on the "30 CVEs in 60 days" thread. Read the draft front-to-back; the policy_digest design is the right primitive - it lets a receipt be matched back to the exact authorization rule that produced it without trusting the gateway.
I've been working on what looks like the static-emission complement: https://github.com/razukc/capgate is a pure-TS compiler that reads an MCP server manifest with declared capabilities (e.g. fs:read,write:/workspace/**, net:connect:api.github.com:443, exec:spawn:chromium?nestedSandbox=true) and emits concrete sandbox policies — bwrap argv, egress allowlist rules, env injection lists. No execution, no signing, no runtime enforcement. Literally a function manifest → policy artifacts.
How they compose: declare-before-execute (capgate) gives you a contract about what a tool is allowed to touch; sign-after-execute (your receipts) gives you a record of what it actually did. The policy_digest is the join key.
The draft notes that Cedar integration is supported but manifest-to-Cedar workflows are left to implementers — that's the gap I think capgate could plausibly fill. Two concrete questions:
No pitch and no ask — just want to check whether the abstractions point at each other before I write either side into a public post.
Happy to take this off-channel if useful.
— Raju