Show HN: Vectimus – Cedar policy enforcement for AI coding agents

Show HN: Vectimus – Cedar policy enforcement for AI coding agents(github.com)

3 points by JXavierH 53 days ago | 2 comments

Hey HN. I built Vectimus because coding agents keep doing things they shouldn't and there's no runtime governance layer for the developer workstation.

The problem: Claude Code, Cursor, Gemini CLI and GitHub Copilot let agents execute shell commands, write files and call MCP servers. Most developers disable the permission prompts because they slow you down. But that means the agent can rm -rf /, read your .env, push to production or call a compromised MCP server with nothing watching.

Vectimus intercepts every tool call and evaluates it against 78 Cedar policies containing 369 rules before execution. Cedar is the policy language AWS chose for AgentCore Policy (GA this month). Evaluation runs locally via a persistent daemon in under 10ms. Zero network calls. Zero telemetry. Every evaluation produces an Ed25519-signed receipt so you have cryptographic proof of what was allowed and denied.

Every policy maps to a real incident. CVE-2025-6514 compromised 437,000+ developer environments through a malicious MCP OAuth proxy. The GitHub MCP server was hijacked via a crafted issue to exfiltrate private repo data. A Terraform agent destroyed production infrastructure. These happened.

How it hooks in: Claude Code intercepts shell commands, file writes, MCP calls and web fetches. Cursor governs shell commands, file reads/writes and MCP tool calls at the editor level. Copilot intercepts terminal commands, file edits, deletes and git pushes. Gemini CLI uses Gemini's native hook system. MCP servers are blocked by default and allowlisted per-project with input inspection. Observe mode lets you see what would be blocked before you enforce.

I also built Sentinel (https://github.com/vectimus/sentinel), a three-agent pipeline that scans for new agentic AI security incidents daily, drafts Cedar policies, replays the incident in a sandbox to prove the policy catches it, then opens a PR. The pipeline is governed by Vectimus. Every finding and policy draft is public.

All 10 OWASP Agentic Top 10 categories covered. Compliance annotations for SOC 2, NIST AI RMF, NIST CSF 2.0, EU AI Act, ISO 27001, CIS Controls and SLSA. Apache 2.0. Solo founder, built in Ireland.

Happy to go deep on the Cedar policy design, the hook architecture, the signed receipts or the OWASP mapping.

salterisp 53 days ago |

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 52 days ago | |

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.