Project 02 / 07 / shipped

Warden

Guards changes to live software and cannot be talked round by a tricked AI assistant.

From the write-up

Warden is an automated security guard for changes to live software. It approves boring ones, blocks dangerous ones, asks a human only when unsure, keeps an unerasable log, and cannot be talked into a bad decision by an AI assistant that was tricked. An AI agent does the legwork on each change request, but it never holds the power to approve anything alone. Every credential it gets names one customer and one request, its tools arrive only when a step needs them, rules on the server make each decision, and the log shows any later edit.

Headline numbers / 2

Attackers tried 84 ways to trick the AI into approving a bad change. None got through.: 0 of 84none got through; From the Warden README, prompt-injection red-team table, row Hardened, MCP over HTTP.
With the safety layers switched off, 35 of the same 84 attacks got through. That is what the layers are worth.: 35 of 84what layers are worth; From the Warden README, prompt-injection red-team table, row Boundary layers off.

Decisions I made and things that broke

Each credential names one customer and one request, so the assistant cannot reach anyone else. Taking those as checked inputs instead let 50 of 56 scripted tries through.
The risk score is plain code. A language model only writes the explanation, and only after the decision is saved.
A small local model steering the assistant never finished a task properly, 0 of 80 times, so that test needs a stronger model.

What this proves / 8 skills

AI / ML

Python: The agent, the server it calls and the risk scoring are written in Python. The results tables are rebuilt from saved files.
LangGraph: A LangGraph agent gathers the facts on each change, but it never has the power to approve anything alone.
Model Context Protocol: The agent reaches its tools through a Model Context Protocol server. Over that link, none of 84 attacks got through.
Tool-using agents: Tools arrive only when a step needs them, and the power to write arrives only after the risk is scored.

Systems

TLA+ and z3: The approval rules live in one versioned file. A solver checks each new version against the last one before it counts.

Web / backend

PostgreSQL: The same defences held against a real login server and Postgres database. None of 84 attacks got through there either.
OAuth and scoped credentials: Each credential is short-lived and names one customer and one request. Seven ways of forging one got zero calls served.

Infrastructure

Tests and CI: A test fails if any results table in the write-up drifts from the saved result files.

The demo, recorded

Warden demo: a safe change approved, an attack refused, and a tampered log entry caught — Four buttons replay recorded runs: a safe change, a dangerous change, an attack picked from the test corpus, and an edit to an old log entry that the page catches in your browser.

Papers / 3

arXiv 2609.14780, The Stochastic DeputyCustomer and request are fixed inside each signed credential instead of being passed in, the pattern the paper showed failing.
arXiv 2609.26900, AjarIts measure, how many writes a credential could still make after the task, is how the tests count what an attacker could reach.
arXiv 2609.22712, Trustworthy agentic AIIts list of ways agents fail is how the threat model is grouped, with each failure matched to the control that handles it.