diff --git a/README.md b/README.md
index b55b4d1..4d762d3 100644
--- a/README.md
+++ b/README.md
@@ -7,60 +7,250 @@
### Enforce MCP tool policy where it cannot be tampered with
-
-
+
+
- Quick Start |
- Architecture |
- Specification |
- Changelog
+
+ Quick Start ·
+ Architecture ·
+ Configuration ·
+ CLI ·
+ Changelog
+
-[](https://github.com/agentrust-io/cmcp/actions/workflows/ci.yml)
-[](LICENSE)
-[](https://pypi.org/project/cmcp-runtime/)
-[](https://discord.gg/9JWNpH7E)
+[](https://github.com/agentrust-io/cmcp/actions/workflows/ci.yml) [](LICENSE) [](https://pypi.org/project/cmcp-runtime/) [](https://scorecard.dev/viewer/?uri=github.com/agentrust-io/cmcp) [](https://discord.gg/9JWNpH7E)
-> **Developer Preview** — launching at Confidential Computing Summit, June 23 2026.
+> **Developer Preview** - launching at Confidential Computing Summit, June 23 2026. May have breaking changes before v1.0.
-Hardware-attested policy enforcement for MCP tool calls. cMCP intercepts every tool call, evaluates it against a Cedar policy bundle, and enforces the decision inside a Trusted Execution Environment (TEE). The policy bundle hash is measured into the hardware attestation report before any code runs — the control plane governing tool calls runs where it cannot be reached by the process it governs.
+Your agent calls Snowflake, Salesforce, a dozen APIs. What stops it from leaking a customer's data on one of those calls? If a regulator asks, could you prove it didn't?
-Every tool call produces a signed [TRACE](https://github.com/agentrust-io/trace-spec) record: cryptographic proof of what ran, under which policy, in which TEE.
+---
-## Quick start
+## The problem
+
+An agent calls a tool. The policy engine says allow. The tool call goes through.
+
+None of that proves the policy engine itself was not compromised. Software-only MCP governance cannot guarantee:
+
+- The Cedar policy on disk is the one that ran. A rogue admin can swap the bundle after approval; the hash check runs inside the same OS the admin controls.
+- The allow/deny decision was not flipped in memory. A supply chain CVE in the evaluator runs in the same address space as the attacker.
+- The audit log reflects what actually happened. Any party holding the software signing key can reconstruct a valid audit chain after the fact.
+
+The control plane that governs tool calls must run where it cannot be reached by the process it governs.
+
+Hardware-attested policy enforcement for MCP tool calls. Every tool call is intercepted, evaluated against a Cedar policy bundle, and enforced by a policy engine running inside a Trusted Execution Environment (TEE). The policy bundle hash is measured into the hardware attestation report before any code runs.
+
+Unlike tunnel-based connectivity solutions, the cMCP Runtime processes tool-call payloads inside the TEE. The connectivity provider sees ciphertext, not plaintext. The only thing that leaves the enclave is the signed TRACE claim.
+
+---
+
+## Quick Start
```bash
pip install cmcp-runtime
```
+Create `cmcp-config.yaml`:
+
```yaml
-# cmcp-config.yaml
attestation:
- platform: amd-sev-snp
-policy:
- bundle: ./policy.tar.gz
- enforcement_mode: enforce
+ provider: auto
+ enforcement_mode: advisory
+policy_bundle_path: ./policies/
+catalog_path: ./catalog.json
```
+Start the gateway:
+
+```bash
+CMCP_DEV_MODE=1 cmcp start --config cmcp-config.yaml
+```
+
+Make a tool call:
+
```bash
-cmcp start --config cmcp-config.yaml
+curl -X POST http://localhost:8443/mcp \
+ -H "Content-Type: application/json" \
+ -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"}}}'
+```
+
+See [docs/quickstart.md](docs/quickstart.md) for the full walkthrough: Cedar policy, tool catalog, first TRACE Claim, and verification (no hardware TEE required).
+
+---
+
+## How it works
+
+1. The agent sends every tool call to the cMCP Gateway instead of directly to MCP servers.
+2. At startup the gateway measures the Cedar policy bundle hash into the hardware attestation report. No code runs before this measurement.
+3. Each incoming tool call is evaluated by the Cedar policy engine running inside the TEE. The result is allow, deny, or redact. The call and its decision are appended to the hardware-sealed audit chain.
+4. At the end of the session the gateway produces a TRACE Claim: a signed, hardware-attested artifact that records which tools ran, which policy decided each call, and the full audit chain. A verifier checks this without trusting the operator.
+
+```
+Agent -> cMCP Runtime -> Cedar Policy Engine (TEE) -> Tool
+ |
+ GatewayClaim (TRACE Profile)
+ +-- trace.eat_profile
+ +-- trace.runtime.platform + measurement
+ +-- trace.policy.bundle_hash
+ +-- trace.cnf.jwk (Ed25519 confirmation key)
+ +-- gateway.audit_chain (root/tip/length)
+ +-- signature (Ed25519 over canonical JSON)
+```
+
+---
+
+## Hardware providers
+
+| Provider | Platform | Assurance | Notes |
+|---|---|---|---|
+| `tpm` | TPM 2.0 / vTPM (Azure, AWS, GCP Trusted Launch) | Medium | Local TPM quote |
+| `sev-snp` | AMD SEV-SNP (Azure DCasv5, AWS C6a Nitro) | High | AMD KDS |
+| `tdx` | Intel TDX (Azure DCedsv5, GCP C3) | High | Intel PCS |
+| `gpu-cc` _(v0.2)_ | NVIDIA H100/H200/Blackwell (CC mode) | High | NVIDIA Remote Attestation Service (NRAS) |
+| `opaque` _(explicit opt-in)_ | OPAQUE Confidential Runtime | High | Set `OPAQUE_ATTESTATION_URL`; not in auto-detect chain (stub: detect() returns False, not yet implemented) |
+
+Provider auto-detects: `SEV-SNP -> TDX -> TPM -> software`. `opaque` is explicit opt-in via `OPAQUE_ATTESTATION_URL` and is never selected automatically.
+
+```python
+from cmcp_gateway.config import TEEProvider
+
+# Auto-detect (default)
+# attestation.provider: auto -> sev-snp -> tdx -> tpm -> software
+
+# Explicit hardware selection
+# attestation.provider: sev-snp
+
+# Opaque Managed Runtime (explicit opt-in only)
+# OPAQUE_ATTESTATION_URL=https://... cmcp start --config cmcp-config.yaml
+```
+
+---
+
+## Enforcement modes
+
+| Mode | Behavior | Use case |
+|---|---|---|
+| `enforcing` | Policy denies return HTTP 403; call is not forwarded | Production |
+| `advisory` | Policy denies are logged; call proceeds | First deployment, policy tuning |
+| `silent` | Policy is evaluated but nothing is logged or blocked | Baselining |
+
+Default is `enforcing`. Set `enforcement_mode: advisory` in `cmcp-config.yaml` to use advisory mode.
+
+---
+
+## Configuration
+
+`cmcp-config.yaml` full reference:
+
+```yaml
+attestation:
+ provider: auto # auto | tpm | sev-snp | tdx | opaque | software-only
+ enforcement_mode: enforcing # enforcing | advisory | silent
+ validity_seconds: 86400 # attestation freshness window (default: 24 hours)
+ staleness_policy: fail_closed # fail_closed | warn_only
+ expected_measurement: ~ # pin a specific PCR/measurement (optional)
+
+policy_bundle_path: policy/ # directory containing .cedar files and manifest.json
+catalog_path: catalog.json # approved tool catalog
+
+listen_addr: "0.0.0.0:8443"
+max_response_size_bytes: 2097152 # 2 MB default
+policy_reload_interval_seconds: 0 # 0 = disabled; restart required to update policy
```
-## Resources
+Environment variables:
+
+| Variable | Effect |
+|---|---|
+| `CMCP_DEV_MODE=1` | Use software-only TEE provider; no hardware required |
+| `CMCP_BEARER_TOKEN` | Require this bearer token on all inbound requests |
+| `OPAQUE_ATTESTATION_URL` | Enable Opaque Managed Runtime attestation (explicit opt-in) |
+
+---
+
+## CLI reference
+
+| Command | Flags | Description |
+|---|---|---|
+| `cmcp start` | `--config PATH` (required) | Start the gateway |
+| `cmcp validate-config` | `--config PATH` (required) | Validate `cmcp-config.yaml` without starting |
+| `cmcp validate-bundle` | `--bundle-path PATH` (required), `--expected-hash sha256:` (required) | Verify a Cedar bundle hash before deployment |
+
+---
+
+## TRACE Claims
+
+A `GatewayClaim` is the unit of proof handed to an auditor, regulator, or downstream verifier. It is produced per session (or per call, configurable) and signed with a key that never leaves the TEE.
+
+| Field | Description |
+|---|---|
+| `trace.eat_profile` | EAT profile URI: `tag:agentrust.io,2026:trace-v0.1` |
+| `trace.runtime` | TEE platform and hardware measurement recorded at enclave boot |
+| `trace.policy.bundle_hash` | SHA-256 of the Cedar bundle loaded at startup; changing any policy file changes this value |
+| `trace.cnf.jwk` | Ed25519 public key bound to the TEE signing key |
+| `gateway.audit_chain` | Hash-chained audit log root and tip; verifiable without replaying individual entries |
+| `signature` | Ed25519 over canonical JSON of the full claim body (RFC 8785) |
+
+Verification with the `cmcp_verify` library does not require trusting the operator. The verifier checks the signature against the TEE-bound key, the policy bundle hash against the approved value, and the audit chain for internal consistency.
-| | |
+See [docs/spec/verification-library.md](docs/spec/verification-library.md) and the [TRACE specification](https://trace.agentrust-io.com) for the full verification protocol.
+
+---
+
+## Standards alignment
+
+| Standard | Coverage |
+|---|---|
+| OWASP Agentic AI Top 10 | MCP10 (data leakage via tool calls), MCP02 (unsanctioned tools), MCP08 (provable governance), MCP04 (supply chain) |
+| NIST SP 800-207 | Policy decision point inside TEE; no implicit trust in workload identity |
+| EU AI Act Art. 12, 15 | Per-decision audit records (Art. 12); TEE-backed cybersecurity controls (Art. 15) |
+| DORA Art. 9 | Attestation chain; audit log retention via `gateway.audit_chain` |
+| RATS/EAT RFC 9711 | `GatewayClaim` is an EAT; `eat_profile` field identifies the TRACE profile |
+
+---
+
+## Security
+
+| Tool | What it checks |
+|---|---|
+| ruff | Style and import linting on every PR |
+| bandit | Python security linting on every PR |
+| pip-audit | Dependency vulnerability scan on every PR |
+| mypy | Static type checking on every PR |
+| CodeQL | Python SAST, security-extended queries, weekly |
+| OpenSSF Scorecard | Weekly scoring, SARIF upload |
+
+See [SECURITY.md](SECURITY.md) for vulnerability reporting and response SLAs. See [LIMITATIONS.md](LIMITATIONS.md) for explicit scope boundaries, including residual risks for APM payload capture, runtime config injection, and P4.1 supply chain (typosquat) that Phase 1 does not close.
+
+---
+
+## Documentation
+
+| Page | Description |
|---|---|
-| 📖 Full documentation | [cmcp.agentrust-io.com](https://cmcp.agentrust-io.com) |
-| 📄 Specification | [docs/spec/](docs/spec/) |
-| 🔑 Cedar policies | [examples/policies/](examples/policies/) |
-| 🔗 TRACE attestation | [trace-spec](https://github.com/agentrust-io/trace-spec) |
-| 🐳 Docker | [Dockerfile](Dockerfile) |
-| 💬 Discussions | [GitHub Discussions](https://github.com/orgs/agentrust-io/discussions) |
-| 📋 Changelog | [CHANGELOG.md](CHANGELOG.md) |
+| [docs/quickstart.md](docs/quickstart.md) | From zero to first TRACE Claim in under 30 minutes |
+| [docs/configuration.md](docs/configuration.md) | Full config reference with all fields and defaults |
+| [docs/SPEC.md](docs/SPEC.md) | Product specification: problem taxonomy, architecture, coverage matrix |
+| [docs/spec/threat-model.md](docs/spec/threat-model.md) | STRIDE analysis, adversary model, residual risks |
+| [docs/spec/cedar-policy.md](docs/spec/cedar-policy.md) | Cedar policy language reference and schema |
+| [docs/testing/benchmarks.md](docs/testing/benchmarks.md) | Latency and throughput benchmarks per TEE provider |
+
+---
## Contributing
-See [CONTRIBUTING.md](CONTRIBUTING.md) and [GOVERNANCE.md](GOVERNANCE.md).
+[CONTRIBUTING.md](CONTRIBUTING.md) · [GOVERNANCE.md](GOVERNANCE.md) · [Discussions](https://github.com/agentrust-io/cmcp/discussions)
+
+Join the community on [Discord](https://discord.gg/9JWNpH7E).
+
+Using cMCP in production? Add your organization to [ADOPTERS.md](ADOPTERS.md).
+
+---
+
+## License
+
+MIT - see [LICENSE](LICENSE).
diff --git a/ROADMAP.md b/ROADMAP.md
index db5b45e..1714faa 100644
--- a/ROADMAP.md
+++ b/ROADMAP.md
@@ -9,7 +9,7 @@ Scope: Minimal viable trust layer for MCP servers, sufficient for early adopters
- TRACE Claim generation from attestation evidence
- Standalone verifier CLI for offline claim inspection
-## v0.2 — Candidates
+## v0.2 — Released (June 2026)
Provider-specific attestation verification:
- TPM2 quote verification
diff --git a/docs/SPEC.md b/docs/SPEC.md
index 9bed37d..e20cd8d 100644
--- a/docs/SPEC.md
+++ b/docs/SPEC.md
@@ -293,43 +293,3 @@ Five attestable properties unique to Phase 2:
| Cross-organizational attestation chains | Party A verifies party B's server directly -- no shared operator, no SOC 2 in between. |
Not the current build focus. Revisit after Phase 1 GA and first design partner cohort feedback.
-
----
-
-## 13. Target Customer
-
-Enterprise AI platform teams and CISOs with a working agent system blocked from production by compliance, legal, or audit requirements.
-
-Qualifying question: What business are you giving up today because you cannot prove data stays protected during processing?
-
-GTM note: For production-bound regulated buyers, the entry point is the proof gap, not the software layer. Do not lead with a software-only gateway as the on-ramp and frame hardware attestation as an upgrade. For this segment the entry point is the proof gap itself.
-
----
-
-## 14. Success Metric
-
-Three enterprise design partners signed on cMCP Runtime by July 15, 2026.
-
----
-
-## 15. Open Research Questions
-
-| ID | Question | Why it matters |
-|----|----------|----------------|
-| RQ1 | Are MCP practitioners experiencing tool-call payload leakage specifically at the tool call layer? | Confirms P1 shapes are Phase 1 requirements, not inferences from the broader AI pipeline problem |
-| RQ4 | What escalates the proof gap from SOC 2 is fine to blocking production? | Determines the qualifying trigger for the sales motion |
-| RQ5 | How are enterprises solving the authorization model for agents calling external tools? | Determines near-term Phase 1 scope |
-| RQ6 | Are SaaS vendors receiving enterprise questionnaires about MCP server behavior? | Validates Phase 2 demand before building |
-
----
-
-## 16. Hypotheses Under Investigation
-
-Not yet on the opportunity tree - no primary customer validation.
-
-| ID | Hypothesis | Evidence Level |
-|----|-----------|----------------|
-| H1 | AI governance policies exist in documents but nothing gets enforced in production | Partial |
-| H2 | Enterprises need and are building an authorization model for agents calling external tools | Partial |
-| H3 | Typosquatted MCP packages and rug-pull via tool-definition mutation are exploited in production | No customer signal; CVE and threat research only |
-| H4 | Two approved MCP servers exposing the same tool name are indistinguishable to the agent routing logic | No customer signal; protocol analysis only |
diff --git a/docs/spec/cedar-policy.md b/docs/spec/cedar-policy.md
index dab4648..2bce790 100644
--- a/docs/spec/cedar-policy.md
+++ b/docs/spec/cedar-policy.md
@@ -1,10 +1,7 @@
# Cedar Policy Specification
----
-Status: Draft v0.1
-Last updated: 2026-06-04
-Stability: Unstable , expect breaking changes before v1.0
----
+!!! warning "Draft"
+ Status: Draft v0.1 · Stability: Unstable — expect breaking changes before v1.0
This document specifies the Cedar policy bundle format, policy expression examples, enforcement modes, evaluation decision flow, and related governance features for the cMCP Runtime.
diff --git a/docs/spec/component-model.md b/docs/spec/component-model.md
index aba7e6f..efd37ae 100644
--- a/docs/spec/component-model.md
+++ b/docs/spec/component-model.md
@@ -1,10 +1,7 @@
# MCP Component Model and Trust Boundaries
----
-Status: Draft v0.1
-Last updated: 2026-06-04
-Stability: Unstable , expect breaking changes before v1.0
----
+!!! warning "Draft"
+ Status: Draft v0.1 · Stability: Unstable — expect breaking changes before v1.0
Defines the full component model, trust levels per phase, and the hardware vs. software trust boundary.
diff --git a/docs/spec/verification-library.md b/docs/spec/verification-library.md
index a35127d..35ba6c0 100644
--- a/docs/spec/verification-library.md
+++ b/docs/spec/verification-library.md
@@ -1,10 +1,7 @@
# cmcp-verify: Verification Library Interface Spec
----
-Status: Draft v0.1
-Last updated: 2026-06-04
-Stability: Unstable , expect breaking changes before v1.0
----
+!!! warning "Draft"
+ Status: Draft v0.1 · Stability: Unstable — expect breaking changes before v1.0
This document is the interface specification for the `cmcp-verify` Python library. Implementation is separate from this spec. All type stubs below define the public interface that the implementation must satisfy.
@@ -59,24 +56,24 @@ def verify_trace_claim(
2. Verify signature over canonical claim body using tee_public_key
3. Check policy_bundle.hash against approved.policy_bundle_hash
4. Check tool_catalog.hash against approved.tool_catalog_hash
- 5. If agent_manifest and trusted_agent_manifest_keys are provided, verify
- the Agent Manifest issuer signature with agent-manifest SDK
- verify_manifest() and cross-check gateway.agent_identity:
- manifest_id, agent_id/authenticated_subject, subject_source, policy hash,
- catalog hash, and manifest expiry.
+ 5. If agent_manifest and trusted_agent_manifest_keys are provided, verify
+ the Agent Manifest issuer signature with agent-manifest SDK
+ verify_manifest() and cross-check gateway.agent_identity:
+ manifest_id, agent_id/authenticated_subject, subject_source, policy hash,
+ catalog hash, and manifest expiry.
6. Check attestation freshness (timestamp within max_attestation_age_seconds)
7. Verify audit chain continuity (audit_chain_root, audit_chain_tip)
Returns VerificationResult with status and details.
"""
- ...
-```
-
-`trusted_agent_manifest_keys` keeps cMCP's runtime-facing shape as raw Ed25519
-public key bytes keyed by issuer `key_id`; the verifier base64url-encodes those
-keys when calling the Agent Manifest SDK.
-
-## Per-Provider Verification Steps
+ ...
+```
+
+`trusted_agent_manifest_keys` keeps cMCP's runtime-facing shape as raw Ed25519
+public key bytes keyed by issuer `key_id`; the verifier base64url-encodes those
+keys when calling the Agent Manifest SDK.
+
+## Per-Provider Verification Steps
### TPM Verification
diff --git a/mkdocs.yml b/mkdocs.yml
index c11e640..4a814a5 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -152,5 +152,3 @@ nav:
- Governance: GOVERNANCE.md
- Roadmap: ROADMAP.md
-extra_javascript:
- - https://agentrust-io.com/supernav.js