feat: publish security & permanence audit, correct false readiness claims

src/components/Footer.astro

@@ -31,6 +31,7 @@
           <li><a href="/docs/quickstart.html">Quickstart</a></li>
           <li><a href="/docs/cli-reference.html">CLI Reference</a></li>
           <li><a href="/questions.html">All Questions</a></li>
+          <li><a href="/security-audit.html">Security Audit</a></li>
         </ul>
       </div>
       <div>

src/components/Nav.astro

@@ -165,6 +165,13 @@ const { currentPath = '' } = Astro.props;
                 <span class="dropdown-item-desc">vs function calling, microservices, serverless</span>
               </span>
             </a>
+            <a href="/security-audit.html" class="dropdown-item" role="menuitem">
+              <span class="dropdown-icon">◎</span>
+              <span>
+                <span class="dropdown-item-title">Security Audit</span>
+                <span class="dropdown-item-desc">Honest security &amp; permanence status</span>
+              </span>
+            </a>
           </div>
         </div>
       </li>
@@ -197,6 +204,7 @@ const { currentPath = '' } = Astro.props;
   <a href="/questions.html">All Questions</a>
   <a href="/examples.html">Examples</a>
   <a href="/compare.html">Compare</a>
+  <a href="/security-audit.html">Security Audit</a>
   <a href="/blog.html">Blog</a>
   <a href="/roadmap.html">Roadmap</a>
   <a href="/changelog.html">Changelog</a>

src/pages/questions/is-traverse-production-ready.astro

@@ -2,8 +2,8 @@
 import QuestionLayout from '@layouts/QuestionLayout.astro';
 
 const relatedLinks = [];
-const _body = "<p>Traverse v0.7.0 is stable for the local placement target. You can use the local runtime, contract validation, CLI, and MCP server in production today. The project is pre-1.0, which means minor version bumps can include breaking API changes. If you build on Traverse now, pin your version and read the changelog before upgrading.</p>\n\n      <h2>What is stable today</h2>\n      <ul>\n        <li>Local placement target — runs WASM capabilities in the local process</li>\n        <li>Contract validation — preconditions and postconditions against JSON Schema</li>\n        <li>The traverse CLI — capability registration, invocation, and trace inspection</li>\n        <li>The MCP server — tools/list and tools/call for AI agent integration</li>\n        <li>Trace artifacts — every execution is recorded and inspectable</li>\n        <li>The governing spec model — linking contracts to source documents</li>\n      </ul>\n\n      <h2>What is still maturing</h2>\n      <ul>\n        <li>Browser, edge, cloud, and AI pipeline placement targets — in development</li>\n        <li>Hosted registry — not yet available</li>\n        <li>Language SDKs for Python, TypeScript, Go — planned</li>\n        <li>Streaming output — not yet supported</li>\n        <li>Capability signing and access controls — on the roadmap</li>\n      </ul>\n\n      <h2>How to evaluate readiness for your use case</h2>\n      <p>If you need the local target only — running contracts on one machine, exposing capabilities to an AI agent via MCP — then Traverse is ready for that today. The core execution model is solid. The things still in progress are around the broader deployment surface, not the fundamental runtime behavior.</p>\n      <p>If you need to deploy capabilities to the browser or cloud, or if you need a hosted registry your team can share, those features are not there yet. You would be building ahead of the stable surface and accepting more churn.</p>\n\n      <h2>The pre-1.0 caveat</h2>\n      <p>Pre-1.0 means Enrico can change APIs between minor versions if the design requires it. In practice, the contract format and core runtime behavior have been stable across recent releases. The parts that change are the edges — new placement targets bring new APIs, and those settle as the targets mature. Follow the <a href=\"/changelog.html\">changelog</a> and the <a href=\"/questions/what-is-traverse-roadmap.html\">roadmap</a> to stay informed.</p>";
-const _jsonLd = "{\"@context\":\"https://schema.org\",\"@type\":\"FAQPage\",\"mainEntity\":[{\"@type\":\"Question\",\"name\":\"Is Traverse production ready?\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"Traverse v0.7.0 is stable for the local placement target. The local runtime, contract validation, MCP server, and CLI are all usable in production today. Other placement targets (browser, edge, cloud, AI pipeline) are in development. The project is pre-1.0, meaning APIs can change between minor versions.\"}}]}";
+const _body = "<p>Traverse v0.7.0 is functionally stable for the local placement target, but a <a href=\"/security-audit.html\">security and permanence audit</a> found dangerous defaults that mean the framework should be treated as pre-production for anything network-facing. The local runtime and contract validation are solid. The CLI's HTTP server and the MCP server currently have real authentication gaps. The project is also pre-1.0, so minor version bumps can include breaking API changes. Pin your version and read the changelog before upgrading.</p>\n\n      <h2>What is stable today</h2>\n      <ul>\n        <li>Local placement target — runs WASM capabilities in the local process</li>\n        <li>Contract validation — preconditions and postconditions against JSON Schema</li>\n        <li>The traverse CLI — capability registration, invocation, and trace inspection (local use; the HTTP serve mode has known gaps, see below)</li>\n        <li>The MCP server — tools/list and tools/call for AI agent integration, trusted as a local IDE child process only (no auth boundary, see below)</li>\n        <li>Trace artifacts — every execution is recorded and inspectable</li>\n        <li>The governing spec model — linking contracts to source documents</li>\n      </ul>\n\n      <h2>What is still maturing</h2>\n      <ul>\n        <li>Browser, edge, cloud, and AI pipeline placement targets — in development</li>\n        <li>Hosted registry — not yet available</li>\n        <li>Language SDKs for Python, TypeScript, Go — planned</li>\n        <li>Streaming output — not yet supported</li>\n        <li>JWT verification, Sigstore verification, and MCP authentication — implemented as insecure defaults or stubs today, not yet real. Ed25519 artifact signing does work.</li>\n      </ul>\n\n      <h2>Known security gaps</h2>\n      <p>A framework-wide audit (July 2026) found the following before recommending any network exposure:</p>\n      <ul>\n        <li>The HTTP server defaults to Development mode and never forces Production; unsigned artifacts are allowed to run.</li>\n        <li>JWT identity is parsed from the base64 payload only — there is no signature or JWKS verification, so a forged token is accepted.</li>\n        <li>The MCP stdio server has no authentication at all. Anything that can write to its stdin can execute capabilities and read full execution traces.</li>\n        <li>Sigstore artifact verification is currently a stub that always reports \"verified\" rather than performing real verification.</li>\n      </ul>\n      <p>None of this affects the local runtime itself — WASM sandboxing and contract validation are unaffected. It affects anything that exposes the HTTP API or the MCP server beyond a fully trusted local process. Read the full <a href=\"/security-audit.html\">security audit</a> for severity, file locations, and the remediation roadmap.</p>\n\n      <h2>How to evaluate readiness for your use case</h2>\n      <p>If you need the local target only — running contracts on one machine, exposing capabilities to an AI agent via MCP — then Traverse is ready for that today. The core execution model is solid. The things still in progress are around the broader deployment surface, not the fundamental runtime behavior.</p>\n      <p>If you need to deploy capabilities to the browser or cloud, or if you need a hosted registry your team can share, those features are not there yet. You would be building ahead of the stable surface and accepting more churn.</p>\n\n      <h2>The pre-1.0 caveat</h2>\n      <p>Pre-1.0 means Enrico can change APIs between minor versions if the design requires it. In practice, the contract format and core runtime behavior have been stable across recent releases. The parts that change are the edges — new placement targets bring new APIs, and those settle as the targets mature. Follow the <a href=\"/changelog.html\">changelog</a> and the <a href=\"/questions/what-is-traverse-roadmap.html\">roadmap</a> to stay informed.</p>";
+const _jsonLd = "{\"@context\": \"https://schema.org\", \"@type\": \"FAQPage\", \"mainEntity\": [{\"@type\": \"Question\", \"name\": \"Is Traverse production ready?\", \"acceptedAnswer\": {\"@type\": \"Answer\", \"text\": \"Traverse v0.7.0's local runtime and contract validation are stable, but a security audit found the HTTP server defaults to an insecure Development mode and the MCP server has no authentication. Treat network-facing surfaces as pre-production until those gaps close. Other placement targets (browser, edge, cloud, AI pipeline) are in development. The project is pre-1.0, meaning APIs can change between minor versions.\"}}]}";
 ---
 <QuestionLayout
   title={"Is Traverse production ready?"}

src/pages/questions/what-is-traverse-security-model.astro

@@ -2,7 +2,7 @@
 import QuestionLayout from '@layouts/QuestionLayout.astro';
 
 const relatedLinks = [];
-const _body = "<p>Traverse enforces two layers of security: WASM sandbox isolation for execution, and contract validation as hard gates on input and output. A capability cannot read arbitrary memory, make network calls, or access the filesystem unless the host explicitly grants those permissions through WASI imports.</p>\n\n      <h2>WASM sandbox</h2>\n      <p>Every capability runs inside a Wasmtime sandbox. WASM has a defined memory model with no access to host memory outside the instance's linear memory. Syscalls are mediated through WASI. By default, Traverse grants no WASI capabilities — no file access, no network, no environment variables. You grant only what a capability explicitly needs.</p>\n\n      <h2>Contract as a security gate</h2>\n      <p>The contract defines what inputs are valid and what outputs are acceptable. The runtime rejects any call that does not satisfy the preconditions before the WASM binary ever runs. A malformed or unexpected input that could cause undefined behavior inside the WASM module never reaches the module.</p>\n\n      <h2>Supply chain considerations</h2>\n      <p>WASM binaries are deterministic and can be checksummed. You can verify a registered capability binary against a known hash before deploying. The registry stores the binary alongside the contract, so you can audit both. This matters when running third-party capabilities.</p>\n\n      <h2>What Traverse does not provide</h2>\n      <ul>\n        <li>Authentication or authorization — who can call a capability is your responsibility</li>\n        <li>Network security — the MCP server transport security is your responsibility</li>\n        <li>Key management or secret injection into capabilities</li>\n        <li>Runtime monitoring or anomaly detection</li>\n      </ul>\n\n      <p>Traverse gives you a sandboxed, contract-validated execution environment. Layering auth, transport security, and observability on top is your design decision.</p>";
+const _body = "<p>Traverse enforces two layers of security: WASM sandbox isolation for execution, and contract validation as hard gates on input and output. A capability cannot read arbitrary memory, make network calls, or access the filesystem unless the host explicitly grants those permissions through WASI imports.</p>\n\n      <h2>WASM sandbox</h2>\n      <p>Every capability runs inside a Wasmtime sandbox. WASM has a defined memory model with no access to host memory outside the instance's linear memory. Syscalls are mediated through WASI. By default, Traverse grants no WASI capabilities — no file access, no network, no environment variables. You grant only what a capability explicitly needs.</p>\n\n      <h2>Contract as a security gate</h2>\n      <p>The contract defines what inputs are valid and what outputs are acceptable. The runtime rejects any call that does not satisfy the preconditions before the WASM binary ever runs. A malformed or unexpected input that could cause undefined behavior inside the WASM module never reaches the module.</p>\n\n      <h2>Supply chain considerations</h2>\n      <p>WASM binaries are deterministic and can be checksummed. You can verify a registered capability binary against a known hash before deploying, and Ed25519 artifact signature verification is implemented. The runtime checksum gate itself is not yet enforced automatically in <code>verify_artifact</code>, and Sigstore verification is currently a stub — see the <a href=\"/security-audit.html\">security audit</a> for exact status. The registry stores the binary alongside the contract, so you can audit both. This matters when running third-party capabilities.</p>\n\n      <h2>What Traverse does not provide</h2>\n      <ul>\n        <li>Authentication or authorization — who can call a capability is your responsibility</li>\n        <li>Network security — the MCP server transport security is your responsibility</li>\n        <li>Key management or secret injection into capabilities</li>\n        <li>Runtime monitoring or anomaly detection</li>\n      </ul>\n\n      <p>Traverse gives you a sandboxed, contract-validated execution environment. Layering auth, transport security, and observability on top is your design decision. For a full breakdown of current gaps — including the MCP server's lack of authentication and the HTTP server's insecure default mode — see the <a href=\"/security-audit.html\">security and permanence audit</a>.</p>";
 const _jsonLd = "{\"@context\":\"https://schema.org\",\"@type\":\"FAQPage\",\"mainEntity\":[{\"@type\":\"Question\",\"name\":\"What is Traverse's security model?\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"Traverse runs capabilities inside a WASM sandbox with no host access by default. The contract enforces input and output constraints as hard gates before and after execution. Capabilities cannot reach outside their sandbox unless the host explicitly grants capabilities via WASI imports.\"}}]}";
 ---
 <QuestionLayout