Ten demos, about twelve minutes end to end. Four cover custody of model weights. Five govern what an agent does at the tool boundary. One governs model calls through an OpenAI-compatible endpoint.
+Ten demos, about thirteen minutes end to end. Four cover custody of model weights. Five govern what an agent does at the tool boundary. One governs model calls through an OpenAI-compatible endpoint.
CMCP_DEV_MODE=1 · no special hardwaregit clone https://github.com/agentrust-io/demos && cd demos pip install -r requirements.txt -export CMCP_BEARER_TOKEN=demo-token python demo.py # all ten, pausing before each +python demo.py --no-pause # straight through, no prompts python demo.py 6 # just demo 6-
The requirements install cMCP for demos 1 to 5, Weight Custody Manifest for demos 6 to 9, and the OpenAI client for demo 10. Source: github.com/agentrust-io/demos.
+The requirements install cMCP for demos 1 to 5, Weight Custody Manifest for demos 6 to 9, and the OpenAI client for demo 10. demo.py sets dev mode and the bearer token for you, so there is nothing to export. Source: github.com/agentrust-io/demos.
Demos 6 to 9 protect the weights. These five govern the tool boundary: what the agent is allowed to call, under which workflow, with what compliance attributes, and what evidence survives afterwards. Cedar policy is enforced on every call and each session closes with a signed TRACE claim.
+Demos 6 to 9 protect the weights. These six put the policy at the boundary the agent has to cross: five at the tool call, and demo 10 at the model call. What is it allowed to invoke, under which workflow, with what compliance attributes, and what evidence survives afterwards. Cedar is enforced on every call and each session closes with a signed TRACE claim.
Before you start. Python 3.11+ · pip · macOS or Linux · two terminal windows · about ten minutes · no special hardware.
+Every command and every output on this page was last run end to end against cmcp-runtime 0.4.0 on 20 August 2026. If a step does not do what it says here, that is a bug and worth reporting.
workflow_id is the only field the runtime reads out of _cmcp. The session id is a label for your own logs: the runtime mints its own session id, which is why step 5 looks it up instead of assuming it.
Your policy stops a PII record from leaving on a tool call, before it reaches Salesforce, decided by the rule you wrote, enforced where the agent can't tamper with it. That's the barrier most teams can't cross today: shipping an agent you can actually prove is governed.
-HTTP/1.1 403 Forbidden · "message": "Request denied by policy" · "error_code": "POLICY_DENY"
+Your policy stopped a PII record from leaving on a tool call, before it reached Salesforce, decided by the rule you wrote, enforced where the agent can't tamper with it. That's the barrier most teams can't cross today: shipping an agent you can actually prove is governed.
+Keep an eye on that call_id. The same id lands in the audit chain, so the deny you just watched is the deny you can hand to someone else in step 5. A refusal nobody can check afterwards is just a log line.
Expected output in dev mode:
+Expected output in dev mode. The CRYPTO-001 line comes first and is an advisory, not a failure: it is the CLI saying up front that a software-mode key binding proves nothing about hardware.