People new to ChangeGuard sometimes assume “connecting” means “installing an agent”, and that installing an agent is what lets ChangeGuard act. Neither is true. There are three planes, and they are deliberately different things.
Fleet by default
Connect AWS once, discover your EKS clusters, authorize the ones ChangeGuard may observe. From then on ChangeGuard collects Kubernetes API state centrally, with short-lived credentials, and a broken or unreachable cluster never stops collection from the healthy ones. Removing the grant you created revokes ChangeGuard within about a minute. See Connected Environments and Connect your EKS fleet.
Edge when the evidence has to stay local
Some evidence only exists on the node. Runtime threat signals and node-level benchmarks need presence; some clusters can’t be reached from outside. For those, install the Edge collector — a small, non-root, read-only component — and add it to the same environment card. Fleet + Edge on one cluster is one environment: one identity, one judgment, one execution location. Edge supplies evidence. It never acts, and nothing about installing it changes what ChangeGuard may do. Install steps: Install ChangeGuard Edge.
The Executor acts — only with a Permit
Whether you choose the Cloud Executor or a Local Executor, the model is the same: a separate identity from reading, scoped to the namespaces you chose, verified by Verify execution access, and inert until a Permit for exactly one change is consumed. The Cloud Executor is preferred wherever the environment is safely reachable — nothing to install, nothing in your cluster holding a credential, and every action attributable in your own CloudTrail and EKS audit logs. The Local Executor exists for topologies or policies that require local presence.
Edge ≠ Executor. Edge ≠ permission to act. A reachable EKS cluster needs nothing installed to be judged or to be acted on under a Permit. If you only ever install Edge, ChangeGuard can see more; it cannot do more.
Which do I need?
