Making AI Egress Technically Impossible Inside Your VPC

To prevent data exfiltration from AI workloads, most firms write a policy. "No client data leaves our environment." Then the inference call goes over a NAT gateway to an API endpoint, resolved by public DNS, through a route nobody has reviewed since the VPC was created. The policy says the data stays. The routing table disagrees, and the routing table wins every time. This piece is for platform and security engineers who want the second sentence to be physically true: a concrete control stack, per layer, with the verification tests that prove exfiltration paths are closed rather than merely forbidden.

Why can't policy alone prevent data exfiltration from AI workloads?

NIST separates the two cleanly. SP 800-53 control AC-4, Information Flow Enforcement, requires that the system itself enforce where information can travel, not that users agree to keep it in place [1]. A policy lives in a document. Information flow enforcement lives in route tables, endpoint policies, resolver rules, and firewall state. The first is a promise about behavior. The second is a property of the network.

AI workloads make the gap wider than usual. A model call is an egress event by design: your data leaves a process you control and arrives at an inference process. If that path traverses the public internet, every hop is an exfiltration channel whether or not anyone intends to use it. Prompt injection makes intent irrelevant. An agent tricked into "summarize this document and send the result" will use whatever egress exists [6]. OWASP's 2025 LLM Top 10 lists sensitive information disclosure as LLM02 and catalogues the exfiltration techniques attackers already use against LLM applications [5]. You cannot train or instruct your way out of an open route. You can only close the route.

Regulators read it the same way. HIPAA's Security Rule at 45 CFR 164.312 requires technical safeguards: access control, audit controls, and transmission security implemented as mechanisms, not intentions [7]. An examiner does not ask what your acceptable-use policy says. They ask what the system makes impossible.

The four layers that turn policy into physics

Egress control for AI workloads is four layers deep. Each layer closes a class of paths the others cannot.

On AWS, the private-endpoint layer is VPC endpoints with endpoint policies: resource policies attached to the endpoint that cap which principals and actions can pass, independently of IAM [2]. On Google Cloud it is VPC Service Controls, which draw a perimeter that blocks API-level copy operations across the boundary even when the caller has valid IAM permissions [3]. Azure's equivalent is Private Link with network policies on the private endpoint [4]. The naming differs. The physics is the same: the request never gets a public path, and a second control checks it even when identity checks pass.

The DNS layer matters more than most teams expect. Blocked TCP egress does nothing against DNS tunneling, which encodes data into queries to attacker-controlled domains [8]. If your VPC resolver forwards anything to the internet, you have an open channel. AWS's Route 53 Resolver DNS Firewall supports allowlists, query-type filtering, and managed detection of tunneling and domain-generation patterns [9]. On other clouds the equivalent is a resolver rule that only resolves your approved domain list and drops the rest.

The gateway is the chokepoint. Once network, endpoints, and DNS leave exactly one permitted destination, that destination is where enforcement lives: workload identity, per-model routing, redaction of regulated fields, and the audit log an examiner will ask for. This is the pattern we call Controls as Architecture: the control is not a review step around the system, it is a load-bearing part of the system. The gateway design itself is covered in AI gateway architecture for the enterprise.

The egress control stack: a checklist you can run Monday

Work through this in order. Each item has a physics test: a command or probe that proves the path is closed. If the test passes, the control is real. If it fails, you have a policy, not a control.

1. Isolate the AI subnet. No public IPs, no NAT gateway, no route to an internet gateway. Test: from a workload pod or instance, curl https://ifconfig.me times out.
2. Route model APIs through private endpoints. Interface endpoints or Private Service Connect for every model provider you use. Test: dig on the provider hostname returns a private address inside your VPC CIDR.
3. Lock the endpoint policy. Restrict principals to the workload roles and actions to invoke-only. The default endpoint policy grants full access to everything, so an unlocked endpoint is a hole with good intentions [2]. Test: an unprivileged role calling the endpoint is denied.
4. Allowlist DNS. Resolver firewall resolves only approved domains; everything else returns NXDOMAIN and logs. Block outbound TCP/UDP 853 and DoH ports at the edge so workloads cannot bring their own resolver. Test: dig exfil.example.com from the subnet fails; dig @8.8.8.8 fails harder.
5. Make the gateway the only egress. Security groups allow outbound from AI workloads to the gateway's ENI and nothing else. Test: direct calls to any provider endpoint from the workload fail; the same call through the gateway succeeds and appears in your log.
6. Deny by organization policy. SCPs or org constraints block creation of NAT gateways, public IPs, and internet gateways in the AI accounts, so the isolation survives the next enthusiastic engineer. Test: attempting to create one is denied at the org level.
7. Prove it quarterly. Run an exfiltration drill: a test workload tries raw sockets, DNS tunneling, DoH, and an allowlisted-domain channel. The first three must fail; the fourth tells you what your gateway inspection needs to catch. Test: the drill report exists and is dated.

The companion discipline is detection: flow logs and resolver logs on the isolated subnet should show zero denied-egress noise in steady state. A spike is either a misconfigured deployment or something worth investigating, and both belong in the audit trail an examiner will eventually request.

The case against: egress control is a wall with a door in it

The skeptical case is strong, and engineers should hear it at full strength.

First, the door. Egress controls stop unauthorized channels and do nothing about authorized ones. The 2023 MOVEit breach compromised over 2,700 organizations by exploiting a product whose entire job was moving data out of the network; the attacker never had to bypass an egress control because the egress channel was sanctioned [10]. Your AI gateway is, by design, a pipe from your most sensitive data to an external inference provider. Locking every other door and polishing that one is not exfiltration prevention. It is exfiltration governance, and the difference matters when the provider is breached, compelled, or careless with logs.

Second, the bypasses are real. DNS firewall allowlists leak: DNS-over-HTTPS to public resolvers has been used to slip past egress policies in hardened CI environments, and CNAME chains through allowlisted domains resolve just fine unless your filter follows them [11]. A determined insider or a compromised workload with gateway credentials walks out the front door. Network controls are perimeter controls, and perimeters have a well-documented history of failing against motivated attackers already inside.

Third, the agent problem. Simon Willison's "lethal trifecta" names the actual risk shape: an agent with access to private data, exposure to untrusted content, and the ability to communicate externally is one prompt injection away from exfiltration, no matter what the firewall says, because the exfiltration rides a channel the agent is supposed to have [6]. Network physics cannot fix that. Only capability design can: separating the agent that reads untrusted content from the agent that touches private data and the agent that can send.

The skeptical conclusion: egress control is necessary hygiene but sells itself as a solution, and teams that deploy it declare victory while the sanctioned channel, the prompt-injected agent, and the flat network inside the perimeter all remain open.

Our read

The skeptics are right that egress control is not sufficient. They are wrong that this makes it optional, and the "wall with a door" framing undersells what the physics buys you.

Every control in the stack removes a failure mode that policy cannot touch. The isolated subnet makes the junior engineer's pip install from a typosquatted host a timeout instead of a breach. The endpoint policy makes stolen provider credentials worthless outside your network, which is the exact scenario VPC Service Controls was built for [3]. The DNS allowlist kills the cheapest exfiltration channel in the attacker's toolkit. None of these stop the sanctioned channel. All of them shrink the problem to one channel, and one channel is something you can redact, log, rate-limit, and audit. That is the move from "exfiltration is possible anywhere" to "exfiltration is possible in exactly one place, where we are watching."

The trifecta point we take at full strength: network controls are not a substitute for agent capability design, and any agent that reads untrusted content and holds private data needs its outbound tools constrained at the application layer too. We cover that discipline in prompt injection defense for the enterprise. Physics first, then capability design, then policy on top, in that order. Most firms have it backwards.

What this means for you

• Test, do not audit. For each layer of the stack, run the physics test, not the config review. A route table that someone verified in a console last quarter is a rumor. A failed curl from the subnet today is a fact.
• Shrink to one channel, then instrument it. The goal is not zero egress; it is one egress, through a gateway that redacts, logs, and attributes every call to a workload identity. Budget your inspection effort there.
• Treat the provider path as exfiltration-adjacent. Your gateway's upstream to the model provider is a sanctioned exfil channel. Contract for zero retention, pin the private path, and log what you send. The HIPAA technical safeguards checklist for AI maps this to 164.312 evidence an examiner accepts.
• Fix the trifecta at the application layer. If an agent reads email or web content and touches client data, split the capabilities before you tune the firewall. Network controls will not save a prompt-injected agent from itself.
• Find your shadow channels first. The stack above assumes you know where your AI workloads run. If teams call provider APIs from laptops and SaaS tools outside the VPC, start with shadow AI detection in the enterprise, because physics only governs the network you actually control.

Book a free assessment: systemics.ai.

References

1. "Security and Privacy Controls for Information Systems and Organizations (SP 800-53 Rev. 5), AC-4 Information Flow Enforcement." NIST, September 2020 (updated December 2020). https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
2. "Control access to VPC endpoints using endpoint policies." AWS Documentation, accessed August 2026. https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html
3. "Overview of VPC Service Controls." Google Cloud Documentation, accessed August 2026. https://cloud.google.com/vpc-service-controls/docs/overview
4. "What is Azure Private Link?" Microsoft Learn, accessed August 2026. https://learn.microsoft.com/en-us/azure/private-link/private-link-overview
5. "OWASP Top 10 for Large Language Model Applications (2025)." OWASP Foundation, 2025. https://owasp.org/www-project-top-10-for-large-language-model-applications/
6. "The lethal trifecta for AI agents: private data, exposure to untrusted content, and external communication." Simon Willison, June 16, 2025. https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/
7. "45 CFR 164.312 - Technical safeguards." eCFR, current as of 2026. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.312
8. "What Is DNS Data Exfiltration?" Akamai, accessed August 2026. https://www.akamai.com/glossary/what-is-dns-data-exfiltration
9. "Route 53 Resolver DNS Firewall." AWS Documentation, accessed August 2026. https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall.html
10. "Cloud Egress Security: Preventing Data Exfiltration at the Architecture Level." Stealth Cloud, May 2026. https://stealthcloud.ai/cloud-paradigms/cloud-egress-security/
11. "More egress filtering bypasses in harden-runner." Devansh, March 2026. https://devansh.bearblog.dev/harden-runner-bypass/