Skip to main content

​
Overview

ChangeGuard AI is designed with a zero-trust, least-privilege architecture, and evidence reaches it two ways:
  • 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/list only, no watch, 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 agent runs inside your cluster and pushes encrypted metadata outbound. There is never any inbound access to your infrastructure. The rest of this page describes the Edge data path and the shared control-plane protections.

​
Architecture

ChangeGuard AI security architecture: a read-only, non-root agent and the KubeBench, Grype, Falco, Pluto, and Syft scanners in your Kubernetes cluster connect outbound over TLS to AWS WAF, load balancing, the backend on Amazon EKS, Amazon RDS (AES-256 at rest), and Amazon Bedrock for AI analysis.

Outbound-only by design: a read-only agent and the five scanners in your cluster push findings out over TLS 1.2+ to the ChangeGuard AI platform on AWS. No inbound connection is ever opened to your infrastructure.

​
Data Flow

ChangeGuard AI data flow: the in-cluster agent pushes snapshots outbound over HTTPS (TLS 1.2+, gzip, API key) through AWS WAF and the load balancer to the backend on Amazon EKS, which writes to Amazon RDS PostgreSQL with sslmode=require and AES-256 encryption at rest.

The agent connects outbound only — telemetry is encrypted in transit (TLS 1.2+) and at rest (AES-256), with no inbound path into your cluster.

Every component in this chain enforces encryption:
  • Agent → Backend: TLS 1.2+ enforced in the agent’s HTTP transport configuration. The agent 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 agent needs outbound HTTPS access to a single endpoint:
No inbound connectivity is required. No LoadBalancer, Ingress, or NodePort is created. The agent is compatible with private clusters, air-gapped environments with egress proxies, and clusters behind corporate firewalls — as long as outbound HTTPS to our API is permitted.

​
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)
This prevents malicious webhook configurations from being used to probe internal networks.