Repository navigation
Integration: would a runtime governance proxy in front of MCP servers be in scope for third-party integrations? #12492
Description
Hi maintainers,
Opening an issue first to gauge appetite before any code work, in the same shape as #12423.
Question
Would maintainers accept a third-party integration entry for Vaara (AGPL-3.0-or-later, https://github.com/vaaraio/vaara) used as a transparent runtime governance proxy in front of any stdio MCP server a Continue.dev user configures?
The intended contribution:
- A docs page in the third-party integrations area covering the three-step setup recipe.
- A small worked example pointing at an existing MCP server (Vaara already ships demos for GitHub MCP and SAP MCP).
- No core Continue.dev changes. The proxy is invoked as the user's configured MCP
command, sitting between Continue.dev and the upstream server.
What Vaara does at the MCP layer
The proxy emits a hash-chained audit record per tools/call, resources/read, and prompts/get, with optional Ed25519-signed OVERT 1.0 envelopes for the same set. Operator allowlist and denylist flags filter tools, resources, and prompts at the perimeter. Streaming notifications/progress and notifications/message are correlated to the originating tool call and audited. Initialization handshake forwards unchanged.
Concrete usage shape:
python -m vaara.integrations.mcp_proxy \
--upstream <user's mcp command> \
--db ./mcp_audit.dbPoint Continue.dev's MCP client at the proxy instead of the upstream, no other changes.
Why this might fit
Issue #12068 (APEX RGPD), #12172 (granular tool approval policy), #12248 (subagent permissions and policy bypass), and #11468 (TLS verification and OAuth) suggest Continue.dev users are asking for governance and audit surfaces at the MCP edge. A drop-in proxy hands that surface to deployers without core changes.
Credentials
- Vaara is acknowledged in the industry contributors of IMDA's Model AI Governance Framework for Agentic AI v1.5 (Singapore, 20 May 2026) alongside Google, IBM, Microsoft, AWS, OCBC, Tencent.
- AMD developer testimonial, May 2026.
- OpenSSF Best Practices Project 12612.
What I would draft if you say yes
- A docs page following the integration pattern for third-party MCP layers.
- A short demo recipe with one upstream MCP server users will recognise.
- A test fixture proving the proxy preserves upstream tool semantics while writing the audit chain.
If you say no
Fine. No PR will follow. I will not bump or repost.
Henri Sirkkavaara
hello@vaara.io
https://github.com/vaaraio/vaara
Activity
Ram9199 commentedon Jun 13, 2026
I am doing incident discovery around MCP/agent authority rather than product feedback.
What real incident, near miss, customer requirement, or production failure made runtime governance/audit at the MCP edge feel necessary? After it happened, did anything change - disabled tools, sandboxing, separate credentials, manual approvals, audit logging, custom policy, or no change?
Trying to distinguish lived operational pain from reasonable pre-incident hardening.
hegu-1 commentedon Jul 16, 2026
A runtime governance proxy in front of MCP servers seems like a clean integration point because it does not require every client or server to reinvent policy enforcement.
The key contract I would look for is:
That would let Continue users keep their existing MCP ecosystem while adding an organizational control plane around it.
I have been framing this as part of an enterprise AI OS architecture: models, clients, and tools change, but governance, identity, workflow, and audit need to remain stable across them: https://github.com/hegu-1/enterprise-ai-os-architecture
SaravananJaichandar commentedon Jul 18, 2026
Runtime governance proxy in front of MCP is exactly the shape I ended up needing. Been building this as etch.systems, sits between the client and the MCP servers, records every call to an append only event log for later replay. Third party integration seems like the right pattern rather than baking it upstream, since teams that do not need it should not have to configure around it. Happy to share how it hooks in if useful.
SaravananJaichandar commentedon Jul 21, 2026
Speaking as the maintainer of a shipped Continue adapter (world-model-mcp, Python MCP, currently around 2,500 monthly PyPI installs). Yes, in scope. The abstraction that actually works is to sit between the LLM proxy layer and the MCP transport, not in front of the MCP server.
Two reasons. First, most governance signals like token cost, provider routing, secret scanning of outbound prompts live at the model call, not at the tool call. Second, MCP servers already speak stdio and HTTP; wrapping them means a per-server integration cost that scales badly.
The pattern that ships cleanly today is an OpenAI-compatible proxy chokepoint plus a policy engine plus a signed audit chain. Reference implementation of the audit half is in world-model-mcp v0.13 (Merkle tree, hybrid Ed25519 and SLH-DSA signatures). If Continue picks this direction, happy to contribute the schema and adapter surface.
Keesan12 commentedon Jul 21, 2026
I think a governance proxy only becomes useful when it gives the person running the agent a clear answer to three questions: what was allowed, what actually happened, and can we safely continue.
I'm building MartinLoop around that gap. We do not need another coding agent. We need a way to trust the ones already doing real work: a budget before the run, verification before calling it done, and a receipt after. We just shipped Arcade as a more proactive terminal experience for long-running agent sessions, because the hard moments tend to happen while nobody is staring at the screen.
Would be happy to compare notes on the boundary between MCP policy and runtime accountability. Feedback is welcome at https://github.com/Keesan12/martin-loop or support@martinloop.com.
vaaraio commentedon Jul 23, 2026
Fair distinction, and you are right that cost, provider routing, and outbound prompt secret-scanning live at the model call. Those are model-layer concerns and a proxy there is the right place for them.
The MCP edge is a different boundary, and that is the one I am aimed at. The tool call is where the agent does something irreversible to the outside world: writes a file, moves money, reads a customer record, hits an external API. That is the authority boundary (allow, deny, ask on a real action) and the evidence boundary (a tamper-evident record of what actually happened that someone who does not run your software can verify later). Neither of those lives at the model call. The model deciding to try a tool is not the same as the tool running.
So I do not think it is one or the other. A model-layer governor and an MCP-edge receipt proxy answer different questions: what is this run costing and what is it about to send, versus what did the agent actually do and can an auditor prove it. You can run both. Redacting tool output before it returns to the client is a real tool-layer job and the proxy does it there.
If the concern is the extra transport hop, that is a fair engineering point and worth measuring. The placement in front of the MCP server is deliberate: that is where the action and the trust boundary sit.
Paraphern commentedon Oct 12, 2026
Different layer from the three governance proxies above, but it is the prerequisite for all of them, so worth putting on the same thread: surface integrity. Every proxy described here - call classification, allow/deny, output redaction, event logging - governs calls against a tool surface it assumes is stable. It is not. MCP servers change tool descriptions, input schemas and behavioral annotations between sessions, without a release the consumer sees and without any signal to the proxy. A governance rule that allows "read-only tools" is blind if
readOnlyHintflipped server-side; an allowlist built on tool names goes stale when a tool gains an exfiltration-shaped parameter while keeping its name.The layer that makes governance proxies sound: pin the tool contract at approval time - hash each tool's name, description, inputSchema and behavioral annotations - then diff on every
tools/listround, and grade changes by direction before the governance layer sees them. The proxy then gets "surface unchanged since approval" (proceed with policy) or "surface drifted: 2 new parameters, 1 annotation flip" (re-evaluate policy before allowing calls). This answers Ram9199's incident question from the field: the incidents that made us build this layer were silent surface changes - a server quietly adding a team environment-variables read channel to a nominally read-only tool, in a release whose notes covered something else entirely; another flipping validation constraints across a minor version wave - none of which any runtime policy would have caught, because the calls themselves were individually legitimate against the surface that existed at call time.We ship that layer open-source (rugsnare, Apache-2.0) - pin, graded diff, CI gate, per-version drift records for 14 public MCP servers. It sits below the governance proxies described above and composes with any of them rather than competing.