Skip to main content
ChangeGuard AI is the decision and control layer for infrastructure change. Before a change executes, it judges the proposed change against the environment it will actually enter and answers SHIP, HOLD or BLOCK, with the reasons. When a change is authorized — by a person, or by a policy you wrote — that authority becomes a short-lived ChangeGuard Permit. An Executor carries out only the permitted action. Then ChangeGuard observes what actually happened, attributes it to the change, and verifies the outcome against fresh evidence.
In short: Judgment → Permit → Execution → Outcome. Infrastructure is now changed by humans, CI/CD, automation and AI agents, and every change arrives with a green build. Existing authorization answers “can this actor make the change?” ChangeGuard answers “should this exact change happen in this exact environment right now?” — and then “did reality match the judgment?” AI can make the change. ChangeGuard decides whether it should.

​
Four things, kept apart on purpose

Autonomous-capable by design. Human-controlled by default. Every environment starts in Advise: ChangeGuard can diagnose, prepare and execute, but a human authorization must exist before anything executes. Auto is opt-in and acts only inside an explicit policy; outside it, Auto falls back to Advise. See Advise and Auto.

​
Where it runs today

Kubernetes on AWS EKS is the current wedge. Fleet reads your environments centrally with read-only access you authorize — nothing to install. Edge is an optional in-cluster collector for evidence that must stay local; it is never required for judgment or execution. The Executor is the governed action plane. See Fleet, Edge and the Executor.

​
Start here

The first-use path takes you from a blank account to a verdict on your own pull requests without learning the architecture first — nothing to install for your first verdict, nothing to paste for GitHub.

1. What ChangeGuard AI does

The vocabulary, the lifecycle, and what is free.

2. Run your first Preflight

A real verdict in about two minutes, with nothing connected.

3. Understand SHIP / HOLD / BLOCK

What each verdict means and what earns it.

4. Connect an environment

Live context for every judgment — read-only.

5. Connect GitHub

A verdict on every pull request. No API key, nothing to paste.

6 – 8. Judge, observe, keep the record

A real change judged, its outcome recorded, one permanent address.

9 – 10. Execution and authority

Optional: enable the Executor; choose Advise or Auto per environment.

Watch the live demo

The same path, recorded live against a real environment.

​
How we label claims

Every capability in these docs is one of: Nothing emerging is documented as if it ships today. See Core concepts and Known limitations and roadmap.
Who these docs are for. Anyone deciding whether a change should happen — developers, on-call engineers, platform teams, security reviewers — and the operators who connect environments and enable execution. Evaluating ChangeGuard AI for your organization? Start at changeguard.ai, or become a design partner.