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.
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.