Architecture & data flow

ChangeGuard AI acquires environment evidence two ways, and both feed the same control plane and the same decision plane:

• ChangeGuard Fleet (default). The Fleet service connects centrally to your Kubernetes API over customer-authorized, read-only access — for EKS, with short-lived AWS and Kubernetes credentials minted per collection cycle. Nothing is installed in the cluster for standard Kubernetes API-state evidence. See Connect your EKS fleet.
• ChangeGuard Edge (optional). A small, read-only in-cluster footprint for evidence that requires local presence — runtime signals (Falco), node benchmarks (kube-bench) — or for environments Fleet cannot reach centrally.

The rest of this page describes the Edge in-cluster half and the control plane, and where your data lives. Fleet collects the same Kubernetes API state with a smaller grant (get/list only, no watch, no Secret access) and the same boundary guarantees — your source code, Secret values, and workload data stay in your cluster either way.

​

Edge deployment topology

The operator runs in changeguard-system and manages the collector (and optional scanners) in changeguard-agent through a CRD. Only the collector talks to the outside world.

​

Communication paths

For evidence, exactly three network relationships exist, and all cluster-originated traffic is outbound HTTPS on 443. Execution, when you enable it, adds a fourth: the Executor’s authenticated calls to your Kubernetes API, described in The execution path.

​

What leaves your cluster — and what never does

This is the boundary that matters most for review. The collector sends the metadata needed to correlate and score change; it does not send your code, images, or secret values.

​

Where the AI runs

All correlation, scoring, and AI reasoning run in the control plane — not in your cluster. AI analysis is powered by Amazon Bedrock (Claude models). The in-cluster collector does no analysis; it reads state and pushes it out. This keeps the cluster footprint tiny (one small collector pod with no persistent storage) and means model/analysis changes ship on the control-plane side without touching your cluster.

​

The execution path

Evidence is read-only by construction. Execution — applying an approved fix — is a separate path with a separate identity, enabled per environment and inert until a Permit exists.

• The Cloud Executor runs in ChangeGuard’s estate. For each environment you enable, it assumes a role in your AWS account — ChangeGuardExecutor-<environment-instance>, with no AWS permissions and a trust policy admitting only ChangeGuard’s Cloud Executor with your external ID — and authenticates to exactly that cluster through an EKS access entry you created, as a Kubernetes group that holds get, list and patch on workloads in the namespaces you chose. Nothing is installed.
• The Local Executor is the same component running inside your cluster, for topologies or policies that require local presence, under a per-environment ServiceAccount with the same narrow grant.
• Either Executor acts only on a Permit — signed in AWS KMS, bound to one action, one target, one environment, one approval or policy and a window of minutes, used once — and ChangeGuard verifies the outcome from fresh evidence afterwards. VERIFIED is never assumed.

Nothing about Fleet or Edge grants write access, and the Executor’s identity cannot read Secrets, exec into pods, delete or create resources, or change RBAC. See Cloud Executor, Local Executor and Execution authority and least privilege.

​

Where data lives

​

Cluster footprint at a glance

For the exact RBAC grants behind this, see Permissions & RBAC.