Overview
ChangeGuard AI is designed with a zero-trust, least-privilege architecture built on one rule: reading never implies writing. Evidence reaches it two ways, both read-only; acting on an environment is a third, separately identified path that exists only where you enable it and only under a short-lived Permit — see Execution and the Permit below. Evidence:- ChangeGuard Fleet (default). The Fleet service reads your Kubernetes API centrally over access you authorize. Every AWS session is minted per operation via STS AssumeRole with a ChangeGuard-issued external ID and expires in 15 minutes; Kubernetes authentication uses a short-lived bearer minted per collection cycle and held only in memory. The Kubernetes grant is explicit and read-only —
get/listonly, nowatch, no writes, no wildcards, and no Secret access is requested. Removing the access entry or role binding you created revokes ChangeGuard AI within about a minute. Nothing runs in your cluster. - ChangeGuard Edge (optional). For node-local evidence, a read-only collector runs inside your cluster and pushes encrypted metadata outbound. Evidence collection never opens an inbound path into your infrastructure. The next sections describe the Edge data path and the shared control-plane protections; Execution and the Permit covers the one path that can act.
Architecture
The Edge evidence path, outbound-only by design: a read-only collector and the optional scanners in your cluster push findings out over TLS 1.2+ to the ChangeGuard AI platform on AWS. Evidence collection opens no inbound connection to your infrastructure.
Data Flow
The Edge collector connects outbound only — telemetry is encrypted in transit (TLS 1.2+) and at rest (AES-256), with no inbound path into your cluster for evidence.
- Collector → Backend: TLS 1.2+ enforced in the collector’s HTTP transport configuration. It will not downgrade to plain HTTP.
- ALB: AWS-managed TLS certificate via ACM. HTTP requests on port 80 receive a 301 redirect to HTTPS.
- Backend → Database: PostgreSQL connections use
sslmode=require. All queries are encrypted in transit. - Database at rest: AES-256 encryption via AWS-managed keys on the RDS instance.
Network Requirements
The Edge collector needs outbound HTTPS access to a single endpoint:Execution and the Permit
Acting on an environment is the only path that is not read-only, and it is governed end to end:- Human-controlled by default. Every environment starts in Advise: a signed-in operator must approve each change. Auto is opt-in and bounded by an explicit per-environment policy; outside the policy it falls back to Advise.
- A separate, environment-scoped identity. The Cloud Executor assumes a role in your account —
ChangeGuardExecutor-<environment-instance>— that carries no AWS permissions, admits only ChangeGuard’s Cloud Executor with a ChangeGuard-issued external ID, and is assumed for 15 minutes with the Permit id as the session name. An EKS access entry maps it to a per-environment Kubernetes group that holds onlyget/list/patchon workloads in the namespaces you chose. No long-lived AWS access keys exist anywhere in the model. - No cluster-admin, no Secrets. The Executor cannot delete, create, exec, read Secrets, write RBAC, impersonate or use wildcards — and Verify execution access proves those denials before the path is usable.
- KMS-backed Permit signing, single use. Authority reaches the Executor only as a Permit signed by a key in AWS KMS, bound to one action, one target, one environment, one approval or policy and a window of minutes, consumed exactly once before any write.
- Observation required for VERIFIED. An applied action is never called successful until fresh evidence from the environment shows the permitted state, healthy.
Infrastructure
Multi-Tenant Isolation
ChangeGuard AI enforces tenant isolation in two independent layers: Application layer. Every API request is scoped to a tenant through the authenticated API key or session token. The backend validates tenant ownership at the middleware layer — before any handler logic runs — on every data path: clusters, snapshots, score history, ArgoCD instances, audit logs, notifications, policies, suppressions, integration configs, API keys, and team members. Database layer. Tenant boundaries are also enforced inside PostgreSQL itself. Every tenant table carries a row-level isolation policy that is evaluated by the database independently of the application. This means a hypothetical bug in application code that forgot to filter by tenant would silently return zero rows — not leak data — because the database refuses the operation rather than trusting the application to do it right. The application’s database role does not have the privilege to bypass these policies, and the audit log is append-only at the grant level: the backend can write new entries but cannot modify or delete existing ones. Forensic integrity does not depend on application correctness.Tenants cannot access, query, or infer the existence of other tenants’ data. There is no shared namespace or cross-tenant aggregation. Cross-tenant operations (used internally for billing, support, and account provisioning) are routed through a separate code path that is reviewed independently and is not reachable through the public API.
SSRF Protection
All outbound webhook URLs (Slack, Teams, notification channels) are validated before the backend makes any HTTP request:- Must use HTTPS (HTTP rejected)
- Private IP ranges blocked (10.x, 172.16-31.x, 192.168.x)
- Loopback and link-local addresses blocked (127.x, 169.254.x, localhost)
- Cloud metadata endpoints blocked (169.254.169.254, metadata.google)