AI Agent Security Framework on GKE: Implementation Guide

Your platform team spent a week configuring the Agent Sandbox CRD on a gVisor-enabled node pool — the architecture Google positions as the recommended pattern for AI agent workloads on GKE. Workload Identity Federation with KSA principals is bound to every agent pod. Container Threat Detection is licensed and active in Security Command Center Premium. And the runtime behavioral sensor you budgeted for won’t install. Enabling GKE Sandbox on those nodes disabled CTD per Google’s own documentation, and on the Autopilot clusters, the privileged DaemonSet the sensor requires is admitted only when a matching WorkloadAllowlist is installed — which your security team didn’t know existed. Two detection products, one configured with a compatibility constraint and the other gated behind an allowlist mechanism. One cluster-creation decision with consequences across every pillar of your security program.

The four-pillar Observe → Posture → Detect → Enforce framework from the parent guide on AI agent security for cloud environments is cloud-agnostic. The wiring on GKE is not. Unlike AWS — where cluster mode, DaemonSet support, and detection product are independent choices, covered in the EKS implementation guide — GKE presents three architectural decisions that have to be made before any pillar gets configured. Each one reshapes which primitives are available for every phase of the program. This article is the wiring manual for teams that have already made those decisions, and the decision matrix for teams who haven’t.

The Three Architectural Decisions That Shape Your GKE AI Agent Program

On EKS, the cluster mode, the runtime detection product, and the isolation technology are largely orthogonal choices: Fargate constrains DaemonSet deployment per-workload, GuardDuty EKS Runtime Monitoring is an add-on enabled independently, and neither choice disables the other. On AKS, the primary implementation challenge is organizational — separately-licensed Defender plans owned by separately-funded teams, with the handoffs between them being where programs stall. GCP has the most sophisticated AI-agent-specific primitives of the three clouds, and that sophistication comes with mutually exclusive architectural choices. These choices compose rather than combine. Three decisions, each forcing pillar-level trade-offs:

Decision 1: GKE Autopilot vs. GKE Standard

Autopilot enables Workload Identity Federation on every node by default, runs managed gVisor, and eliminates the Compute Engine default service account fallback that turns one misconfigured Standard node pool into project-wide Editor access. It also enforces a default set of constraints that reject privileged workloads — the deployment pattern eBPF-based runtime sensors require. As of GKE 1.35, eligible customers can admit privileged workloads on Autopilot by installing a WorkloadAllowlist CRD, either from an approved Autopilot partner or authored by the customer. This unblocks third-party eBPF sensors — ARMO has published its Autopilot support via this mechanism — but it adds operational overhead: allowlist installation, GKE Warden admission-webhook troubleshooting, and ongoing maintenance as partner allowlists update. Standard clusters give you complete control over node images, DaemonSet scheduling, and runtime class selection without the allowlist layer, at the cost of having to configure Workload Identity, hardening, and node pool policies explicitly rather than inheriting them. The Observe pillar’s kernel-level telemetry is reachable on both cluster modes — but the operational path to get there is materially different, and the decision has to be made at cluster creation.

Decision 2: Agent Sandbox CRD + managed gVisor vs. Container Threat Detection

The Agent Sandbox CRD is Google’s AI-agent-specific primitive — a Kubernetes API for managing isolated, stateful, single-container environments designed for running LLM-generated code, with warm pools and snapshot-based lifecycle management. On GKE, it integrates with managed gVisor by default for kernel-level isolation (Kata Containers is also supported as an alternative backend). Two constraints have to be priced in together. First, per Google’s own documentation, Container Threat Detection is incompatible with GKE Sandbox and must be disabled on affected node pools. Teams following the Google codelab for deploying secure AI agents on GKE enable GKE Sandbox as a step in the tutorial — and their Security Command Center posture dashboard continues showing CTD as enabled org-wide, while it is silently inactive on the exact node pool where the AI agent runs. Second, GKE requires that at least one node pool in the cluster has GKE Sandbox disabled, which means production architectures that want Sandbox for all AI agent workloads still maintain a non-sandboxed pool for system workloads — and that pool becomes the one place where CTD remains active. The Enforce pillar’s isolation layer and the Detect pillar’s signature-matching primitive cannot coexist on the same nodes.

Decision 3: Self-hosted on GKE vs. Vertex AI Agent Builder

Vertex AI Agent Builder abstracts the underlying compute — no cluster to operate, no node pools to secure, no sensors to deploy. The Observe pillar shifts from kernel-level telemetry to API-level Cloud Audit Logs for the aiplatform surface. Behavioral baselines at the syscall layer are not available because the syscall layer is not exposed. Enforcement operates within whatever boundaries Agent Builder’s runtime exposes, not within boundaries you define. This is a program-scoping decision rather than a per-cluster one: the framework methodology still applies on Agent Builder, but the wiring is qualitatively different and the Detect and Enforce pillars rest on substantially fewer primitives.

The rest of this guide assumes self-hosted agents on GKE — Agent Builder deserves its own implementation treatment. For the Autopilot-vs-Standard and CRD-vs-CTD decisions, the sections below surface the consequences at each pillar and show where the runtime behavioral layer fills the gaps that the forced-choice decisions open.

The GKE Forced-Choice Decision Matrix

Decision	What This Choice Gives You	What It Takes Away	Impact by Pillar
Autopilot vs. Standard	Autopilot: Workload Identity on by default, gVisor on every node, Google-managed node hardening, no default SA fallback. Standard: full DaemonSet access without an allowlist layer, custom node images, runtime class control.	Autopilot: privileged workloads rejected by default; eBPF runtime sensors require a WorkloadAllowlist CRD (partner-supplied or customer-authored in GKE 1.35+), which adds installation and maintenance overhead. Standard: must configure Workload Identity, gVisor, hardening, and node-pool policies explicitly.	Observe: kernel-level telemetry reachable on both modes; the operational path differs. Posture: Autopilot has fewer misconfiguration vectors; Standard has more gaps to close. Detect: Autopilot’s default hardening shifts detection toward the identity plane. Enforce: Autopilot constrains the enforcement substrate to what the allowlist mechanism admits.
Agent Sandbox CRD + managed gVisor vs. Container Threat Detection	Agent Sandbox CRD: Google’s AI-agent-specific isolation built on gVisor by default (Kata Containers also supported), kernel-level sandbox, warm pools for sub-second startup, still at API version v1alpha1. CTD: Google-supplied runtime detection for known-bad container patterns.	Per Google’s own documentation, GKE Sandbox disables CTD on the affected node pool, and every cluster must keep at least one non-sandboxed node pool. The two products cannot run side-by-side on the same nodes.	Observe: CTD’s known-pattern runtime signals disappear on sandboxed pools; Agent Sandbox contributes none. Detect: teams following Google’s recommended agent architecture silently lose Google’s own runtime detection on the exact pool where AI agents run. Enforce: Agent Sandbox CRD provides isolation; CTD provides nothing at this pillar.
Self-hosted on GKE vs. Vertex AI Agent Builder	GKE: full kernel access, complete pillar implementation, behavioral baselines at syscall granularity. Agent Builder: managed agent infrastructure, no cluster operations.	Agent Builder: the runtime surface is abstracted; behavioral detection at the kernel layer is not available. Enforcement boundaries are Google-defined, not customer-defined.	Observe: Agent Builder shifts to API-level Cloud Audit Logs only. Posture: the posture surface is a subset of GKE’s. Detect: no syscall-level behavioral baselines. Enforce: boundaries are what Google exposes, not what you configure.

The runtime behavioral layer is the one capability that stays constant across all three decisions. Whatever you choose for cluster mode, isolation technology, or program scope, the gap between “authorized action” and “normal for this specific agent at this time against this resource” is what determines whether an AI agent attack is detected or missed. Each pillar section below assumes that constant and shows where the GCP-native primitives stop.

What You Already Have: GKE-Native Primitives for AI Agent Security

Before deploying anything new, take inventory of what GKE already gives you. Each GCP primitive contributes to a specific framework phase — but each also has a boundary where it stops being useful for AI agent behavior. The table below organizes them by framework pillar and names the specific point at which each primitive’s contribution ends.

GCP Primitive	What It Contributes	Framework Phase	Where It Stops
Cloud Audit Logs (Admin Activity, Data Access, System Event)	API-level audit trail: who called aiplatform.InvokeEndpoint, bigquery.jobs.insert, storage.objects.create, from which principal, at what time. Captures KSA-to-IAM principal exchanges through the GKE metadata server.	Observe (API activity), Posture (permission usage)	Logs the request, not the consequence. Cannot see what the agent did inside the pod after the API returned a response.
Workload Identity Federation (KSA principals)	Per-pod IAM identity via KSA-as-principal bindings. Short-lived OAuth2 tokens via the GKE metadata server at 169.254.169.254. No long-lived keys in manifests.	Enforce (identity boundaries), Posture (declared scope)	Grants the permissions ceiling, not the actual permissions needed. Cannot tell you which of 47 permitted APIs the agent actually uses.
Security Command Center — Container Threat Detection	Runtime eBPF agent detects known-bad container patterns: Added Binary Executed, Added Library Loaded, Reverse Shell, Malicious Script Executed, Malicious URL Observed.	Detect (known signatures)	Incompatible with GKE Sandbox on the same node pool. Ships static rules, no behavioral baselines, silent on AI agent misuse through authorized tool surfaces.
Security Command Center — Event Threat Detection	Identity and audit-surface anomaly detection: suspicious IAM grants, privilege escalation patterns, anomalous service account use visible in Cloud Audit Logs.	Detect (identity anomalies)	Assumes stable identity behavior. AI agent identity use varies legitimately as models update and tools come online — produces noise or goes silent during actual attacks.
Model Armor	Content-plane screening for prompts and responses: prompt injection and jailbreak detection, content safety filtering (hate, harassment, dangerous content), sensitive data protection through DLP, malicious URL detection, and malware scanning in attached PDFs.	Detect (content plane)	Operates on the language plane before and after the model call, not on the agent’s subsequent behavior. Indirect injection payloads crafted as benign instructional text frequently pass classifiers operating on adversarial prose.
Chronicle (Google Security Operations)	SecOps ingestion and correlation layer. UDM normalization across GCP and non-GCP sources. YARA-L rule language supports custom correlation across event types. Content Hub and investigation-automation features (including the Triage & Investigation Agent) continue to expand.	Detect (correlation target)	Shipping curated detection content remains organized around traditional cloud and endpoint threat patterns. No supplied rule set correlates Model Armor, CTD, ETD, and Workload Identity events into AI-agent-specific incidents. Rule authoring is the customer’s detection-engineering work.
VPC Service Controls	Perimeter enforcement around Google Cloud APIs: BigQuery, Cloud Storage, Secret Manager, Vertex AI, Artifact Registry. Restricts which contexts can access which APIs.	Enforce (API perimeter)	Perimeter sees allowed traffic between perimeter-internal services as legitimate. Behavioral misuse through sanctioned paths inside the perimeter is invisible.
Agent Sandbox CRD + managed gVisor	Kernel-level isolation for LLM-generated code execution. Built on gVisor by default with Kata Containers also supported as an isolation backend. Ephemeral environments, warm pools, snapshot-based lifecycle. Google’s recommended primitive for AI agent workloads, still at API version agents.x-k8s.io/v1alpha1.	Enforce (code execution isolation)	Controls where the agent runs, not what it does once running. Disables CTD on affected node pools. Requires at least one non-sandboxed pool in the cluster.
Binary Authorization	Admission-time image attestation for deploy-time enforcement. Verifies that agent and model images came from trusted pipelines before they run.	Enforce (supply chain), Posture (image provenance)	Does not observe runtime behavior. An attested image can still host a compromised agent or a legitimate agent being manipulated.

The pattern across every row is the same one the parent framework identifies: GCP primitives handle identity, audit, supply chain, and signature-based runtime detection well. The behavioral gap — what your AI agents actually do at runtime, whether an authorized action is consistent with observed normal, and how to derive enforcement from evidence rather than guesswork — is what the rest of this guide wires in. Runtime behavioral context is the pillar-spanning capability that closes that gap at every phase.

Phase 1: Observe — Deploying Runtime Visibility on GKE

Observation is the foundation. You cannot assess posture, detect threats, or enforce policies for AI agents until you know what they actually do — which tools they call, which Google Cloud APIs they reach, which models they load, which data sources they access. Cloud Audit Logs captures the control-plane view. Phase 1 adds the runtime behavioral view that sits underneath.

eBPF sensor deployment on Standard and Autopilot

On GKE Standard, ARMO’s eBPF-based sensor deploys as a DaemonSet on each node pool via Helm, instrumenting kernel-level events for every pod: syscalls, process trees, network connections, file access. Container-Optimized OS (COS) and Ubuntu node images both support it. Overhead lands at 1–2.5% CPU and ~1% memory per node — inside the performance budget most platform teams already accept for observability tooling. On Autopilot, the deployment path is different: Autopilot’s default constraints reject privileged workloads, so the sensor (and Google’s own CTD) runs only when a matching WorkloadAllowlist is installed in the cluster. Partner-supplied allowlists — including ARMO’s — are available as of GKE 1.35; eligible customers can also author their own. The operational consequence for Phase 1: on Autopilot, the platform team adds an allowlist-installation step before the sensor rolls out, monitors the Warden admission webhook for rejections from third-party webhooks that inject sidecars, and tracks allowlist updates as partners ship new versions. On Standard, the DaemonSet deploys without the allowlist layer but you inherit more configuration responsibility for node-pool hardening. Kernel-level telemetry is reachable on both; the operational cost is materially different.

Cloud Audit Logs configuration for AI agent operations

Admin Activity logs are always-on. Data Access and System Event logs are not. For AI agent workloads, enable Data Access logs explicitly on the Google Cloud services agents call at runtime: aiplatform.googleapis.com for Vertex AI inference, bigquery.googleapis.com for dataset queries, storage.googleapis.com for object access, and secretmanager.googleapis.com for credential retrieval. Route to Cloud Logging and mirror to Chronicle for long-term retention and correlation. Without Data Access logging enabled on these specific services, the audit trail records that the agent authenticated — and nothing about what it did once authenticated.

The KSA-principal audit surface shift

Google’s simplified Workload Identity Federation allows IAM policies to reference Kubernetes service accounts directly as principals, eliminating the GSA-intermediary pattern and the iam.gke.io/gcp-service-account annotation. Operationally cleaner — and the audit surface changes. IAM audit logs now show KSA principals directly in the principalEmail field in formats like principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/ns/NAMESPACE/sa/KSA_NAME. Log analysis tooling and Chronicle parsers need to recognize these formats and route them through the same investigation paths as traditional service account activity. Posture assessments that were written against the GSA pattern need updating; detection rules that key on GSA email formats will silently miss KSA-bound agent activity.

The first deliverable: runtime AI-BOM

Phase 1 ends with a runtime-derived AI Bill of Materials that catalogs behavioral discoveries: AI agents self-hosted on GKE, inference servers, MCP tool runtimes, RAG data sources, Vertex AI endpoints called from cluster workloads, and external model APIs reached through egress. Runtime-derived rather than manifest-derived, because AI workloads routinely use components at runtime that no deployment manifest declares. The AI-BOM is what Phase 2 depends on — you cannot compare declared permissions against observed behavior until you know what the observed workload actually is. For the full treatment of how runtime observability produces this inventory on Kubernetes specifically, see the runtime observability deep-dive.

Phase 2: Posture — Declared vs. Observed on GKE

The Posture pillar’s job is to surface the gap between what the AI agent can do — declared IAM permissions, admission-time policy, attested images — and what it actually does. On GKE, four posture sources contribute, and each has a specific behavioral-gap boundary.

Runtime-informed Workload Identity posture

Phase 1 captured exactly which APIs each agent called and which datasets it read. Phase 2 compares that observed behavior to the declared KSA-to-IAM bindings. The typical finding: agents authorized for dozens of APIs actually exercise three. That gap is a posture finding generated from evidence rather than guessed from a manifest — and on GKE it lands harder than on other clouds because project-level role grants are so common in Google’s own reference material. The GKE sandboxing guide walks through the specific project-level role trap pattern (aiplatform.user, bigquery.dataViewer, storage.objectViewer granted at project scope rather than resource scope) in depth; Phase 2 treats it as a posture finding surfaced by the declared-vs-observed comparison and handled at the Enforce pillar through IAM scope tightening.

Policy Controller, Config Connector, and admission-time posture

Policy Controller (built on Open Policy Agent and Gatekeeper) evaluates policies at resource admission — Pod specs, NetworkPolicies, RBAC bindings, and Workload Identity bindings get checked against policy constraints before they enter the cluster. For AI agent workloads, the posture question is whether your constraint templates cover agent-specific concerns: required Workload Identity binding verification, forbidden use of the default service account, required runtime class for agent pods, image provenance requirements, and resource limits that survive non-deterministic workload behavior. Config Connector extends this surface to Google Cloud resources themselves (IAM bindings, Secret Manager secrets, BigQuery datasets), making cross-resource posture queries expressible as Kubernetes admission policies rather than separate scripts.

The default Compute Engine service account fallback

On Standard clusters, a pod without an explicit Workload Identity binding falls back to the node’s service account. That node SA is typically the Compute Engine default service account, which in most projects carries Editor at the project level — enough to touch every Google Cloud service in the project. One misconfigured node pool running one misconfigured agent pod produces project-wide write access for a workload that was supposed to have read-only scoped access to a single BigQuery dataset. Posture tools flag this in two places: Workload Identity should be enabled on every node pool running agent workloads, and no agent Deployment should reference the default Kubernetes service account without a KSA-to-IAM binding. On Autopilot, this fallback cannot occur because Workload Identity Federation is always on — which is one of the concrete trade-offs Decision 1 above is trading.

Runtime-informed posture and SCC’s boundary

Security Command Center’s posture surface includes AI-BOM discovery at the project level, misconfiguration findings, and vulnerability scanning through Artifact Registry integration. It does not produce behavioral posture findings — no declared-vs-observed gap analysis, no per-agent permission usage profiling, no identification of which granted capabilities are actually exercised. This is the boundary where runtime-informed posture takes over. ARMO’s Application Profile DNA builds baselines at the Deployment level rather than the pod level, because AI agent pods typically don’t live long enough to converge per-pod under model updates and pod churn. Per-Deployment baselines produce the stable declared-vs-observed comparison that drives the findings list: granted-but-unused permissions, granted-but-overused scopes, observed-but-undeclared egress destinations, and the behavioral-baseline inputs that Phase 3 needs.

Phase 3: Detect — Behavioral Context for Non-Deterministic Workloads

GKE’s detection surface is the most fragmented of the three major clouds. AWS funnels through GuardDuty and CloudTrail into a relatively consolidated detection plane. Azure funnels through Defender for Cloud and Sentinel. GCP splits runtime detection across Model Armor (content plane), Security Command Center’s CTD (runtime signatures) and ETD (identity anomalies), and Chronicle (correlation target) — four products from three separate Google product teams, with no shipped plane that assembles their signals into AI-agent-specific incidents. Phase 3’s job is to wire each product into the right pillar role and add the behavioral layer where the GCP-native stack does not ship one.

Model Armor as a Detect input, not a Detect answer

Model Armor contributes content-plane screening: prompt injection classifiers, jailbreak detection, and sensitive data redaction applied to prompts and responses before and after the model processes them. Valuable for its design scope. The boundary is that Model Armor operates on the language plane — it does not see what the agent does with the model’s response inside the cluster, and indirect prompt injection payloads crafted as benign instructional text are a documented residual risk for content classifiers operating on adversarial prose. Treat Model Armor as one input to the Detect pillar whose signals — prompt screening passes, classifier decisions, redaction events — flow into the correlation layer alongside runtime signals. It is not the Detect pillar.

Container Threat Detection and the Agent Sandbox CRD incompatibility

CTD ships an eBPF runtime agent tuned to known-malicious patterns: Added Binary Executed, Reverse Shell, Malicious Script Executed, and similar signatures that work well for traditional container compromise. The model breaks down for AI agents because the most consequential agent compromises do not involve added binaries or reverse shells — they involve the agent doing something its authorized tool surface allows, in a sequence it has never produced before, against a target that is technically permitted but contextually wrong. No CTD signature fires on that pattern. More structurally, on any node pool where GKE Sandbox is enabled, CTD is disabled by Google’s own documentation. Teams that follow the recommended Agent Sandbox CRD architecture lose CTD entirely on the clusters where AI agents run — the Decision 2 trade-off showing up at the Detect pillar. The replacement is a runtime behavioral layer that operates inside the sandbox, watching syscall patterns and process lineage against per-Deployment baselines rather than matching against static signatures.

Event Threat Detection and the identity-behavior variance problem

ETD’s anomaly model assumes relatively stable identity behavior — principals that act in characteristic patterns over time. AI agents structurally violate this assumption because their identity use varies legitimately as models update, tool surfaces shift, and downstream services evolve. ETD either produces noise (flagging every variation) or goes silent (treating variation as expected, including the malicious kind). Treat ETD as a low-confidence input to Phase 3 that catches classical identity anomalies — suspicious grant events, known privilege-escalation patterns — but not as the primary signal source for AI agent behavioral detection.

Chronicle as correlation target, not correlation engine

Chronicle is Google’s SecOps platform: ingestion, UDM normalization, retention, and a rule language that supports correlation across event types. Its scale and normalization are real. What is not shipping, in the currently curated detection content, is AI-agent-specific correlation — no supplied rule that says a Model Armor screening pass plus a Workload Identity token use plus a downstream tool invocation against a sensitive data target equals a potential indirect injection chain. That logic is expressible in Chronicle’s rule language; authoring, tuning, and maintaining it is customer detection-engineering work, and requires AI agent threat modeling capacity that most SOC teams are still building. A CADR platform that ships this correlation logic on the AI-agent threat model routes assembled attack stories into Chronicle as single events, with Chronicle serving as the long-term retention and SIEM-integration surface rather than the logic layer. For the detection patterns that matter here specifically, see the walkthrough of behavioral anomaly detection and intent drift.

The behavioral layer that closes the gap

Application Profile DNA per Deployment produces behavioral baselines that survive pod churn and tolerate model-update-driven variance — per-pod baselines don’t converge for AI agents because individual pods don’t live long enough. ARMO’s Cloud Application Detection & Response assembles full-chain correlation: content-plane input (from Model Armor where deployed) plus syscall-level runtime signals plus Workload Identity token use plus downstream data access plus egress behavior, joined into a single attack story rather than four rows in four consoles. On Standard clusters running both ARMO and CTD, the two layers complement: CTD catches known-bad patterns that generalize across workload types; the behavioral layer catches AI-specific misuse that CTD’s signature model cannot express. On clusters running Agent Sandbox CRD, the behavioral layer covers the Detect gap the Sandbox-CRD decision creates.

Phase 4: Enforce — From Behavioral Evidence to GKE-Native Policies

Enforcement is the output of Phases 1 and 2, not the starting point. Four weeks of Application Profile DNA data tells you exactly what each agent does — which APIs, which datasets, which egress endpoints, which syscalls. Enforcement on GKE maps to six concrete mechanisms, each wired from that observed evidence rather than guessed from a manifest. The observe-to-enforce methodology covers the cloud-agnostic workflow; this section covers the GKE-specific substrate.

Workload Identity scope tightening from observed API usage

Phase 2 surfaced the gap: dozens of authorized APIs, three actually used in practice. In Phase 4, rewrite the KSA’s IAM bindings to the observed set, at resource-level granularity wherever possible — specific Vertex AI endpoint rather than project-scope aiplatform.user, specific BigQuery dataset rather than project-scope bigquery.dataViewer, specific Cloud Storage bucket rather than project-scope storage.objectViewer. For the specific patterns where this most often goes wrong (and how Google’s own codelabs reinforce the overprivileged default), the GKE sandboxing guide walks through the project-level role trap in depth.

Seccomp profiles from observed syscall distributions

ARMO’s sensor recorded every syscall each agent pod made during Phase 1 and 2 observation windows. Generate least-privilege seccomp profiles that allow exactly the syscalls the agent actually uses and block everything else, then deploy as Kubernetes SeccompProfile resources referenced in the pod’s security context. The progression is the same as on other clouds: audit mode first (log what would be blocked without blocking), validate for a week against live traffic, then graduate to enforce. Because profiles are generated from observed behavior rather than guessed from a manifest, the risk of breaking production drops dramatically — the core principle of the parent framework.

NetworkPolicy from observed egress behavior

GKE Standard enforces Kubernetes NetworkPolicy through one of two plugins: Dataplane V2 (Cilium-based, eBPF, Google-recommended and the default on Autopilot) or Calico (opt-in on Standard only). Without a plugin selected, NetworkPolicy resources in the cluster aren’t enforced — verify your cluster’s network plugin before generating policies from observed egress. Once the plugin is in place, generate policies from Phase 1 egress baselines: model API endpoints agents actually reach, vector database hosts, external tool APIs, RAG data sources. Deploy in audit mode first, compare real egress against the baseline, tighten to deny-all with explicit allows for observed destinations, and maintain monitoring for legitimate new destinations that require policy updates. One specific rule belongs in every AI agent namespace: a NetworkPolicy that blocks egress to 169.254.169.254, the GKE metadata server — Google’s own GKE Sandbox documentation recommends this explicitly when using Workload Identity Federation, because the metadata endpoint is where compromised credentials get exchanged for tokens. Cilium’s eBPF substrate is architecturally complementary to the ARMO sensor — both operate at the kernel layer — which means the enforcement data plane and the observability data plane share telemetry rather than duplicating it.

VPC Service Controls with behavioral context inside the perimeter

VPC Service Controls remains the boundary control: which contexts (networks, identities, devices) can reach which Google Cloud APIs. For AI agent workloads, the perimeter should include the data services agents touch (BigQuery, Cloud Storage, Secret Manager), the inference surface (Vertex AI), and the supply chain target (Artifact Registry). What VPC-SC cannot distinguish — legitimate intra-perimeter traffic from behavioral misuse of sanctioned paths between perimeter-internal services — is what runtime behavioral enforcement provides inside the perimeter. A compromised agent exfiltrating through allowed APIs from inside the perimeter produces behavioral signals (unusual data volumes, atypical query targets, novel staging patterns) that the behavioral layer catches and VPC-SC was never designed to see. The sanctioned exfiltration walkthrough in the GKE sandboxing guide details the specific pattern and the detection signals that identify it.

Agent Sandbox CRD + managed gVisor as the isolation underlay

Where Decision 2 favored GKE Sandbox, the Agent Sandbox CRD handles code execution isolation at the kernel level and the behavioral layer handles what happens inside the sandbox. These are complementary rather than overlapping: the CRD controls where the agent runs (isolated environment, ephemeral lifecycle, warm pools for performance); behavioral enforcement controls what it’s allowed to do once running. For the detailed walkthrough of the sandbox CRD’s boundaries and where each layer stops, see the dedicated GKE sandboxing guide.

Binary Authorization at deploy-time

Binary Authorization enforces image attestation at admission: only images with required attestations from trusted build pipelines can run. For AI agent workloads, this covers both the agent runtime image and any model images pulled at runtime. Pair it with runtime behavioral enforcement — Binary Authorization stops unattested images from running; behavioral enforcement constrains what attested images can do. Most of the interesting AI agent compromises involve fully-attested images being manipulated through prompts, not unattested images being deployed, which is why the layers are additive rather than redundant.

How This Implementation Differs From EKS and AKS

The framework methodology is the same on every cloud. The wiring is structurally different in five ways, and the differences are not cosmetic:

1. GKE forces architectural decisions at cluster creation time that EKS and AKS do not. Autopilot-vs-Standard has no direct equivalent in AWS — the choice shapes whether privileged sensors deploy directly or require a WorkloadAllowlist CRD, which is a category of decision neither Fargate nor AKS managed clusters expose in the same way. The EKS implementation treats Fargate as a workload-level caveat rather than a program-shaping decision.
2. GCP’s detection surface is split across four products (Model Armor, SCC’s CTD, SCC’s ETD, Chronicle) from three product teams. AWS funnels through GuardDuty; Azure funnels through Defender and Sentinel. Same behavioral gap, substantially more assembly work on GCP.
3. GKE’s recommended AI agent architecture silently disables Google’s own runtime detection product on the node pool where agents run, while the Security Command Center dashboard continues to show CTD enabled at the org level. No equivalent self-canceling design exists on EKS or AKS — GuardDuty EKS Runtime Monitoring runs alongside any sandboxing approach, and Defender for Containers is independent of isolation choices.
4. Workload Identity Federation with KSA principals exposes Kubernetes service accounts directly in IAM audit logs. IRSA and AKS Workload Identity use intermediary identity mappings; GKE’s newer pattern does not. Log analysis tooling, detection rules, and forensic investigation paths have to handle the KSA principal format explicitly.
5. Chronicle is the SIEM target, not a peer detector — mirroring AKS’s use of Sentinel and differing from AWS where the integration targets are EventBridge and CloudWatch. For teams operating across multiple clouds, the multi-cloud framework guide covers what breaks at the boundaries between these different integration models.

From Framework to Running Security Controls on GKE

Every phase above maps to a specific capability in the ARMO platform. Phase 1’s runtime discovery uses the Kubernetes-first AI workload detection and runtime-derived AI-BOM generation. Phase 2’s posture assessment uses runtime-informed gap analysis comparing declared Workload Identity scopes against observed API usage. Phase 3’s detection uses CADR with LLM-powered attack story correlation that assembles Model Armor signals, CTD findings (where active), identity events, and behavioral anomalies into a single narrative that lands in Chronicle as one event rather than four. Phase 4’s enforcement uses eBPF-based progressive sandboxing that promotes Application Profile DNA baselines into production-safe Workload Identity scopes, seccomp profiles, NetworkPolicies, and Binary Authorization attestation policies.

The quantified outcomes carry over from the parent framework: 90%+ CVE noise reduction through runtime reachability analysis, 90%+ faster investigation through attack story correlation, 80%+ reduction in issue overload through runtime-based prioritization — at 1–2.5% CPU and ~1% memory overhead per node. The platform runs on Kubescape, the open-source Kubernetes security project used by over 100,000 organizations, which means Phase 1 can start with free runtime observability before committing to the full platform. Kubernetes-native, eBPF-based, no sidecars, no code changes.

To see how each program phase maps to your GKE environment, including the Autopilot-vs-Standard trade-offs for your specific cluster configuration and the detection-layer wiring around your Agent Sandbox CRD decisions: book a demo.

Frequently Asked Questions

Should I use GKE Autopilot or Standard for AI agent workloads?

This is the Decision 1 forced choice. Autopilot enables Workload Identity Federation by default, runs managed gVisor on every node, and eliminates the Compute Engine default service account fallback — three fewer misconfiguration vectors. It enforces default constraints that reject privileged workloads, so eBPF-based runtime sensors (ARMO’s, Google’s own CTD) require a WorkloadAllowlist CRD to run — partner-supplied or customer-authored in GKE 1.35+. Standard admits privileged DaemonSets without the allowlist layer but requires explicit configuration of node hardening, Workload Identity, and runtime class policies. Kernel-level telemetry is reachable on both, so the decision is operational: Autopilot trades default-on hardening for allowlist maintenance; Standard trades explicit-configuration discipline for direct DaemonSet access. Mixed environments — Autopilot for less sensitive workloads, Standard (or Autopilot with a partner allowlist installed) for AI agents requiring full four-pillar coverage — are a common and valid pattern.

If I use Agent Sandbox CRD with managed gVisor, what replaces Container Threat Detection?

Per Google’s documentation, GKE Sandbox disables CTD on affected node pools — they cannot coexist on the same nodes. The replacement is a runtime behavioral layer that operates inside the gVisor sandbox rather than against raw kernel syscalls. eBPF-based telemetry that runs as a privileged DaemonSet on Standard nodes (which is where GKE Sandbox is typically deployed) watches syscall patterns inside the sandbox and compares them against per-Deployment behavioral baselines rather than matching against static signatures. The Agent Sandbox CRD controls where the agent runs; the behavioral layer controls what it’s allowed to do once running. The two layers are complementary.

How does this implementation differ from the EKS implementation guide?

The framework and the methodology are the same. The wiring differs on the five structural dimensions covered in the section above: cluster-creation forced choices on GKE that EKS does not impose, a more fragmented native detection surface on GCP, a recommended AI agent architecture that disables Google’s own detection product on GKE, a different Workload Identity principal format that changes the audit surface, and Chronicle-as-SIEM-target rather than peer detector. For the AWS-specific wiring against EKS, see the EKS implementation guide. For cross-cloud programs that span providers, the multi-cloud framework guide addresses what breaks at the boundaries between these different cloud models.