From 21d73421028ba5230691c72d7922ca4f37751884 Mon Sep 17 00:00:00 2001 From: Imran Siddique Date: Tue, 4 Aug 2026 13:25:35 -0700 Subject: [PATCH] docs: pin loopback in the README config and scope the tpm row to 0.3.0 Both halves are the same defect: the tree is correct and the release a reader installs is not, and the docs describe the tree. listen_addr The Quick Start config omitted listen_addr and the Configuration reference documented "0.0.0.0:8443". On the published 0.3.0 the default is unconditionally 0.0.0.0:8443 and there is no loopback guard, while CMCP_DEV_MODE=1 skips the bearer token on purpose. So following the README on 0.3.0 stands up an unauthenticated policy gateway on every interface. main already defaults to loopback in tokenless dev mode and raises ConfigError on a non-loopback bind, so pinning 127.0.0.1 explicitly is correct on both. The quickstart page was fixed for this; the README was not. tpm row STATUS.md credited report-signature verification as hardware-validated. verify_tpm_quote_chained was validated on 2026-07-31, but it had no production caller: the tpm2 branch of verify_trace_claim called only verify_tpm_measurement, which takes no signature parameter, so a forged TPMS_ATTEST with correct magic and matching qualifying_data was reported as hardware-attested (#370, fixed in #469, ships in 0.4.0). The row now says so and points TPM evaluators at main. The #431 chain caveat is unchanged and still applies after the fix. Also links agentrust-io.com/quickstart from Quick Start. The repo is the landing page for readers who never reach the docs site. Co-Authored-By: Claude Opus 5 (1M context) --- README.md | 15 ++++++++++++++- STATUS.md | 2 +- 2 files changed, 15 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index fc3eacd..d928699 100644 --- a/README.md +++ b/README.md @@ -64,10 +64,18 @@ Create `cmcp-config.yaml`: attestation: provider: auto enforcement_mode: advisory # advisory eases first-run tuning; the default is `enforcing` +listen_addr: "127.0.0.1:8443" # pin loopback: dev mode runs without a bearer token policy_bundle_path: ./policies/ catalog_path: ./catalog.json ``` +`listen_addr` is not optional here. `CMCP_DEV_MODE=1` deliberately skips the +bearer token requirement so you can try things quickly, and on the published +0.3.0 the default bind is `0.0.0.0:8443`, so omitting it stands up an +unauthenticated gateway on every interface on your machine. Later versions +default to loopback and refuse to bind a non-loopback address without +`CMCP_BEARER_TOKEN`, but pin it explicitly and the config is correct on both. + Start the gateway: ```bash @@ -82,6 +90,11 @@ curl -X POST http://localhost:8443/mcp \ -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"salesforce.contacts","arguments":{"query":"Acme Corp"},"_cmcp":{"session_id":"s1","workflow_id":"demo-agent"}}}' ``` +Prefer a guided version? [agentrust-io.com/quickstart](https://agentrust-io.com/quickstart/) +walks the same path in about ten minutes on a laptop, with no hardware and no +signup: install, write one Cedar `forbid` rule, watch a tool call return 403 +`POLICY_DENY` before it reaches an upstream, then verify the signed receipt. + See [docs/quickstart.md](docs/quickstart.md) for the full walkthrough: Cedar policy, tool catalog, first TRACE Claim, and verification (no hardware TEE required). --- @@ -162,7 +175,7 @@ attestation: policy_bundle_path: policies/ # directory containing .cedar files and manifest.json catalog_path: catalog.json # approved tool catalog -listen_addr: "0.0.0.0:8443" +listen_addr: "127.0.0.1:8443" # tokenless dev mode is loopback-only; set CMCP_BEARER_TOKEN before binding wider max_response_size_bytes: 2097152 # 2 MB default policy_reload_interval_seconds: 0 # 0 = disabled; restart required to update policy ``` diff --git a/STATUS.md b/STATUS.md index 5dbc512..cac374d 100644 --- a/STATUS.md +++ b/STATUS.md @@ -25,7 +25,7 @@ picture is stated once. Developer Preview: interfaces may change before v1.0. | Offline verification (`cmcp_verify`) | Shipped | No operator trust required when the verifier independently checks the attestation report. | | Agent Manifest identity binding | Shipped | Optional; trust in the issuer key is an out-of-band PKI concern. | | Attestation verifiers: `sev-snp`, `tdx` | Shipped | Verified end to end against genuine hardware evidence: an Azure CVM SEV-SNP report (VCEK chain to the AMD ARK-Milan root, ECDSA-P384 report signature, paravisor `REPORT_DATA` binding) and a GCP C3 Intel TDX DCAP v4 quote (PCK chain to the pinned Intel SGX Root CA, QE binding, quote signature). Runs are recorded in [`docs/testing/hardware-validation.md`](docs/testing/hardware-validation.md). This validates the *verifier* against real quotes; quote generation still requires the corresponding hardware, and TCB status stays in `unverified_fields`. | -| Attestation verifier: `tpm` | Partial | Report parsing and report-signature verification are hardware-validated: an AK-signed quote from an Azure Trusted Launch vTPM was verified end to end on 2026-07-31 and tampered copies were rejected ([`docs/testing/hardware-validation.md`](docs/testing/hardware-validation.md)). The certificate chain is **not** verified: `ek_cert_chain` is unconditionally unverified (#431), and chaining is host-dependent rather than merely unimplemented. Azure Trusted Launch presents two AK certificate hierarchies concurrently at NV index `0x01C101D0`, and on the `Global Virtual TPM CA - 03` variant the AIA extension is absent entirely, so there is nothing to walk and no chain to a pinnable root. Pin the root your own hosts present; a mixed fleet needs both. | +| Attestation verifier: `tpm` | Partial | **Not in 0.3.0, the current PyPI release.** `verify_tpm_quote_chained` was hardware-validated on 2026-07-31 (an AK-signed quote from an Azure Trusted Launch vTPM verified end to end, tampered copies rejected, see [`docs/testing/hardware-validation.md`](docs/testing/hardware-validation.md)), but it had no production caller: the `tpm2` branch of `verify_trace_claim` called only `verify_tpm_measurement`, which takes no signature parameter, so a forged `TPMS_ATTEST` with correct magic and matching `qualifying_data` was reported as hardware-attested (#370). Fixed in #469 and shipping in 0.4.0. If you are evaluating the TPM verifier on 0.3.0, install from `main` instead. The certificate chain is **not** verified even after that fix: `ek_cert_chain` is unconditionally unverified (#431), and chaining is host-dependent rather than merely unimplemented. Azure Trusted Launch presents two AK certificate hierarchies concurrently at NV index `0x01C101D0`, and on the `Global Virtual TPM CA - 03` variant the AIA extension is absent entirely, so there is nothing to walk and no chain to a pinnable root. Pin the root your own hosts present; a mixed fleet needs both. | | `opaque` provider | Not implemented | Opt-in placeholder; excluded from auto-detect. Selecting it explicitly raises `ATTESTATION_PROVIDER_NOT_IMPLEMENTED` rather than falling through silently. | | `gpu-cc` (NVIDIA H100/H200/Blackwell, via NRAS) | Planned (v0.2) | | | Transparency-log anchoring for TRACE Claims | v0.2 | Write and lookup. |