[salterisp]

Really well thought out — anchoring every policy rule to a real incident (Clinejection, the terraform destroy incident) is a smart way to make governance feel necessary rather than bureaucratic. The observe mode is a good adoption path too.

The problem you're solving is the developer workstation side — stopping an agent from breaking the developer's own environment. I've been working on the complementary server side: controlling which users in an org can access which MCP tools, with full audit trail.

https://github.com/PanosSalt/MCP-Gateway

OAuth 2.1 + PKCE, Microsoft Entra SSO with group-based role assignment, per-tool RBAC, multi-tenant isolation. The two approaches could actually stack — Vectimus at the workstation, MCP Gateway at the server.

One question: how does Vectimus handle the case where the MCP server itself is legitimate but the tool parameters contain injected instructions? The Clinejection attack was a malicious server, but the harder problem is a legitimate server returning poisoned data that the agent then acts on.

[JXavierH]

Vectimus does input inspection on approved MCP servers, but it can only catch known bad patterns too. It does not try to solve prompt injections or if a legitimate MCP server was comprimised and returned poisoned outputs. I do plan to add additional post took hooks in future that can scan the MCP server output too.

You're project is interesting. It's a bit of an MCP proxy in a way, moreso than Azure API Management, yours seems to give more functionality. I will definitely take a look.