Provable policy enforcement for coding agents

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

Warden runs your coding agent inside a policy engine. Every action is checked against your rules by the ZSGuard engine before it runs - a verdict in microseconds, so it can't go rogue however the model is talked around. And it holds the agent to the spec you set: your assumptions enforced, with a proof of what each run actually verified.

For developers running agents on code they can't afford to break - client work, production repos, regulated stacks.

Free to run - no credit card, no per-seat pricing. A free developer preview you install on your own machine. Apple Silicon Mac (M1 or later).

Policy-governed by default

Write your guardrails once in plain YAML. Warden enforces them on every tool call your agent makes, across every project.

Verified in microseconds

Decisions come from the ZSGuard engine, not an LLM guessing whether an LLM is safe. Deterministic, auditable, and fast enough to sit in the hot path.

Blocks what hurts

Leaked secrets, git push --force, rm -rf, and destructive commands are stopped with a proof of exactly which rule fired.

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.

Your subscriptions, via their CLI

Sign in once in each tool's own CLI; Warden drives it over ACP. No API keys, no metered billing.

Claude ChatGPT / Codex Cursor Gemini (Antigravity) GitHub Copilot Devin Kimi

Cloud & open-source APIs

Bring your own keys for hosted frontier and open-weight models.

Amazon Bedrock Azure OpenAI GLM Qwen DeepSeek OpenRouter

Local models

Run open-weight models on your own hardware. Nothing leaves your machine.

Ollama llama.cpp LM Studio Fully offline

Multiple accounts per provider - switch in one click

Keep a work and a personal OpenAI signed in at the same time, a separate Claude account for each client, and flip between them without ever signing out. Warden keeps every account and every model one click away.

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.

Warden - project workspace

Agent

You  Add rate limiting to the login endpoint.

Agent  Edited auth/login.ts, added a limiter, and ran the tests. 14 passed.

✓ Verified by Warden  no blocked actions

Files changed

auth/login.ts
  export async function login(req) {
+  await limiter.check(req.ip)
    const user = await verify(req)
-  return sign(user)
+  return sign(user, { ttl: '15m' })
  }

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.

Pull request #134 - review4 comments · on gpt-5.6-luna
agents/execution/run_worker.py
  509    if run.parent_run_id:
+ 511    parent = await repo.get(run.parent_run_id)
AI REVIEW · line 511 No auth or scope check before copying a parent run's report into this prompt. If parent_run_id crosses a tenant, this leaks prior-run data. Validate the owner and company scope, or query with those predicates. Edit · Remove · or add your own on any line
Then publish as you: Comment Approve Request changes

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.

Assurance - rate-limit the login endpointreached L2 of 4
L0 Built L1 Proven by a test L2 Non-trivially tested L3 Lightweight formal L4 Proof
2 tests fail before the change, pass after it VERIFIED
Reviewed by a different model than wrote the code INDEPENDENT
No property tests - unusual inputs remain unproven NOT VERIFIED

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.

policy.yamleveryday guardrails
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
Redis: allow reads, protect productioncomplex rule
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] }
What the agent hits at runtimeverified in microseconds
redis-cli -h cache-staging GET session:42 ALLOWED
redis-cli -h prod-orders FLUSHALLblocked by rule: production cache is read-only BLOCKED

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.

One rule: never touch .env secretsblock: { touches: dotenv }
cat .envBLOCKED
sudo cat .envwrapped in sudo - unwrapped and checkedBLOCKED
sh -c 'cat .env'nested shell - recursed intoBLOCKED
cat ./config/../.envpath detour - resolved to the same fileBLOCKED
eval "$(printf 'cat .env')"can't be proven statically - held, never silently allowedHELD

Choose how strict to be

Three postures - set per project.

Pick a posture for each project: how much Warden blocks or pauses out of the box. Loosen a weekend side project, tighten a client's repo - same agent, different rules, chosen by which project you are in.

Open

The agent runs freely. Only the always-on basics stay enforced - like keeping file access inside the project.

default: allow

Guarded

Recommended

Blocks the dangerous few - secrets, force-pushes, destructive commands - and pauses for approval on risky ones. The agent works freely otherwise.

default: allow · block risky

Hardened

Maximum enforcement: the widest set of protections set to block, the rest to ask. Still a deny-list - a command you haven't named will run.

default: allow · block most

All three are deny-lists - by design

Anything you don't explicitly block runs, Hardened included. Pick a posture, then add the rules you need. ZSGuard's core engine defaults the other way - deny-all - for the production, unattended deployments where nothing should run unless it is named.

Per-project controlone setting per project
weekend-side-projectOpen
client-web-appGuarded
production-paymentsHardened

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.

automated.yamlapplies only to unattended runs
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

Every run is a restore point

Warden snapshots your working tree before each run - stored as lightweight git objects, never committed. If a change isn't what you wanted, put your files back in one click. A restore saves your current state first, so it's always undoable.

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.

Workflow: pre-pr-checksruns top to bottom, gated
1.  skill: run-test-suiteSkill
2.  skill: check-migrationsSkill
3.  ruff check --fixCommand
4.  workflow: open-pull-requestSub-flow
Three ways to run itchat · button · automatic
Type /pre-pr-checks in chat, or press Run in the project - each step streams its result.
Or bind it to run automatically after the agent edits files - your per-project gate before anything ships.

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.

Your memoryprivate, on this machine
Always use pnpm, never npm Run the tests before saying it's done Keep commit messages to one line Explain trade-offs before a big refactor
Shared, in the repocommitted for the team
# 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.

Starter packsone click to enable
Secrets & destructive-command shield enabled
Block force-push to main enabled
Production database protection
No outbound network to unknown domains
HIPAA / SOC 2 / PCI / GDPR compliance
Author with AIplain English in, tested policy out
"Let the agent read from Redis anywhere, but never touch the production cache."
rules:
  - allow: redis-cli
  - block: redis-cli
    when: { flag.h: "prod-*" }
    unless: { subcommand: [GET, MGET, SCAN] }
✓ Verified - 2 example checks passed before you save

Get Warden for macOS (Apple Silicon)

Tell us who you are and we'll email you a signed license and the download link. Your license key is delivered by email only - it is never shown on this page - so please use a valid email you can access. Requires an Apple Silicon Mac (M1 or later).

Requesting a license and downloading Warden constitutes acceptance of the Terms & Disclaimer below. Free while in preview. No credit card. Your license key is sent only to this email address - it is not displayed here - so make sure it's one you can receive mail at.

Check your email for your license

We sent your Warden license and install steps to your inbox. Download the app below to get started.

  1. Download and open Warden.dmg, then drag Warden to Applications.
  2. Open Warden.
  3. Go to Policies and paste your license key when prompted.

Terms & Disclaimer

Warden is a free developer preview, provided "as is" and "as available", without warranty of any kind, whether express or implied, including but not limited to merchantability, fitness for a particular purpose, and non-infringement. You use it entirely at your own risk.

Warden runs and governs coding-agent actions on your own machine. While it is designed to block dangerous operations, no software is perfect. You remain solely responsible for reviewing what the agent does, for keeping your own backups, and for the systems, data, and credentials the agent can reach.

To the maximum extent permitted by law, Pluto Coach Ltd and its officers, directors, and employees accept no responsibility or liability for any direct, indirect, incidental, or consequential loss or damage - including lost data, lost revenue, downtime, or security incidents - arising from your use of, or inability to use, Warden. Because Warden is provided free of charge, no refund or other remedy is offered.

By submitting your email, requesting a license, or downloading and using Warden, you confirm that you have read, understood, and agree to these terms.