I wrote about a failure mode where everything works as configured, yet an AI agent still exfiltrates data. The chain is simple: attacker-controlled text appears in a support ticket, the agent makes a legitimate tool call, and the tool sends data over HTTPS to an attacker-controlled domain. There is no vulnerability, stolen credential, or compromised process—the agent is operating within its permissions.
Traditional network policies operate at layers 3 and 4, so allowing outbound TCP 443 often means allowing access to nearly any internet destination. IP-based allowlists are especially weak when legitimate services and attacker-controlled domains share rotating CDN address ranges. Blocking all HTTPS would also prevent the agent from reaching required model and API endpoints.
Model-based guardrails are useful but probabilistic. An attacker can retry until one prompt succeeds, while the resulting action may be irreversible. A stronger baseline is deterministic egress containment: give each workload its own identity, enforce domain-aware policy using information such as SNI, and default-deny destinations that have not been explicitly declared. This still does not prevent exfiltration through an approved destination or DNS tunneling, but it reduces the reachable set and makes suspicious behavior easier to detect.
For those running MCP-style workloads, can you identify every external domain each server needs to reach? Has anyone deployed default-deny, domain-aware egress, and what broke first?
5 Answers
A forward proxy can provide domain-aware filtering, logging, and sometimes TLS inspection. That is a reasonable design, but it should not be the only control. A misconfigured or prompt-injected client may bypass proxy settings, so the workload should be allowed to reach only the proxy at the network layer. The proxy then becomes the domain-level enforcement point, while the lower-level policy acts as the funnel.
This is fundamentally different from parameterized SQL or a kernel/userspace boundary. Those systems have a structural separation between instructions and data. An LLM receives both through the same token stream, so prompt sanitization and instruction hierarchies remain probabilistic classifiers rather than hard enforcement. Until models have a reliable structural boundary, permissions and egress controls have to exist outside the model.
Exactly. Egress controls do not solve prompt injection itself; they limit what a successful injection can reach. Container hardening, secret isolation, action auditing, least privilege, and workload-specific network policy all reduce different parts of the blast radius.
A centralized corporate firewall helps, but attribution matters. If all workloads are NATed behind one gateway address, the firewall sees the whole cluster as one client. A whitelist built from that traffic becomes the union of every workload's requirements, so the most sensitive agent inherits everyone else's destinations. Preserve per-workload identity until policy evaluation, whether the enforcement point is a gateway or the cluster network.
The bigger issue is the architecture. An agent that can read untrusted support content and also invoke operational tools has too many responsibilities. It should not need broad access to cluster systems, and untrusted inputs should be isolated from actions that affect production. Separation of concerns, limited credentials, approval gates, and a narrow tool set should come before relying on network controls.
That separation is absolutely useful, but the example does not require Kubernetes write access or a stolen secret. The agent only needs permission to read tickets and make outbound requests. Any external text—tickets, email, documents, or web pages—should be treated as attacker-controlled, so the network boundary is still needed even after reducing the agent's privileges.
Domain-aware policies in Cilium or similar systems can enforce this model. We deployed cluster-wide default deny and permitted only the DNS, internal services, and specific external domains each workload required. The first things to break were applications that intentionally fetch arbitrary internet content, such as feed readers and importers. Moving those functions into separate services made the policy manageable and kept untrusted retrieval away from sensitive workloads.
That is the important distinction: a service designed to fetch any URL cannot have a meaningful external allowlist. It needs isolation, separate credentials, and monitoring rather than being placed in the same workload as an agent handling sensitive data.
TLS interception also comes with costs: certificates must be trusted inside workloads, certificate pinning can break, and the proxy temporarily handles sensitive plaintext. It can work in some environments, but it needs careful operational and privacy review.