Docs: add Vaara (transparent runtime governance proxy) to documentation/docs/mcp/

Please explain the motivation behind the feature request.

Goose users running MCP extensions in real workflows increasingly need a per-action audit chain and per-tool policy enforcement at the protocol boundary, not only at the LLM input layer or the goose-mode permission gate. #9407 (Command-Level Permissions for AI Terminal Execution) is a recent example of this demand surfacing inside the Goose queue. #9322 (ToolBuild hooks) is another, where the author considered "a proxy layer that intercepts and rewrites tool definitions" as an alternative shape.

Vaara is an Apache-2.0 OSS MCP proxy that sits between Goose and any stdio MCP server. It writes a hash-chained, tamper-evident audit record per tools/call, resources/read, and prompts/get, optionally emits a signed OVERT 1.0 attestation envelope per interaction, and supports allow/deny filtering on tools, resources, and prompts at the perimeter. The proxy is transparent. The initialize handshake, tools/list, resources/list, prompts/list, and notifications/* all forward unchanged. Goose's existing prompt-injection classifier, tool permissions, .gooseignore, and OpenTelemetry exporter compose cleanly with it. Different layers.

Describe the solution you'd like.

Add Vaara to documentation/docs/mcp/ as vaara-mcp.mdx following the existing _template_.mdx. Users configure Vaara as a Command-line Extension whose cmd is the Vaara proxy module and whose --upstream points at whichever MCP server they want governed. The docs page would mirror the existing per-server tutorials in shape (CLI + Desktop tabs, install, configure, verify).

A working integration recipe with a concrete upstream lives at https://github.com/vaaraio/vaara/tree/main/examples/goose-mcp-proxy-demo. The README walks through the three-step setup (install Vaara, register as Command-line Extension, restart Goose), the audit-trail shape, the compose-with-existing-features section, and troubleshooting notes. A paste-ready snippet for ~/.config/goose/config.yaml is in the same directory.

Describe alternatives you've considered.

• The native hooks approach in #9322 lives inside the Goose process and operates at the tool-build layer. Useful for token-trimming and schema rewriting. Less useful for tamper-evident audit, because the records would still be authored by the same process they govern.
• The terminal-command allow/deny pattern in #9407 handles one specific tool. Vaara generalises to any MCP tool a Goose extension exposes, with allow-list, deny-list, ESCALATE-to-human routing, and a downstream signed-envelope option.
• Cloud guardrails (Bedrock Guardrails, Azure Content Safety, GCP Model Armor) cover content scanning at the LLM input or output layer, not tool-call audit at the protocol boundary. Vaara has adapters that consume their findings as upstream signals into the same audit chain, so they compose rather than substitute.

Additional context.

• Vaara is acknowledged in the industry contributors of the IMDA Model AI Governance Framework for Agentic AI v1.5 (Singapore, 20 May 2026).
• AMD developer testimonial, May 2026.
• OpenSSF Best Practices Project 12612.

If maintainers say yes, I will open a draft PR with documentation/docs/mcp/vaara-mcp.mdx following _template_.mdx, plus a short tutorial entry if scope permits. If you say no, no PR will follow.

• I have verified this does not duplicate an existing feature request

Henri Sirkkavaara hello@vaara.io https://github.com/vaaraio/vaara