Warden

Companies are about to run fleets of AI agents with real access. Warden governs what they do: it checks every action against the rules, records it, and revokes an agent's access when it breaks one.

Comment

Inspiration

Companies are about to run fleets of AI agents. Not one assistant, but dozens or hundreds, each with real credentials and the ability to act. The tooling for that world does not exist yet, and it shows. In the past year 88% of organizations reported an AI agent security incident, and only about 14% say their agents reached production with full security sign-off (State of AI Agent Security 2026). Gartner expects governance problems to push 40% of enterprises to pull back or shut down autonomous agents by 2027.

The failures are already public. Replit's agent deleted a production database during a code freeze. An agent at Amazon inherited elevated permissions and took a service down. A single GitHub issue hijacked an agent inside Google's own ADK repository and reached a service-account credential. The pattern never changes: the agent is not evil, it has real access, nothing is watching what it does with it, and nothing can stop it in time. Model Armor guards what an agent says. Nothing guards what a fleet of agents does. That is the layer we built.

What it does

Warden is a control plane for a fleet of AI agents. Every agent streams what it does as OpenTelemetry spans to Warden through Pub/Sub, and Warden checks each action against that agent's mandate: the tools it may use, the ones it may never use, and limits written in plain English. Exact limits are decided in code; the softer ones go to Gemini, which points to the rule that was broken.

The difference from a dashboard is that Warden acts. Before a dangerous tool runs, the agent has to ask first, so a bad action is stopped before it happens, not logged after. Break a hard rule and Warden does not send an alert, it quarantines the agent and disables its IAM service account, so its next call is a real 403 from Google Cloud. Every decision goes into a per-agent hash chain sealed to a retention-locked bucket, so the record cannot be changed later, not even by Warden.

Warden also builds the agents it supervises. You describe an agent in plain words, and the factory has Gemini design it, Cloud Build deploy it under its own identity, and simulation approve it before it goes live. Governance is wired in from the agent's first request, not bolted on after. It is built as one system on the Google Cloud agent stack: OpenTelemetry for what agents do, a service account per agent for identity and revocation, versioned mandates as the registry, and inline pre-approval as the gateway. Two fleets run under it today: cloud operations on a real sandbox Google Cloud project, and payments on a Stripe test account.

How we built it

Every agent, including Warden's own incident agent, is an ADK agent, and the whole system runs on Google Cloud.

  • Gemini 3.5 Flash (Vertex AI): judges every action, designs new agents, runs the simulations, and powers Warden's own reasoning.
  • Google Agent Development Kit (google-adk): the framework for every agent in the fleet and for Warden itself.
  • google-agents-cli: the factory's build lifecycle, scaffold to eval to deploy, driven inside Cloud Build.
  • Cloud Run: hosts Warden and every agent, each under its own service account.
  • Pub/Sub: carries the OpenTelemetry spans from every agent to Warden.
  • Firestore: holds the mandates, verdicts, hash chains and incidents.
  • Cloud Storage: holds the retention-locked ledger anchors and the factory's build artifacts.
  • Cloud Build: builds and deploys each new agent.
  • IAM: the enforcement lever, where Warden disables a breaching agent's service account.
  • Cloud Scheduler: runs the recurring fleet tasks, routed through Warden with OIDC.
  • Secret Manager: stores the operator key and the Stripe test key.

The console is React and Vite, served by Warden. The payments fleet runs on Stripe in test mode.

Challenges we ran into

Getting from flagging a problem to actually removing the access was the hard part. It needed a service account per agent, a guard in every agent that fails safe, and handling the minute or so it takes IAM to switch a login off and back on. Judging actions rather than requests was another lesson: a healthy agent that refuses a bad request should not create an incident, so the real breach needs an agent whose own rules have been stripped out. And a hash chain that Warden both writes and checks is not tamper-proof on its own, so we anchor it to a bucket with a retention lock.

What we learned

The framework is the easy part. The rules, the tools, and the ability to revoke access are the product. A verdict is only as good as the rule it is judged against, which is why the factory writes the rules first and makes every agent state concrete limits. And a real 403 convinces people in a way a red banner never will.

What's next

The bet is that every company running agents will need this.

Next: calibrate the judge against human-labelled evidence, tier the supervision so a fleet of thousands does not need a model call on every action, broaden the connector catalog, support per-tenant fleets, and graduate the memory and registry onto Vertex AI Agent Engine. The goal is a control plane you can point at any fleet of agents and trust.

Built With

  • cloud-build
  • cloud-run
  • cloud-scheduler
  • cloud-storage
  • fastapi
  • firestore
  • gemini-3.5-flash
  • google-adk
  • google-agents-cli
  • iam
  • opentelemetry
  • pub-sub
  • python
  • react
  • secret-manager
  • stripe
  • typescript
  • vertex-ai
  • vite
Share this project:

Updates

Submission history