Skip to main content
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.
There is no inbound path into your cluster. The control plane never connects to you — the collector always initiates the connection out.

​
Communication paths

Exactly three network relationships exist, and all cluster-originated traffic is outbound HTTPS on 443.
There is no HTTP-proxy support today. The collector’s push client does not honor HTTP_PROXY / HTTPS_PROXY. The cluster needs direct outbound HTTPS to api.changeguard.ai:443. For air-gapped image pulls you can point global.imageRegistry at your own mirror, but the egress requirement stands.

​
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.
Optional code graph. If you enable the code-graph feature, ChangeGuard AI reads your repositories in-cluster and ships only the derived knowledge graph — never your raw source. Your source code still does not leave the cluster.
Data the control plane stores is tenant-isolated at the database level using PostgreSQL row-level security, so one tenant’s data is never visible to another.

​
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 deterministic CSC Score and the AI reasoning capabilities are distinct. Scoring is deterministic and generally available; the reasoning layers (Engineering Advisor, Engineering Opinion, and related) are Early Access and off by default. See Product concepts.

​
Where data lives

​
Cluster footprint at a glance

Tiny

One lightweight pod (~13MB image; observed ~9m CPU / 21Mi memory on a small cluster). Current defaults (chart ≥ 5.3.6): requests 25m/64Mi, limits 500m/512Mi — overridable via agent.collector.resources. No PersistentVolumeClaims.

Non-root

The collector runs non-root. Optional security scanners differ — the Falco DaemonSet runs privileged; see Permissions.

Read-only

get / list / watch only — no writes to your workloads unless you opt into remediation.
For the exact RBAC grants behind this, see Permissions & RBAC.