How it works

A change is proposed. Everything after that is governed.

ChangeGuard AI judges the change against the environment it will actually enter, turns an approval or a policy into a short-lived Permit, lets an Executor carry out only the permitted action, and verifies what happened against fresh evidence. Your pipeline still deploys the way it always has; every production change now has a decision, an authority and a proof.

Proposed change → Actual environment → Judgment → Authorization → Permit → Execution → Observed outcome → History

The lifecycle

Propose → Judge → Authorize → Permit → Execute → Observe → Verify

Eleven steps, four roles. Every step is recorded against the change, so the record can always explain itself.

  1. 1 · ProposeA change arrives from a pull request, a pipeline, an agent or a person. Its proposer is recorded from the session, never self-declared.
  2. 2 · IdentifyThe target environment is resolved to one canonical identity — the same cluster reported by Fleet and Edge is one environment, not two.
  3. 3 · UnderstandWhat is running there now, what the environment can afford, what the change actually alters — the manifest, the artifact, the diff.
  4. 4 · JudgeSHIP, HOLD or BLOCK with the reasons, and an explicit list of the evidence used and the evidence missing. Judgment authorizes nothing.
  5. 5 · AuthorizeA signed-in operator approves (Advise), or an explicit environment policy allows it (Auto). The authorization binds the exact action hash.
  6. 6 · PermitChangeGuard issues a Permit: signed in AWS KMS, bound to the action, target, environment, executor and authority, expiring in minutes.
  7. 7 · ExecuteThe Executor verifies the Permit offline, consumes it online exactly once, records the pre-state, and applies one patch — nothing else.
  8. 8 · ObserveFresh evidence arrives from the environment: the workload as it actually is after the action.
  9. 9 · AttributeThe observation is attached to the change by the Permit and attempt it names — never by whatever happened most recently.
  10. 10 · VerifyVERIFIED only when an independent observation shows the permitted state, healthy. No report in time means failed and escalated, never assumed.
  11. 11 · RespondA verified fix closes the loop. A failed one is handed to a human; compensation needs its own authority and its own Permit.
  12. RecordVerdict, authority, Permit, attempt, outcome: one permanent, append-only change record with a shareable address.
The judgment

What SHIP, HOLD and BLOCK mean

Three answers, each with its reasons. A verdict is a judgment, not an enforcement: in your pipeline you decide whether a BLOCK fails the job (the shipped GitHub Action does by default). Execution that ChangeGuard itself performs is a separate authority, and it happens only with a Permit.

SHIP

ChangeGuard sees no reason to hold this change. The evidence it had supports it, and the reasons say which evidence that was.

HOLD

Review first. Something is worth a look — often evidence ChangeGuard did not have, which it names. An artifact that has not been independently evaluated is HOLD, never SHIP.

BLOCK

ChangeGuard advises against this change. Judged against live state it would fail or break something — exceed a quota, request more than its limits allow, contradict what is actually running.

A real BLOCK — the reason, in numbers
A change record with verdict BLOCK: scaling the storefront to 8 replicas would exceed the namespace memory quota — used 256Mi plus a proposed delta of 768Mi exceeds the hard limit of 512Mi.
From a real pull request against a live environment. Valid manifest; wrong in context. Only a judgment against live state catches it.
Watch: three real verdicts on a live environment (3:01)
Recorded on Northwind, our live test environment on Amazon EKS: a release held for missing evidence, a scale-up blocked over the namespace memory quota, a health-check change that ships and then fails in production, and the incident tied back to the change that caused it.
Three planes

Fleet reads. Edge extends. The Executor acts.

Evidence and action are separate authorities with separate identities. Reading never implies writing, and nothing executes without a Permit.

Fleet — centralized evidence

Connect AWS once, discover your EKS clusters, authorize read-only access per cluster. Short-lived sessions, minted per collection cycle. Nothing installed. Live

Edge — optional local evidence

A small read-only collector for signals that need presence on the node, or clusters that can’t be reached centrally. It supplies evidence only — it never acts, and it is never required for execution or autonomy. Supported

Executor — governed action

Cloud Executor — central execution where the environment is safely reachable; preferred, nothing installed. Local Executor — inside your cluster where topology or policy requires it. Both: a separate identity from reading, scoped to your namespaces, inert without a live Permit. Live-proven

Authority

How a decision becomes an action — without becoming standing access

  • Advise (default). No approval, no authorization, no Permit. Only a signed-in operator can approve a cluster write; API keys cannot.
  • Auto (opt-in, per environment). A Permit is issued only under an explicit, non-empty policy with an id and a version. Outside the policy the change waits for a human. A policy edit bumps the version and revokes Permits issued under the old one.
  • Bound, not broad. The authorization records the canonical hash of the exact action. If the proposal changes afterwards, authority is withdrawn and a new approval is required — a Permit for A can never execute B.
  • Consume is the commit point. Before any AWS or Kubernetes call, the Executor consumes the Permit with ChangeGuard, atomically and exactly once. Revocation wins any race up to that moment.
  • Expiry and revocation are facts, not hopes. Permits expire in minutes; a lapsed, revoked or already-used Permit is refused at consume even though its signature still verifies offline.
Execution states, as the product shows them
  • Authorized
  • Permit issued
  • Execution started
  • Action applied
  • Verifying
  • Verified

“Applying” is set by the consume, never by the Executor’s say-so. An attempt with no report in 15 minutes is recorded as unreported and the change fails to a human. VERIFIED needs a fresh observation of the same environment, at least 90 seconds after the action, showing the permitted state and healthy pods.

Remediations — the ladder on a real record
A verified remediation showing the state ladder from authorized by policy through Permit issued, execution started, action applied and verifying to verified.
Watch: an approved fix runs under a single-use Permit (3:17)
Judgment says what ChangeGuard AI believes. A Permit defines exactly what is authorized: this action, this workload, this environment, this approver, a few minutes, used once. The Executor carries out only the permitted action, and VERIFIED comes from fresh evidence observed in the environment, not from the Executor’s word.
Boundaries

What leaves your environment — and what never does

Never leaves

  • Your source code
  • The values of your secrets — the Executor is denied reading them at all; evidence carries Secret names, types and key counts, never values
  • Standing write authority — the execution role carries no AWS service permissions; Kubernetes write access exists only in the namespaces you grant, and is used only with a live Permit

Sent to ChangeGuard AI

  • Environment state (workloads, events, posture)
  • Change metadata and diffs from your pull requests and pipelines
  • Findings you choose to ingest (vulnerability, benchmark, runtime signals)
With Fleet, ChangeGuard connects to your Kubernetes API endpoint over credentials minted per operation; the cluster needs no outbound path for standard evidence. The optional Edge collector makes one direct HTTPS connection to api.changeguard.ai:443. Every action the Cloud Executor takes is attributable in your own logs: the Permit id is the AWS session name in CloudTrail and in your EKS audit log, and every write carries the field manager changeguard-executor. The full trust model is on Security & trust and in the documentation.

See the whole loop on a live environment.

The live demo shows a change judged, blocked, shipped, observed and fixed. A design partnership runs the same loop on your own EKS environment.

Become a design partner▸ Watch the live demoRead the docs