Skip to main content
This page states ChangeGuard AI’s cluster permissions plainly, including the parts security teams most want to scrutinize. Nothing here is softened.
Fleet’s grant is smaller. This page describes the optional ChangeGuard Edge in-cluster footprint. The default path — Connect your EKS fleet — grants the customer-authorized Fleet identity get/list only: no watch, no write verbs, no wildcards, and no Secret access is requested at all. The Secrets caveat below applies only to an Edge install.

​
The short version (Edge)

  • ChangeGuard AI does not request cluster-admin.
  • ChangeGuard AI does not use wildcard (*) RBAC rules.
  • The operator and collector read cluster resources. To correlate changes and score posture, that read is cluster-wide and includes Secrets and RBAC objects (read-only).
  • ChangeGuard AI’s evidence identities write nothing to your workloads. Writes happen only through a separately enabled Executor identity — per environment, in the namespaces you grant, and only with a consumed Permit. See Execution permissions below.
Read this carefully: because the collector reads Secrets cluster-wide, it can see the values of your Kubernetes Secrets. It is designed not to transmit secret values off-cluster (see what leaves your cluster), but the in-cluster read grant is real. If your security posture forbids any component reading all Secrets, raise this with your team before installing.

​
What the collector reads

The collector needs a fleet-wide picture of state and change. Its ClusterRole grants read verbs only (get, list, watch) across the resources it correlates:
“Read verbs only” means get / list / watch. The collector’s ClusterRole contains no create, update, patch, or delete on your workloads.

​
What the operator does

The operator manages ChangeGuard AI’s own components (the collector and optional scanners) through the changeguardagents.changeguard.ai CRD. Its write access is scoped to ChangeGuard AI’s own resources — it does not get write access to your applications.

​
What ChangeGuard AI cannot do (by default)

No workload writes

It cannot create, patch, or delete your Deployments, Pods, or configs.

No secret exfiltration

Secret values are not transmitted to the control plane.

No inbound path for evidence

The collector initiates all communication outbound over HTTPS, and Fleet reads over access you authorized. Only the Executor — when you enable it — calls your Kubernetes API, and only with a Permit.

No cluster-admin

No wildcard rules, no cluster-admin binding.

​
Security scanners (optional, on by default)

The default install (agent.security.enabled=true) runs a suite of security scanners. Most run as scheduled Jobs, but one runs continuously and with elevated privilege — your security review should account for it: Falco requires kernel-level access because eBPF syscall monitoring inherently does — the same privilege model Falco uses upstream. It is called out here so it is never a surprise in a security review. If your posture does not allow a privileged DaemonSet, disable it without affecting the collector or the other scanners:

​
Execution permissions (opt-in, per environment)

If — and only if — you enable execution for an environment, ChangeGuard AI gets a separate identity to act with. It is never the collector’s or Fleet’s identity, and it is deliberately narrow:
  • Cloud Executor (preferred, nothing to install). An IAM role in your account, ChangeGuardExecutor-<environment-instance>, with no AWS permissions and a trust policy admitting only ChangeGuard’s Cloud Executor with your external ID; one EKS access entry mapping it to the Kubernetes group changeguard:executor:<environment-instance>; a ClusterRole changeguard-executor-<environment-instance> that only defines get, list and patch on Deployments, StatefulSets and DaemonSets; and a RoleBinding of the same name in each namespace you chose.
  • Local Executor (where topology or policy requires it). The same verbs, through a per-environment ServiceAccount changeguard-local-executor-<environment-instance>, bound only in the namespaces you chose.
  • Neither grants delete, create, update, pods/exec, Secrets, RBAC writes, impersonation, node access, wildcards or cluster-admin — and Verify execution access proves each of those denials before the environment is execution-ready, and again every 12 hours.
  • Holding the identity is still not authority: nothing is written without a consumed, single-use Permit for exactly one approved change.
Enabling execution approves nothing. In Advise (the default) a signed-in operator approves each change; in Auto an explicit policy does, inside its bounds. Until you apply the generated grant, neither mode has anything to act with. See Execution authority and least privilege.

​
Inspect what’s actually granted

Don’t take this page’s word for it — read the live grants in your own cluster:
Confirm the ClusterRole verbs are limited to get, list, watch, and that no rule uses * for resources or verbs on your workloads.

​
Revoke access

To remove all of ChangeGuard AI’s in-cluster permissions, uninstall it — the ClusterRoles, bindings, and ServiceAccounts are removed with the release:
To revoke only execution while keeping visibility, delete the Executor’s RoleBindings, the EKS access entry or the execution role (Cloud Executor), or the Local Executor’s manifest — or disable execution for the environment in ChangeGuard AI. Evidence is unaffected either way.
Revoking API-key access on the control-plane side is handled in-app under API keys. See the Operations handbook for key rotation guidance and its current limitations.