The coding agent that does what you asked - and nothing you didn't.

One agent, every model

Bring every subscription and key you already pay for.

Warden is model-agnostic. Sign in with the AI subscriptions you already have, plug in cloud and open-source APIs, or run models fully offline on your own machine - and switch between any of them mid-conversation. No lock-in, no second set of bills.

Built for people who check the work

An agent and a code editor, in one window.

Warden is not a black box that runs off and merges on your behalf. The coding agent and a full file editor sit side by side, so you see every change, read every diff, and decide what ships. Enforcement on the machine's side, your judgment on yours. Enforcement, not vibes.

The Software Factory

Run your whole delivery line through Warden - idea to production.

Ideas come in from wherever your team keeps them - Linear, Jira, GitHub issues, an error tracker, or a skill that reads your bugs channel. An agent triages each one against the codebase, you decide, and Warden carries it through a plan or spec, a build in its own worktree, a review against the original ask, the merge, then staging and production. Every stage is read from git, pull requests and deployments, so nothing says “Done” that isn't.

# warden-lifecycle.yaml
rules:
  - ask: { tool: Factory }   # a person merges migrations
    when: { factory_transition: merge,
            factory_migrations_touched: "true" }

Review, not just write

It reviews the pull request. You decide what stands.

Point Warden at a pull request and it reviews the diff like a principal engineer - on a model you pick, guided by a review style you set per project. The findings come back as line-anchored comments right on the diff, not a wall of chat. Edit them, delete them, add your own, then post to GitHub as yourself - a comment, an approval, or a request for changes - or hand the whole review back to the agent to make the fixes.

Confidence, not claims

Every run tells you what it proved - and what it didn't.

“Done” from an agent usually just means it stopped. Warden grades each run on a confidence ladder built from checks that actually ran - it typechecks, lints and tests, then verifies the tests aren't vacuous - and shows the evidence next to an equally prominent list of what is not verified. The review is run by a different model than the one that wrote the code, so it's a second opinion, not a self-assessment.

Your rules, in plain YAML

Say exactly what the agent may and may not do.

Policies are short, readable, and as fine-grained as you need. Allow a tool everywhere but carve out the one thing that must never happen - like touching a production instance - and Warden enforces it on every command, returning a proof of exactly which rule fired.

default: allow
rules:
  - block: "git push --force"
  - block: { touches: dotenv }   # never read or write .env secrets
  - block: rm
    when: { path: "*/prod/*" }
  - ask: aws
    when: { flag.profile: prod }  # pause for human approval

default: allow
rules:
  # Redis is fine on dev and staging caches
  - allow: redis-cli

  # ...but the production cache is off-limits,
  # except read-only inspection.
  - block: redis-cli
    when:   { flag.h: "prod-*" }
    unless: { subcommand: [GET, MGET, SCAN] }

Start each project from a posture - loosen a weekend side project, tighten a client's repo - then add your own rules.

All three are deny-lists: anything you don't block runs. ZSGuard's core engine defaults the other way, deny-all, for production deployments where nothing should run unless it is named.

It can't be talked around

A blocked command stays blocked - however it's disguised.

Guardrails that match on text lose the instant an agent chains, wraps, or path-qualifies a command - or just obfuscates it. Warden decomposes every command to its real effect and checks each piece against your rules. And when a command can't be proven safe ahead of time - a dynamic eval, a piped subshell - it doesn't guess. It fails closed: ask, or block. Prove it, or refuse it.

Runs you can leave alone

Let it run unattended - with tighter rules for when you're not watching.

Some work should run without you at the keyboard - an overnight refactor, a scheduled cleanup, a batch of fixes. Warden gives an automated run its own, stricter set of permissions, separate from interactive work, so “fine while I'm watching” and “fine on its own” are not the same thing. When an unattended run hits something outside its rules, it stops and holds for you instead of guessing.

context: automated            # these rules apply when no human is watching
default: allow
rules:
  - block: "git push"          # never publish from an unattended run
  - block: { touches: dotenv }
  - on-block: hold            # stop and wait for a human, don't improvise

Do it once, replay it forever

Chain your skills and checks into one repeatable workflow.

The multi-step things you do again and again - a pre-PR gate, cutting a release, onboarding a new service - become an ordered chain of your own skills and shell commands. Build it by picking steps, run it from chat with a slash command, or bind it to run automatically after the agent edits files. Deterministic, versioned, and stored with the repo - every step still checked by policy, so a repeatable workflow is a governed one.

It remembers how you work

Personal memory - private to you, never in the repo.

Shared conventions belong in your repo's AGENTS.md, where the whole team gets them. But how you like to work shouldn't be committed for everyone. Warden captures your preferences as personal memory - kept on your machine, global or per-project - and loads them into context so you stop repeating yourself. Everything it remembers is in one place, for you to read and edit.

# AGENTS.md - versioned with your code
- Build: just build
- Migrations: never edit applied ones
- API errors: return typed Result, never throw

You never start from a blank page

Turn one on, or just describe it.

Enable a ready-made pack in one click, or write a rule in plain English and let Warden generate and test the policy for you - so guardrails take seconds, not an afternoon of hand-written YAML.

rules:
  - allow: redis-cli
  - block: redis-cli
    when: { flag.h: "prod-*" }
    unless: { subcommand: [GET, MGET, SCAN] }

Pricing & licensing

Free for you. Licensed for your company.

Warden is free for personal use. If you use it on commercial work - for an employer, a client, or your own business - you need a Team license.

Not sure which you need? If Warden touches code someone pays for, it's commercial. Ask us - we're happy to help.