Veto Ops

Inspiration

Giving an AI agent real write-access to infrastructure is terrifying. A bad tool call against a Kubernetes cluster can take down production. Most "agentic ops" demos either fake the danger (read-only tools) or hand-wave the safety story. We wanted an agent that could genuinely act not just suggest—while making it structurally impossible for it to act alone.

What it does

Veto Ops puts a Qwen-driven agent behind a security proxy that sits in front of a Kubernetes MCP server. The agent plans and calls. infrastructure tools through MCP, but every state-changing action is:

Suspended, not executed, until a human operator approves it
HMAC-signed and replay-protected end-to-end
RBAC-gated — operators authenticate with scoped permissions, not a shared secret
Backstopped at the kernel level by a BPF-LSM failsafe executor that can block or correlate execution independently of the application layer
Fully audited — every agent decision, human approval, and executed Action is logged for after-the-fact review

So the agent gets autonomy over proposing and executing real operations, But a human always holds the veto—hence the name.

How we built it

The proxy is a FastAPI service `that forwards MCP traffic to a Kubernetes-facing MCP server, intercepting write operations into a persistent, atomic approval queue (SQLAlchemy + Alembic-managed schema) The agent (agent/`) is a Qwen3.7-max client against Alibaba Cloud DashScope's OpenAI-compatible Responses API, running a tool-calling over the same MCP surface. A separate BPF-LSM component enforces execution policy at the kernel level as a defense-in-depth failsafe, independent whether the Python layer is compromised or misconfigured. Prometheus metrics and OpenTelemetry tracing give visibility into both the prox the agent loop. The stack deploys to Alibaba Cloud ECS via a free tier. Deploy the pack, with migrations running automatically on container startup.

Challenges we ran into

Fail-open vs. fail-closed defaults. Several of our own default a hardcoded seed admin API key, an unauthenticated metrics endpoint, a migration step that silently no-op'd on a fresh volume—looked dev but would have quietly failed open in production. We spent real effort, auditing, and closing exactly these gaps (permission checks every route, a startup validator that refuses to boot with the default admin credentials outside development, migrations wired into the (container entrypoint) rather than leaving them as roadmap items.
Kernel-level enforcement is unforgiving. Getting the BPF-LSM failsafe correct (device/inode encoding, WSL2 LSM quirks) took far more iteration than the application-layer code, because bugs there fail Silently, at a layer normal application tests can't see.
Keeping the agent honest about what it can't do yet. It's temporary. to describe the system in more autonomous, more "SOC platform" terms than what's actually implemented today. We chose to scope this submission to what's real and running: one agent, one proxy, one approval gate, one kernel-level backstop—not a multi-agent security operations center.

What we learned

Human-in-the-loop is a design constraint, not a bolt-on approval state has to be a first-class, persistent, replay-safe object from day one It becomes the weakest link instead of the safety mechanism. We also learned that the most valuable "AI safety" work on this project wasn the agent's prompting—it was in closing fail-open defaults in the proxy underneath it.