GitHub

Open source · Apache-2.0 · pre-release

Let AI agents change real systems, safely.

Changeward sits between your agents and your databases, clusters and infrastructure. Every change an agent wants to make is previewed exactly, checked against your policy, applied by Changeward, and kept undoable.

Get started View on GitHub

Works with Claude Code, Codex, OpenCode, Gemini CLI, Cursor, any MCP client, GitHub Actions and GitLab CI.

changeward · an agent session5 applied1 held1 denied
stagingALTER TABLE invoices DROP COLUMN legacy_ref
prodDELETE FROM sessions WHERE user_id = user_id
planDELETE FROM sessions WHERE user_id = user_id48,210 rows: every row in public.sessions · dry run, rolled back
policyprod denied: production writes need an incident reference and a second approver
resultnothing ran · the dry run was rolled back

Low risk: through in milliseconds. Risky: a person decides. Dangerous: stopped before it runs.

The problem

Agents can write the change. Nobody sees its effect until it runs.

Coding agents now run psql, kubectl and terraform with your credentials. In a chat window, a dangerous command looks just like a safe one, because you are shown the command, not what it will do.

What the agent shows you

agent

Stale sessions are slowing down login. I'll clean them up:

DELETE FROM sessions WHERE user_id = user_id;
Allow this command?YesNo

Looks routine. You've approved forty of these today.

What Changeward shows you

#1 DELETE public.sessions48,210 rows: the whole table
iduser_idlast_used
9f1c42026-10-24 09:12
a2e7172026-10-24 09:40
b6d042026-10-24 10:03
c311882026-10-24 11:27
d9a4232026-10-24 12:55
e05b172026-10-24 13:18
… 48,204 more
user_id = user_id is true for every rowapproval required

The effect is obvious, and policy stops it before anything runs.

More commands that look fine in chat

Looks fine in chat

DELETE FROM sessions WHERE user_id = user_id

What it actually does

A typo that compares a column with itself. It is true for every row, so every session is deleted.

Looks fine in chat

ALTER TABLE events ALTER COLUMN id TYPE bigint

What it actually does

Rewrites the whole table under an exclusive lock. On a big table, writes stop until it finishes.

Looks fine in chat

kubectl apply -f deploy/

What it actually does

Overwrites the fix someone applied by hand during last night's incident, or fights Argo CD for the object.

Looks fine in chat

terraform apply

What it actually does

“1 to replace” is an aws_db_instance. Replacing a database means destroying it first.

Option 1: approve every command

The agent stops and asks before each command. After the fortieth prompt, people click "yes" without reading the SQL. And reading SQL does not tell you how many rows it touches anyway.

Option 2: let it run

Skip permissions and hope. When something goes wrong, you find out afterwards, if you look, and "undo" means restoring a backup.

What's missing: a change-control layer

Show the exact effect before anything runs, let policy decide by risk and environment, apply only what was approved, and keep every change undoable. That is what Changeward does.

July 2025

During an explicit code freeze, an AI coding agent ran destructive commands against a production database. It deleted records for 1,206 executives and 1,196 companies, and then misreported what had happened.

With Changeward, that DELETE is planned in a transaction that is always rolled back. You see the exact rows, policy denies it in production, and the audit log records what really happened. Run the replay demo

How it works

Plan first. Then policy. Then apply, verify, and keep the undo.

The agent keeps doing the work. Changeward becomes the only way its changes reach your systems.

How changes flow through ChangewardCoding agents, pull requests and your own agents send proposed changes to Changeward. Changeward plans each change, applies policy, applies and verifies it, and records how to undo it, before it reaches Postgres, MySQL, Kubernetes, Terraform, proxies or REST APIs. Direct writes from agents with raw credentials are blocked.direct writes with raw credentials: blockedClaude Code · Codexcoding agentsCursor · OpenCode · Geminiany MCP clientPull requestGitHub Actions · GitLab CIYour own agentPython · TypeScript SDKAGENTS & PIPELINESPostgres · MySQLrows, schemaKubernetesArgo CD · FluxTerraformOpenTofuProxies · REST APIsNGINX · GitHubYOUR SYSTEMSChangewardPlanPolicyApply · verifyUndo logholds the credentials
← scroll the diagram →
  1. 1

    Propose

    The agent calls propose_change with the SQL, manifest or plan, plus its intent. It never gets your credentials.

  2. 2

    Plan

    Changeward dry-runs it for real (a rolled-back transaction, a server-side dry run, a Terraform plan) and records the exact effects.

  3. 3

    Decide

    Policy routes on environment, reversibility and blast radius: auto-approve, ask you, ask someone else, or deny.

  4. 4

    Apply & verify

    Changeward applies exactly the approved plan, then checks that only the planned rows or objects moved.

  5. 5

    Undo

    Every change keeps a tested undo path. Undo one step, the whole session, or let policy require a checkpoint first.

Try it

Same change, different environment, different decision

Pick what the agent wants to do and where. Changeward plans it, policy decides with the built-in defaults, and anything applied can be undone.

1. The agent wants to…
2. …on a database classed as
DELETE FROM sessions WHERE user_id = user_id
  1. 1Propose
  2. 2Plan
  3. 3Policy
  4. 4Apply
  5. 5Verify

Plan · dry run, always rolled back

  • 48,210 rows: every row in public.sessions
  • the WHERE clause matches everything
  • before-images kept for undo

reversibledestructive48,210 rows

Policy · staging

approval required out of band, from a second person

Applied · verified

Only the planned rows moved. The undo path is recorded on the session timeline.

See the effect, not the command

The exact effect, before anything runs

Changeward plans every change against the real system and shows what will actually happen: rows, locks, table rewrites, objects created, changed or destroyed.

Every row that changes, with before and after values. In production, values are hidden and keys hashed.

Postgres · direct change
$ changeward exec --intent "archive customers inactive for two years" \
    "UPDATE customers SET status = 'archived' WHERE last_seen < DATE '2024-10-19'"
plan p_805e48ce4b33 · shop (personal) · reversible · 99 rows · live-dry-run
#1 UPDATE public.customers — 99 rows
   ~ id=102  status: "active" → "archived"
   ~ id=103  status: "active" → "archived"
   …
change c_0abd3564f023 (#2) — verified · 99 rows · UPDATE 99

Undo

Every step on the timeline can be taken back

Agents work in sessions. Each change records exactly how to reverse it: row images, soft-dropped tables, previous manifests, the last-applied config.

changeward logsession s_30f9a360ec02 · agent=claude-code · env=personal
  1. #1ALTER TABLE customers ADD COLUMN status textschema · reversible · verified
  2. #2UPDATE customers SET status = 'archived' WHERE …99 rows · reversible · verified
  3. #3DELETE FROM customers WHERE status = 'archived' AND …89 rows · reversible · verified

Click undo on step 2.

  • Dependency-aware. Undoing a step first undoes the later steps that touched the same objects.
  • Guarded. A row is restored only if it still matches what the change left behind. If someone edited it since, undo stops with a conflict instead of overwriting their work.
  • Whole sessions. changeward rewind undoes everything the agent did, newest first.
  • Honest about limits. Changes that need a full copy to undo are checkpoint-only, and policy can require a checkpoint first.

Before and after

What changes when Changeward is in the loop

CredentialsWithout Changeward: The agent runs psql, kubectl or terraform with your credentials.With Changeward: The agent calls propose_change. Changeward holds the credentials and applies only what was approved.
VisibilityWithout Changeward: You see what happened afterwards, if you look.With Changeward: You see the exact effect first: rows and before/after values, locks, rewrites, objects created, changed or destroyed.
UndoWithout Changeward: “Undo” means restoring a backup.With Changeward: Every change has a tested undo path. Undo refuses if someone changed the data since, instead of overwriting their work.
ApprovalWithout Changeward: All or nothing: ask for every command, or for none.With Changeward: Routed by risk and environment. Reversible dev changes are auto-approved; production needs an incident reference and a second person.
MigrationsWithout Changeward: Reviewed by reading SQL.With Changeward: Rehearsed on a throwaway copy, with an effect report and a merge gate on the PR.
AuditWithout Changeward: Scattered shell history.With Changeward: Every session, plan, decision, approval and undo in a hash-chained log, exportable to OpenTelemetry.

Policy

Fast where it's safe. Strict where it matters.

Each connection is bound to an environment class that the agent can never change. Sensible defaults come built in; write your own rules in CEL for anything else.

  1. personal

    Reversible changes are auto-approved. Anything else asks you in the agent's UI.

  2. shared-dev

    Auto-approved if reversible, non-destructive and under 1,000 rows; otherwise you confirm.

  3. staging

    Auto-approved if reversible, non-destructive and under 10,000 rows; otherwise a second person approves.

  4. prod

    Needs an incident or ticket reference, plus approval from someone other than the proposer.

  5. prod-restricted

    Read-only for agents acting directly.

changeward.policy.yaml
rules:
  - name: prod-destructive-needs-dba
    when: change.env == "prod" && change.destructive
    decide: require
    channel: out-of-band
    approvers: ["group:dba", "group:sre"]
    quorum: 2

  - name: release-freeze
    when: change.env == "prod" && calendar.freeze("q4-release")
    decide: deny
  • Approvals bind to the plan hash. If the data or the change moves after approval, it is planned again.
  • Separation of duties. Out-of-band approvals come from someone other than the proposer. Agents can't approve.
  • Fail closed. A rule that errors counts as "require approval". Gateways deny when Changeward is unreachable.
  • Dry runs never leak. Statements with effects outside the transaction (dblink, DO blocks) are never run while planning.

Two lanes, one engine

For agents acting live, and for changes going through Git

The same planner, policy and audit log cover both. Most teams use both.

Direct lane

Agents acting on live systems

Coding agents and your own agents call Changeward through its MCP server, hooks, SDKs or an MCP gateway. Each write becomes plan → decision → apply → verify, on a session timeline you can undo step by step.

$ changeward log
SESSION s_30f9a360ec02  agent=claude-code
  #1  ALTER TABLE customers ADD COL...  verified
  #2  UPDATE customers SET status ... verified
$ changeward rewind --yes

CI lane

Changes going through pull requests

Migrations, Kubernetes manifests and Terraform plans in a PR are rehearsed or dry-run. The report is posted on the PR or MR, and policy gates the merge or the deploy.

# .github/workflows/changeward.yml
- uses: srawlin/changeward/integrations/github-action@main
  with:
    mode: gate
    synthetic-rows: 1000

changeward promote --pr turns what an agent did directly in dev into migration files and a pull request, so Git stays the source of truth.

Integrations

Plugs into the agents and pipelines you already use

One command sets up a coding agent: changeward install claude-code adds the MCP server and a hook that blocks direct writes and points the agent to Changeward's tools. Claude Code, Codex, OpenCode and Gemini CLI were tested end to end with each real CLI.

Coding agents

Your own agents

CI/CD and GitOps

Systems

Gateways

Measured, not promised

Unsafe actions that landed with no human decision

Agent unsafe-action benchmark v0: 20 scripted scenarios on Postgres 18, including actions induced by prompt injection. Each runs once with raw credentials and once through Changeward.

Raw credentials100% (14/14)
Changeward, built-in policy14% (2/14)
Changeward + intent signals0% (0/14)
Safe actions blocked
0 of 6
Median plan latency
32 ms
Median time to undo
16 ms

The two misses with built-in policy are small, reversible updates whose effect doesn't match what was asked for (one came from an injected ticket). Optional intent signals catch both and route them to a person; signals can only tighten a decision, never loosen it. Risky actions auto-applied in a personal environment count as safe only when undo restored the database byte for byte. v0 is scripted; v1 will drive real agents. Methodology and full results

Who it's for

Built for the people who get paged when it goes wrong

Platform, DevOps and SRE teams

Your developers already point agents at psql and kubectl. Give them a paved road instead of a ban: one policy, one audit log, and a shared executor that holds the credentials so they never reach a laptop.

Shared executor

Developers using coding agents

Let Claude Code or Codex move fast on your dev database without babysitting every command. Read the session timeline afterwards and undo any step, or the whole session, in one command.

Getting started

Teams building agents into products

Your support or ops agent needs to write to real systems. The Python and TypeScript SDKs give it plans, approvals and undo, with policy you control rather than a prompt.

SDKs

Security and compliance

Separation of duties, approvals bound to the exact plan, production values redacted from plans, and a hash-chained audit log you can export to OpenTelemetry.

Concepts

Quick start

Running in five minutes

  1. 1

    Install

    Pre-release: build from source (Go 1.27+ and a C compiler). Homebrew, npx and uvx packages come with the first release.

    git clone https://github.com/srawlin/changeward && cd changeward
make build && export PATH="$PWD/bin:$PATH"
  2. 2

    Connect a database

    Its environment class decides the default policy.

    changeward connect app --dsn 'postgres://localhost/myapp_dev' --env personal
  3. 3

    Plug it into your agent

    Adds the MCP server and a hook that blocks direct writes.

    changeward install claude-code   # or codex, opencode, gemini, cursor
  4. 4

    Ask for a change, then look

    The session timeline, step-by-step undo, and a local web view.

    changeward log
changeward undo 2 --yes
changeward ui

Full walkthrough with a sample database

FAQ

Questions people ask first

Is this a sandbox?
No. Changeward is a control plane for changes to real systems. In a coding agent, a hook blocks direct writes and steers the agent to Changeward's tools. For a hard boundary, run the shared executor: it holds the credentials, so an agent that gets around a hook still has nothing to make a change with.
Does it replace backups?
No. Undo covers the changes Changeward applied: row images, soft-dropped tables, previous manifests and the last-applied configuration. Changes that can only be undone from a full copy are classed checkpoint-only, and policy can require a checkpoint first. Keep your backups.
What about changes that can't be undone?
Each plan gets a reversibility class before anything runs: reversible, compensatable, checkpoint-only or irreversible. Policy sees it, so "irreversible in production" can be denied or sent to a DBA.
Does production data end up in the model's context?
In production, plans hide row values and hash keys. CI rehearsals run on synthetic rows generated from types and constraints, never sampled from production.
Does the agent slow down?
Barely. In the benchmark, the median plan took 32 ms on Postgres and the median undo 16 ms. Reversible changes in dev are auto-approved, so the agent doesn't wait on you.
Do I need an account or a hosted service?
No. Changeward is a single open-source binary (Apache-2.0) that runs on your machine, or next to your systems as a shared executor (Helm chart or systemd). Your credentials stay with you.
What's the status?
Pre-release. Postgres, MySQL, Kubernetes, Terraform, proxy configs and REST APIs work today, as do the coding-agent integrations and the GitHub and GitLab CI integrations, all tested end to end. Packages arrive with the first tagged release.

Give your agents real access, without giving up control.

Open source, self-hosted, and running in five minutes.

Get started Star on GitHub