One layer of judgment and control over every production change.
ChangeGuard AI judges a change against the environment it will actually enter — SHIP, HOLD or BLOCK. Authorized changes get a short-lived Permit. An Executor carries out only the permitted action. The outcome is observed and verified. Kubernetes on AWS EKS today.
Judge → Govern → Permit → Execute → Verify
Judgment, Permit, Executor, Observation
A decision, an authorization, an action and a proof are four different things. ChangeGuard never lets one stand in for another.
What ChangeGuard believes
SHIP, HOLD or BLOCK for this change against this environment right now, with the reasons and the evidence it had and did not have. Judgment alone authorizes nothing.
What is authorized
A short-lived, signed, single-use authorization bound to this action, this target, this environment, this approval or policy, and this time window.
What acts
The Cloud Executor or a Local Executor verifies the Permit, consumes it once, and applies exactly the signed action with the least privilege you granted.
What proves what happened
Fresh evidence from the environment, attributed to the change by identity. VERIFIED is a conclusion from observation, never an assumption.
SHIP / HOLD / BLOCK, against the real environment
Judge a change by hand in Preflight, on every pull request through the GitHub integration, or from any pipeline or agent with one call. The verdict carries plain-terms reasons, the deterministic CSC score, and an explicit list of the evidence it had and did not have — absent evidence is never counted as safe.
- Live environment state: what is running, what it can afford, whether the change is even feasible against quotas and limits
- Artifact evidence when you supply a digest; honest “not available” when you don’t
- Verdicts are append-only and kept with the outcome on one permanent change record
- Engineering Advisor — the one or two things a senior engineer would raise — Early Access
Advise or Auto, per environment — and a Permit for every action
Authority is a per-environment decision, never account-wide. Advise is the default: a signed-in person approves each change, and that approval becomes the Permit. Auto produces a Permit only inside an explicit policy — namespaces, fix types, a confidence floor, an hourly cap — and falls back to Advise outside it. There is no third mode.
- Every authorization becomes a ChangeGuard Permit: signed with a key held in AWS KMS, bound to the exact action hash, expiring in minutes, used once
- Revocable until the moment it is consumed; a changed proposal, a changed policy or a withdrawn approval revokes it automatically
- Auto never authorizes under an empty or default policy — it fails closed
Two Executors, one Permit model
Both verify the same signed Permit, consume it exactly once with ChangeGuard before touching anything, record the pre-state, apply one patch, and report the result under the Permit’s identity.
Cloud Executor · preferred
Runs in ChangeGuard’s estate. For each Permit it assumes an execution role in your account that carries no AWS service permissions — only a trust policy naming ChangeGuard with your external ID; its Kubernetes authority is scoped separately through an EKS access entry and namespaced RBAC — mints a 60-second token bound to exactly this cluster, and patches only the workloads in the namespaces you chose. Nothing to install. Edge is never required.
Local Executor
Installed in your cluster from the environment’s Execution section when your topology or policy requires local presence. Same Permit, same single-use consumption, same least privilege: its own service account with a namespaced get/list/patch grant — never the Edge collector’s identity.
Verify execution access proves the path before it is used: the Executor assumes its role, authenticates to exactly this cluster, holds get, list and patch in your namespaces — and is denied delete, create, exec, secrets, impersonation, RBAC writes and cluster-admin. It verifies a signed probe Permit without reading or changing any workload.
Observed outcomes, verification, history
After a change executes, ChangeGuard records what actually happened against the change that caused it. Incidents are attributed to the exact change. Fixes are verified against fresh evidence, and a fix that fails verification is handed to a human — failure escalates, it never loops.
- Outcome attached by the verdict and Permit it named, never by recency
- VERIFIED only from an independent observation showing the permitted state, healthy
- Permanent, shareable change records; append-only audit trail with the approver, the policy version and the Permit on every action
- Measured outcomes: predicted versus observed, joined by change identity
Evidence and action are separate planes
Fleet is the centralized evidence plane: connect your AWS account once, discover EKS clusters, authorize read-only access per cluster. Edge is an optional local-evidence extension for signals that must stay on the node. The Executor is the governed action plane. None of them grants another’s authority.
AWS Account Center
Which AWS accounts ChangeGuard is connected to and whether each connection is healthy enough to discover and read your environments. Verify, discover, repair, reauthorize — without ever widening authority.
Connected Environments
Every environment ChangeGuard can see: what supplies its evidence (Fleet, Edge, or both), whether a judgment would be fully informed, its execution readiness, its latest Permit, and its Advise/Auto mode.
ChangeGuard Edge
A small read-only collector for evidence that needs local presence — runtime signals, node benchmarks — or clusters that can’t be reached centrally. Optional. Never required for judgment or execution.
Clearly labeled, so what you evaluate is what you can turn on
Engineering Advisor & reasoning
The read a senior engineer would add to a verdict — led by what is true in the environment right now, challengeable, silent when nothing is material. Opinion, experience and reasoning capabilities ship behind flags, on request. The Advisor →
Realms, SSO, self-hosted inference
Realms — a tenant split into production and test with separate authority — is on the roadmap, not built. SSO/SAML and in-VPC inference for judgment and reasoning (NVIDIA NIM) are planned. None of these ships today.
Governed autonomous change
The same judgment, Permit and verification applied wherever a production change originates — beyond Kubernetes, and for every actor that can act on infrastructure. Direction, earned domain by domain on evidence.
ChangeGuard does not learn from every change today. The outcome record is instrumented so that future prediction can be measured against it; no model, threshold or policy is modified by an outcome. Future capability is labeled as future.
See it decide, then prove it on your environment.
Watch the live demo, judge a change for free in Preflight, or work with us as a design partner on one real EKS environment.