Author here. cMCP sits between an agent and its MCP tool servers. Every tool call is evaluated against a Cedar policy before it is forwarded, and the gateway emits a signed, hash-chained record of what it decided. MIT, Python 3.11+.
Ten-minute laptop version, no hardware and no signup: https://agentrust-io.com/quickstart/ You install the runtime, write one forbid rule, watch a tool call come back 403 POLICY_DENY before a byte leaves the machine, then verify the receipt it produced.
That last step is the only part I would care about if a stranger posted this, so: run the verifier on a laptop and you get six checks passing and one failing.
Exit code 1. Software mode has no hardware root of trust to offer, so the tool refuses to call the result verified. I would rather hand you that than a green check that means nothing. It reports verified only when the platform evidence is itself cryptographically checked: for SEV-SNP the report signature plus VCEK to ASK to ARK with the ARK pinned by the operator, for TDX the DCAP quote to a pinned Intel root, for TPM 2.0 the signature over the TPMS_ATTEST plus the AK certificate chain to a manufacturer CA the operator pins.
We got that last one wrong, and it is still wrong in the release you would install right now. The tpm2 branch checked the measurement and never the signature over it, so a forged TPMS_ATTEST with correct magic and matching qualifying_data was reported as hardware-attested. That is issue #370, fixed in #469, on main as of this week and not yet on PyPI, so pip install gives you 0.3.0 and 0.3.0 has the defect. It ships as 0.4.0 rather than a patch because the fix moves signed evidence to a new field that older verifiers reject. Nothing in the laptop quickstart touches that path, but if you are evaluating the TPM verifier specifically, install from main. LIMITATIONS.md is where we keep the rest of these, including the ones still open.
Two boundaries worth naming before anyone has to ask. It governs the tool boundary, not the model boundary: it sees no inference, no context window, and no chat output that never becomes a tool call. And as someone who sells confidential computing for a living, current CC silicon is not custody-grade against an attacker who physically owns the machine, see TEE.fail and BadRAM. The threat model this actually buys you is the rogue admin and the compromised host OS at an operator you have some basis to trust, not a hostile hardware owner.
Happy to go into the Cedar evaluation path, the audit chain format, or why the receipt is a separate spec rather than a log line.
recursive•1h ago
To the OP: your sibling explanation comment here is flagged and dead. I don't know why.
mosiddi•1h ago
Ten-minute laptop version, no hardware and no signup: https://agentrust-io.com/quickstart/ You install the runtime, write one forbid rule, watch a tool call come back 403 POLICY_DENY before a byte leaves the machine, then verify the receipt it produced.
That last step is the only part I would care about if a stranger posted this, so: run the verifier on a laptop and you get six checks passing and one failing.
Exit code 1. Software mode has no hardware root of trust to offer, so the tool refuses to call the result verified. I would rather hand you that than a green check that means nothing. It reports verified only when the platform evidence is itself cryptographically checked: for SEV-SNP the report signature plus VCEK to ASK to ARK with the ARK pinned by the operator, for TDX the DCAP quote to a pinned Intel root, for TPM 2.0 the signature over the TPMS_ATTEST plus the AK certificate chain to a manufacturer CA the operator pins.We got that last one wrong, and it is still wrong in the release you would install right now. The tpm2 branch checked the measurement and never the signature over it, so a forged TPMS_ATTEST with correct magic and matching qualifying_data was reported as hardware-attested. That is issue #370, fixed in #469, on main as of this week and not yet on PyPI, so pip install gives you 0.3.0 and 0.3.0 has the defect. It ships as 0.4.0 rather than a patch because the fix moves signed evidence to a new field that older verifiers reject. Nothing in the laptop quickstart touches that path, but if you are evaluating the TPM verifier specifically, install from main. LIMITATIONS.md is where we keep the rest of these, including the ones still open.
Two boundaries worth naming before anyone has to ask. It governs the tool boundary, not the model boundary: it sees no inference, no context window, and no chat output that never becomes a tool call. And as someone who sells confidential computing for a living, current CC silicon is not custody-grade against an attacker who physically owns the machine, see TEE.fail and BadRAM. The threat model this actually buys you is the rogue admin and the compromised host OS at an operator you have some basis to trust, not a hostile hardware owner.
Happy to go into the Cedar evaluation path, the audit chain format, or why the receipt is a separate spec rather than a log line.