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. |