The 2023 MOVEit breach compromised over 2,700 organizations and exposed the personal data of approximately 95 million individuals. The attack did not exploit a zero-day in the victim organizations’ own infrastructure. It exploited a SQL injection vulnerability in a file transfer appliance — a third-party component that, by design, had permission to move data out of the network. The attacker did not need to bypass egress controls. The egress channel was the product.

This is the fundamental challenge of cloud egress security: in modern distributed architectures, data must flow outward — to SaaS providers, to API partners, to analytics platforms, to CDN edges, to LLM inference endpoints. Every authorized egress path is a potential exfiltration channel. Every API integration is a trust decision. And the distinction between “authorized data transfer” and “data exfiltration” is often nothing more than the intent of the entity initiating the transfer.

The conventional response is Data Loss Prevention (DLP) — software that inspects outbound traffic for patterns matching sensitive data. The DLP market reached $3.8 billion in 2025, according to MarketsandMarkets. The efficacy of these tools against sophisticated adversaries is, to put it precisely, limited. DLP systems detect known patterns in cleartext. An attacker who encrypts, encodes, steganographically embeds, or fragments exfiltrated data bypasses pattern matching entirely. DLP is a compliance tool. It is not an exfiltration prevention architecture.

The Anatomy of Cloud Data Exfiltration

Data exfiltration from cloud environments follows predictable patterns, each exploiting a different architectural feature of cloud infrastructure.

Direct Egress: The Obvious Channel

The simplest exfiltration path: a compromised workload sends data directly to an attacker-controlled endpoint over HTTPS. In a default AWS VPC configuration, all outbound internet traffic on port 443 is permitted. The exfiltrated data is encrypted in transit (by TLS, ironically protecting the attacker’s traffic from inspection) and indistinguishable from legitimate API calls.

Mitigations exist: egress firewalls, explicit allow-listing of destination IPs and domains, FQDN-based egress policies in service meshes. But each mitigation introduces operational friction. Modern microservices architectures make hundreds of outbound API calls to dozens of external services. Maintaining an accurate egress allow-list requires cataloging every external dependency, keeping that catalog current as dependencies change, and accepting that any gap in the catalog creates either a blocked legitimate request or a permitted exfiltration path.

AWS VPC Flow Logs capture metadata (source, destination, port, bytes transferred) but not payload. Inspecting egress traffic at the payload level requires a TLS-terminating proxy — which means the proxy holds the decryption keys to all outbound traffic, creating a high-value target and a single point of compromise.

DNS Tunneling: The Covert Channel

DNS tunneling encodes data in DNS queries, typically as subdomponents of a domain controlled by the attacker. A query to aGVsbG8gd29ybGQ.exfil.attacker.com carries base64-encoded data in the subdomain. The DNS resolver forwards the query to the attacker’s authoritative nameserver, which extracts the data.

DNS is the most permissive protocol in enterprise networks. Blocking DNS breaks name resolution. Rate-limiting DNS queries produces false positives against legitimate services (Kubernetes alone generates hundreds of DNS queries per second in a moderately sized cluster). DNS over HTTPS (DoH) compounds the problem by encrypting DNS traffic, making inspection impossible without a DoH-terminating proxy.

Iodine, dnscat2, and DNSExfiltrator can achieve exfiltration throughput of 10-50 KB/s over DNS — slow by modern standards, but sufficient to extract API keys, credentials, customer databases, and intellectual property over hours or days. Palo Alto’s Unit 42 reported in 2025 that DNS tunneling was detected in 23% of investigated data breaches, up from 9% in 2021.

Supply Chain and Dependency Compromise

The most difficult exfiltration vector to defend against is a compromised dependency. The 2024 XZ Utils backdoor — a supply chain attack on a ubiquitous Linux compression library — demonstrated that a patient, skilled attacker can embed exfiltration capabilities in infrastructure that organizations trust implicitly.

Cloud environments amplify this risk. A typical Node.js application imports 200-1,500 npm packages. A Python application may pull from 50-300 PyPI packages. Each package can make outbound network calls, read environment variables (which often contain API keys and database credentials), and access the local filesystem. A single compromised package in a build pipeline can exfiltrate secrets during the CI/CD process — before the application even reaches production.

In serverless environments, the risk compounds: function handlers frequently bundle dependencies that have full access to the function’s execution context, including environment variables, temporary file storage, and the network. A compromised dependency in a Lambda function has the same egress permissions as the function itself.

Insider Exfiltration: The Trusted Channel

The most statistically significant exfiltration vector is also the hardest to architect against. IBM’s 2025 Cost of a Data Breach report found that insider threats (malicious and negligent combined) accounted for 35% of breaches, with an average cost of $4.99 million per incident — the highest of any attack vector.

Insiders do not need to exploit vulnerabilities. They have credentials. They have authorized access. Their data transfers are, by definition, authorized — until the moment they redirect data to an unauthorized destination. The difference between a database administrator running a backup (authorized) and the same administrator exporting the same data to a personal cloud storage account (exfiltration) is invisible at the network layer.

Architectural Approaches to Egress Control

Network-Level Egress Filtering

The baseline approach: restrict outbound traffic to known-good destinations at the network layer.

AWS implementation. Security groups provide stateful outbound filtering by IP and port. NACLs provide stateless filtering at the subnet level. AWS Network Firewall provides FQDN-based egress filtering (inspecting the SNI field in TLS Client Hello packets to determine the destination domain without decrypting the traffic). AWS PrivateLink eliminates public internet egress for AWS service-to-service communication entirely.

Limitations. FQDN filtering relies on SNI inspection, which is undermined by Encrypted Client Hello (ECH) — a TLS extension, now supported in Chrome and Firefox, that encrypts the SNI field. Once ECH is widely deployed, FQDN-based egress filtering becomes blind without a TLS-terminating proxy. Domain fronting — using a trusted domain’s CDN to relay traffic to an attacker’s origin — bypasses FQDN filtering entirely by presenting a legitimate SNI while routing the HTTP request to a different backend.

Application-Level Egress Control

Instead of filtering at the network, restrict egress at the application runtime.

Service mesh. Istio, Linkerd, and Consul Connect enforce egress policies through sidecar proxies. All outbound traffic from a pod passes through the sidecar, which can enforce destination allow-lists, rate limits, and payload inspection. The sidecar operates at Layer 7, making it resistant to IP-based evasion techniques.

Sandbox restriction. Runtime sandboxes like gVisor, Firecracker, and V8 isolates can restrict the network capabilities available to application code. A V8 isolate has no raw socket access — it can only make HTTP requests through the runtime’s fetch API, which can be intercepted, logged, and restricted.

WASM-based restriction. WebAssembly modules execute in a sandboxed environment with no ambient capabilities. Network access must be explicitly granted through imported functions. A WASM module processing sensitive data can be granted zero network capability — it processes data and returns results through its exported interface without any ability to make outbound connections.

Data-Centric Egress Control

Rather than controlling where data can go, control what the data contains — or whether the data exists at all.

Tokenization. Replace sensitive data values with non-reversible tokens before they enter the cloud. The cloud workload processes tokens, not real data. Even if exfiltrated, the tokens are meaningless without the tokenization mapping, which remains on-premises.

Format-preserving encryption. Encrypt data while maintaining its format (a 16-digit number remains a 16-digit number). The cloud workload can process encrypted values without decryption for many operations — sorting, deduplication, range queries — reducing the blast radius of exfiltration.

Zero persistence. Eliminate the exfiltration target entirely. If data exists only in volatile memory for the duration of a computation and is cryptographically shredded upon completion, the exfiltration window shrinks from “indefinite” (data at rest in a database) to “milliseconds” (data in flight during processing). This does not eliminate exfiltration risk during processing — a compromised workload can still exfiltrate data from memory in real time — but it eliminates the 99% of breach scenarios where the attacker exfiltrates data at rest.

The Zero-Persistence Advantage

Consider the attack surface of a traditional cloud application versus a zero-persistence architecture:

Traditional architecture. Data is stored in a database (Amazon RDS, Google Cloud SQL). The database persists data to disk, replicates it to standby instances, backs it up to object storage. The data exists in the primary database, the replica, the backup, the WAL archive, potentially in a data warehouse, in analytics pipelines, in log files that capture query patterns. Each copy is an exfiltration target. Each backup is a liability. The attacker has months or years to find and exploit a single egress path.

Zero-persistence architecture. Data exists only in the memory of an ephemeral compute environment for the duration of a request. When the request completes, the memory is zeroed and the encryption keys are destroyed. There is no database to exfiltrate. There are no backups to steal. There are no logs to mine. The exfiltration window is the request duration — typically 100-2,000 ms.

This does not make exfiltration impossible. A compromised runtime can still capture and transmit data during the processing window. But the economics of attack change fundamentally. The attacker cannot perform a one-time exfiltration of a database dump. They must maintain persistent access to the runtime and exfiltrate data request-by-request, in real time, while avoiding detection. The throughput drops from “gigabytes per hour” (database exfiltration) to “kilobytes per request” (memory-level extraction during processing). The attacker must also defeat the egress restrictions of the runtime environment — and if that environment is a V8 isolate with no raw socket access, the available egress channels are severely constrained.

Egress Monitoring and Detection

Prevention is necessary but insufficient. Detection systems provide the second layer.

Network Flow Analysis

VPC Flow Logs (AWS), NSG Flow Logs (Azure), and VPC Flow Logs (Google Cloud) capture connection metadata for all traffic crossing network boundaries. Anomaly detection models trained on baseline traffic patterns can identify unusual egress volumes, new destination IPs, connections to known-malicious infrastructure, and traffic at unusual times.

The signal-to-noise ratio is the challenge. A large cloud deployment generates billions of flow log entries per day. A 50 KB DNS tunnel operating over 24 hours produces negligible anomalies in aggregate metrics. Machine learning-based detection (Lacework, Orca Security, Wiz) reduces false positive rates but cannot guarantee detection of low-and-slow exfiltration.

Runtime Behavioral Analysis

Falco, Tracee, and Tetragon (eBPF-based) monitor system call behavior inside containers and VMs in real time. They detect anomalous process execution (a web server spawning a shell), unexpected network connections (a database connecting to an external IP), and file access patterns inconsistent with the workload profile.

eBPF-based monitoring operates at the kernel level with minimal performance overhead (typically 1-3% CPU impact). For workloads running in zero-trust environments, runtime behavioral analysis is the most effective detection mechanism for in-progress exfiltration, because it observes the workload’s actual behavior rather than its declared intentions.

Cryptographic Egress Control

The most rigorous approach: ensure that all data leaving the system is encrypted with keys controlled by the data owner, and that the decryption keys are never available in the same environment as the egress channel.

In this model, the compute environment processes encrypted data using techniques like client-side encryption, secure enclaves, or confidential computing hardware. The cleartext exists only inside the hardware trust boundary. Egress traffic from the compute environment contains only ciphertext. Even a fully compromised network stack exfiltrates only encrypted data — useless without the decryption key, which resides on the client device.

This is the model that AES-256-GCM client-side encryption implements: the server never possesses the decryption key. The server processes ciphertext, returns ciphertext, and the only entity that can recover the plaintext is the client that holds the key. Exfiltration from the server yields encrypted data that the attacker cannot decrypt.

Case Studies in Egress Failure

Capital One (2019)

A former AWS employee exploited a misconfigured WAF to gain access to Capital One’s AWS environment. The exfiltration path: a server-side request forgery (SSRF) attack against the EC2 instance metadata service, which yielded IAM role credentials. Those credentials provided access to S3 buckets containing 106 million customer records. The data was exfiltrated directly from S3 to an external server.

The egress path was S3 → internet. No egress filtering was in place on the S3 bucket. No anomaly detection flagged the large outbound transfer. The breach was discovered four months later when the attacker posted about it on social media.

SolarWinds (2020)

The Sunburst backdoor, embedded in SolarWinds Orion update packages, exfiltrated data through DNS queries and HTTPS callbacks to command-and-control infrastructure hosted on domains designed to mimic legitimate cloud services. The exfiltration operated within the normal traffic patterns of network monitoring software — which, by design, needs to communicate with external services.

DLP would not have detected the exfiltration because the data was encrypted and fragmented. Network anomaly detection did not flag the traffic because Orion’s normal behavior includes substantial outbound communication. The attacker leveraged the trusted position of the monitoring software to create an egress channel indistinguishable from legitimate traffic.

Snowflake Customer Breaches (2024)

In 2024, attackers used stolen credentials to access Snowflake customer accounts and exfiltrate data from cloud data warehouses. Over 165 organizations were affected. The attack was trivially simple: the credentials were obtained from infostealer malware on employee devices, the Snowflake accounts did not require multi-factor authentication, and the data warehouses contained unencrypted customer data. The exfiltration path was the Snowflake API itself — a fully authorized egress channel used with stolen authorization.

No network-level control, no DLP system, and no egress filter could have prevented this. The attacker used legitimate credentials through legitimate APIs to access legitimately stored data. The only defense would have been: the data should not have been stored in cleartext, or the data should not have been stored at all.

The Stealth Cloud Perspective

Stealth Cloud’s approach to egress security starts from a different premise than the industry standard. Rather than building increasingly sophisticated controls to prevent the exfiltration of data that has already been stored, we eliminate the stored data that an attacker would exfiltrate.

The architecture is zero-persistence by design. User prompts arrive at the edge encrypted with AES-256-GCM keys held exclusively by the client. The decrypted plaintext exists only in the V8 isolate’s volatile memory for the duration of the request. The PII stripping engine tokenizes identifiable data before it reaches the LLM provider, ensuring that even the egress to the AI inference endpoint carries sanitized content. When the request completes, the isolate’s memory is cleared and the session keys are destroyed.

The egress surface is reduced to a single, well-defined channel: the proxy request from the edge worker to the LLM provider, carrying a PII-stripped, context-limited prompt. No database stores historical conversations. No log files capture query patterns. No backup system accumulates weeks of user data waiting for an attacker to discover.

This does not make us immune to all exfiltration vectors — a compromised edge runtime could theoretically exfiltrate data during the processing window. But the attack economics are radically different from the industry baseline. There is no accumulated dataset. There are no credentials to steal that unlock months of stored conversations. There is only the current request, in the current moment, and then nothing. The exfiltration window is measured in milliseconds, not months. And the attackable surface — a V8 isolate with no filesystem, no raw sockets, and no persistent state — offers the attacker almost nothing to work with. The best egress security is having nothing worth stealing.