What does ChangeGuard AI do?

ChangeGuard AI is the decision and control layer for infrastructure change. Before a change executes, it evaluates the proposed change against the actual target environment and returns SHIP, HOLD or BLOCK with the reasons. When a change is authorized, that authority is bound to a short-lived ChangeGuard Permit; an Executor carries out only the permitted action, and ChangeGuard observes what happened and verifies the outcome.

What is a ChangeGuard Permit?

A ChangeGuard Permit is a short-lived, machine-verifiable authorization bound to one action, one target, one environment, one approval or policy, and one time window. It is signed by ChangeGuard, used once, revocable, and expires in minutes. Nothing ChangeGuard governs executes without one.

Does ChangeGuard AI act on its own?

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

Does ChangeGuard AI block deploys?

A verdict is a judgment, not an enforcement. In your pipeline you choose whether a BLOCK fails the job (the shipped GitHub Action does by default). Execution that ChangeGuard itself performs is a separate authority: it happens only with a valid Permit.

The decision and control layer for infrastructure change

Know whether a production change should happen before it executes.

ChangeGuard AI judges a proposed change against the actual target environment — SHIP, HOLD or BLOCK. Execution needs a short-lived Permit. The outcome is verified.

AI can make the change. ChangeGuard decides whether it should.

Become a design partner ▸ Watch the live demo

Kubernetes on AWS EKS · connects read-only · nothing executes without a Permit

ChangeGuard AI Preflight: a proposed change to roll the storefront to the next release, judged against the northwind-prod environment. Verdict HOLD, with plain-English reasons, the CSC score, and an evidence panel listing what was and was not available. — Real product output. The verdict names the evidence it had — and the evidence it didn’t.

Live-proven end to end

The complete control loop runs in production.

Judgment → Permit → Execution → Verified outcome

Exercised end to end against the live production system — and pinned by security tests that block every build.

18 / 18Latest live acceptance

A complete customer workflow exercised against the live production system.

Single-useEvery Permit

Signed, short-lived, revocable. Consumed exactly once.

Least privilegeNo cluster-admin or Secrets

Get, list and patch in the namespaces you chose. Nothing else.

Design partnersNow opening production evaluations

A small number of teams on AWS EKS, with the founder directly involved.

How it works

Judgment → Permit → Execution → Outcome

The same treatment for every change, whether it comes from a person, a pipeline or an AI agent.

1 · Proposed change

Something wants to change production

A pull request, a pipeline, an agent or a person.

2 · Environment

The place it will actually land

What is running, what it can afford, how healthy it is right now.

3 · Judgment

SHIP / HOLD / BLOCK

With the reasons, and the evidence it had and didn’t. Judgment authorizes nothing.

4 · Permit

Authority, bound and signed

An approval or a policy becomes a Permit for exactly this action.

5 · Execute

Only the permitted action

The Executor verifies the Permit, consumes it once, applies the change.

6 · Verified

Did reality match?

Fresh observed evidence, attributed to the change. Never an assumption.

The real product

Four screens, one controlled change

Every frame is the product against a live environment.

A change the environment can’t afford — BLOCK

A valid manifest that would exceed the namespace’s memory quota. The record says so in numbers.

A change record with verdict BLOCK: scaling the storefront to 8 replicas is Kubernetes-infeasible against the namespace quota — requests.memory used 256Mi plus a proposed delta of 768Mi exceeds the hard limit of 512Mi.

Authority becomes a Permit — and the Executor acts only with it

Authorized by policy, Permit issued, action applied, verified against fresh evidence. The Permit is consumed exactly once.

A verified remediation: patch Deployment permit-demo. The state ladder reads Authorized by policy, Permit issued, Execution started, Action applied, Verifying, Verified; authorized by an Auto policy at version 6, Permit consumed, proposed by changeguard-agent and approved by agent-policy.

The Executor proves what it can do — and what it cannot

Before an environment is execution-ready, every verb the Executor must never hold is checked and denied.

Verify execution access results: No excess authority passed, checked by the executor — cluster-admin wildcard denied, delete Deployments denied, create Deployments denied, exec into pods denied, read Secrets denied, list Secrets denied, create RoleBindings denied, impersonate users denied, patch nodes denied. Namespace scope passed: write access stops at the chosen namespaces. Permit verification passed.

What actually happened — on the same record

The outcome is attached to the change by the verdict it named, never by whatever happened most recently.

A change record showing the judgment before execution (SHIP) and what actually happened afterwards: deployed successfully, attributed to this change by the verdict it named, not by recency.

ChangeGuard Permit

Judgment says what should happen.
A Permit says what may.

A Permit is a short-lived, machine-verifiable authorization bound to exactly one change. It is how a decision becomes authority without becoming standing access.

changeguard permitsigned · single-use

This action: one patch to one workload, hashed and signed
This target: Deployment northwind/storefront
This environment: the cluster’s identity, signed in
This authority: a named approver, or a policy id and version
This time: minutes, then it expires

Rendered from the Permit model. Real Permits are compact signed tokens.

Signed, short-lived, single-use and revocable. A Permit for A cannot authorize B.

Advise by default: a signed-in person approves each change. Auto acts only inside a policy you set.

Autonomous-capable by design. Human-controlled by default.

See how Permit works →

Observe & verify

Nothing is “done” until reality says so.

After a change executes, ChangeGuard observes the environment and verifies the outcome against fresh evidence.

Attributed by identity

An outcome is attached to the change by the verdict and Permit it named — never by recency.

VERIFIED needs evidence

No fresh observation showing the permitted state, healthy — no VERIFIED.

Failure escalates, never loops

A fix that fails verification is handed to a human.

A change record showing verdict SHIP and, under what actually happened, an incident after deploy attributed to exactly this change.

Why different

Four questions. Only two of them have had an owner.

Validation asks

“Is this configuration valid?”

Authorization asks

“Can this actor make the change?”

ChangeGuard asks

“Should this exact change happen in this exact environment right now?”

And then

“Did reality match the judgment?”

Permissions say who may. ChangeGuard decides whether this change should — and governs the authority to carry it out.

Prove it on one real environment with us.

A small number of design partners on Kubernetes / AWS EKS: judgment on your changes, governed execution in the namespaces you choose, a measured outcome record — with the founder directly involved.

Become a design partner ▸ Watch the live demo Talk to the founder