Egress Control for AI Agents on GCP

Egress control for AI agents on GCP means forcing every outbound call an agent makes through an inspected, default-deny path: VPC firewall egress rules and Cloud NAT to constrain the routes, plus an inline proxy that evaluates host, method, path, headers, and tool arguments before the request ever leaves your project.

Why agent egress on GCP is not ordinary workload egress

A conventional microservice has a fixed set of destinations you can enumerate at design time. An LLM agent does not. The destination set is produced at inference time by a model reading untrusted input: a retrieved document, an issue comment, a web page, a tool response from a third-party MCP server. That means your allowlist is no longer a deployment detail, it is the last deterministic control between a prompt injection and a real HTTP request.

On GCP this matters more than most teams expect, because the default posture of a VPC is permissive on egress. A new VPC network ships with an implied allow-all egress rule at priority 65535. A Compute Engine VM or GKE pod with a route to a Cloud NAT gateway can reach any public endpoint on 443. Nothing in that path reads the request body, and nothing knows the difference between a legitimate Vertex AI call and an agent POSTing your customer table to a paste site.

The GCP building blocks, and what each one cannot see

Google gives you real primitives here. They are necessary. They are also, individually, blind to agent intent. The pattern is the same one we described for egress control on Azure: cloud-native network controls resolve to hosts, ports, and identities, never to what the agent is actually trying to do.

Step-by-step: building a gcp agent egress proxy path

The goal is one enforced chokepoint per agent workload. Here is the order of operations that survives a real security review.

1. Give agents their own subnet and service account. Do not run agent workloads in a shared subnet with batch jobs. Create a dedicated subnet in the agent VPC and bind each agent runtime to a distinct service account so firewall rules and proxy policy can key off identity rather than IP.
2. Delete the implied allow. Create an egress deny rule at a low priority number (for example, priority 1000, action deny, destination 0.0.0.0/0, all protocols) scoped to the agent service account. This inverts the default and makes every subsequent allow explicit. This is the same posture described in default-deny egress allowlisting, expressed in GCP terms.
3. Allow exactly one destination: the proxy. Add a higher-priority egress allow rule permitting TCP 443 (and 3128 or whatever port you standardise on) to the internal IP or internal load balancer fronting the Agent G proxy. Nothing else. No Cloud NAT route for the agent subnet.
4. Put the proxy behind an internal passthrough load balancer. Run the proxy as a managed instance group or a GKE Deployment in its own subnet with its own egress rules and its own Cloud NAT gateway. Only the proxy subnet gets an external path.
5. Force the client-side configuration. Set HTTPS_PROXY, HTTP_PROXY, and NO_PROXY in the agent runtime environment, and mount the proxy CA bundle so Python requests, httpx, Node fetch, and the gcloud SDK all trust it. Environment variables alone are advisory, which is why step 2 and 3 exist: if a library ignores the proxy, the packet is dropped at the firewall rather than escaping.
6. Write policy against tool semantics, not just hosts. Allowing api.github.com is not a policy. Allowing GET and POST to /repos/{org}/*/issues while denying DELETE /repos/* is a policy. This is where a purpose-built agent firewall diverges from Cloud NGFW.
7. Log every decision out of band. Ship allow, deny, and escalate events with the agent service account, destination, path, matched rule, and payload fingerprint to Cloud Logging and then to your SIEM. The log must be written by the proxy, not by the agent process, so a compromised agent cannot edit its own audit trail.
8. Test the deny path in CI. Add a job that runs a container in the agent subnet and attempts a curl to an unapproved host, the metadata IP, and a DNS TXT lookup for an external zone. All three must fail before the deployment is promoted.

gcp metadata lockdown for agents

The GCE metadata server at 169.254.169.254 (and its alias metadata.google.internal) is the single highest-value target for an injected agent. A successful fetch of /computeMetadata/v1/instance/service-accounts/default/token yields a live OAuth access token carrying whatever scopes the workload service account holds. One tool call with an attacker-supplied URL is enough, which is exactly the pattern covered in our guide to SSRF in AI agents.

Practical hardening, in the order you should apply it:

• Disable legacy endpoints. Set the instance or project metadata key disable-legacy-endpoints to true so the v0.1 and v1beta1 paths, which do not require the Metadata-Flavor: Google header, are unreachable. Header-required v1 access blocks the naive image-tag and simple-GET exfiltration attempts.
• Use GKE Workload Identity. On GKE, enable Workload Identity and the metadata server proxy so pods cannot read the node service account token at all. Combine it with a NetworkPolicy that denies pod egress to the link-local range.
• Block link-local at the proxy. Agent G denies 169.254.0.0/16 by default and also denies requests whose hostname resolves into that range at connect time, which is what stops DNS rebinding from smuggling a metadata call past a name-based allowlist.
• Scope the service account down. Assume the token will eventually leak. A token with only roles/aiplatform.user on one project is a different incident from a token with project editor.

Vertex AI agent security and managed runtimes

Vertex AI agent security introduces a wrinkle: when your agent runs inside a Google-managed runtime, you own less of the network path. Anchor on three questions.

Where does the reasoning loop execute? If it runs in your VPC (Cloud Run with a Direct VPC egress connector, GKE, or a GCE MIG), the steps above apply cleanly. Set Cloud Run egress to route all traffic through the VPC, then drop the agent subnet behind the proxy.

Where do the tools execute? Tool and extension calls are the part that touches the internet. If a managed runtime calls out on your behalf, you should terminate those calls against endpoints you control (Private Service Connect, an internal MCP server, an API behind the proxy) rather than letting the runtime dial arbitrary public hosts.

Which Google APIs must remain reachable? Keep aiplatform.googleapis.com reachable through Private Google Access or PSC and wrap the project in a VPC Service Controls perimeter so model and storage access cannot be redirected into an attacker-owned project. VPC-SC handles the Google-to-Google exfiltration case that a domain allowlist alone would happily approve.

What the inline proxy adds on top of native GCP controls

Once traffic is chokepointed, you get controls no firewall rule can express. Agent G inspects the decrypted request and applies deterministic policy per agent identity: allow, deny, redact, or escalate. That means blocking a DELETE against a production resource while allowing reads, catching an API key or PHI string in a POST body before it crosses the boundary, normalising base64 and homoglyph tricks before matching, and pausing a high-risk call for human approval instead of failing it silently. Every decision produces a signed record with the service account, destination, matched rule, and timestamp, which is the artifact auditors actually want. Platform teams standardising this across many workloads should read the platform engineer's guide to agent egress, and teams routing MCP traffic can front their servers with the Agent G MCP gateway.

Frequently Asked Questions

Is Cloud NGFW enough for egress control ai agents gcp workloads need?

No. Cloud NGFW with FQDN objects handles domain-level allow and deny well, but it cannot see URL paths, HTTP methods, request bodies, or tool arguments, and it cannot pause a call for human approval. Pair it with an application-aware proxy that enforces per-action policy.

How do I stop an agent from reaching the GCP metadata server?

Set disable-legacy-endpoints to true, enable GKE Workload Identity so pods cannot read node tokens, deny 169.254.0.0/16 in VPC firewall egress rules and NetworkPolicy, and block hostnames that resolve to link-local at the proxy to defeat DNS rebinding.

Does an inline proxy break Vertex AI or gRPC traffic?

Not if you configure it correctly. Terminate and inspect HTTP(S) tool traffic, and either tunnel gRPC and streaming endpoints with CONNECT or route Vertex AI calls over Private Google Access outside the inspection path while keeping them inside a VPC Service Controls perimeter.

Can I run the proxy in a shared VPC across multiple projects?

Yes, and that is the recommended topology. Host the proxy in the host project's service subnet, expose it via an internal load balancer, and have each service project's agent subnet carry a default-deny egress rule with a single allow to the proxy address.

Bringing it together

Effective egress control ai agents gcp teams can defend in an audit looks like this: a dedicated agent subnet with no NAT route, an explicit deny-all egress rule, one allowed destination (the proxy), metadata endpoints hard-blocked, Google APIs reached privately inside a VPC-SC perimeter, and an inline policy engine that reads the actual tool call and can stop it. The cloud primitives constrain the routes. The proxy decides the actions.

Agent G runs as a drop-in egress proxy inside your VPC, enforces per-agent policy on the wire, and logs every allow and deny out of band. Request access to the Agent G private beta to deploy it in your GCP environment, or read more about how the agent firewall works.