Skip to content
DineshKumar Sarangapani
All writing

Network Segmentation for AI Systems: Containing Blast Radiuses in Agent Architectures

Why flat virtual networks are dangerous for AI systems, and how to design isolated network zones to prevent SSRF and data exfiltration.

CloudArchitectureNetworkingSecurity

When teams build an initial AI system, they usually launch all their components into a single virtual network.

The orchestrator, vector databases, cache clusters, and background workers share the same private subnets. Everything communicates over internal IP addresses without friction. Routing is simple, and there is no inter-network peering to manage.

For traditional internal apps, this flat topology is common. For agentic AI systems, it creates a serious security risk.

Autonomous AI agents do something standard microservices rarely do: they dynamically construct network requests, invoke external tools, and fetch content from untrusted endpoints based on model reasoning.

If an agent runs in a flat network and encounters prompt injection or malicious input, an attacker can use the agent as an internal proxy to explore your private infrastructure.

This post explains the network threat model for AI agents, how a zoned network design contains blast radiuses, how it works in production, and what to watch out for.

The Problem: The Agentic Threat Model

In traditional software, network requests are deterministic. Code specifies exact hosts, ports, and payload structures.

AI agents are non-deterministic. A user prompt or a retrieved document can instruct an agent to call an HTTP tool with arbitrary parameters.

This opens the door to Server-Side Request Forgery (SSRF):

  1. An agent retrieves an external document or processes user input containing hidden instructions.
  2. The instructions direct the agent to fetch an internal URL (such as a cloud instance metadata service or an internal database management port).
  3. The agent executes the request using its host identity.

In a flat network, the agent shares private network routes with critical databases, internal credentials, and other services. Once an agent is compromised, the attacker inherits the agent’s internal network access.

The Idea: Zoned Network Micro-Perimeters

To protect against this, production AI platforms should adopt a zoned network architecture. Instead of placing everything together, components are grouped by their trust level and access requirements:

  • The Execution Zone: Hosts the core agent orchestration engine and ephemeral session state. It can query vector indexes and send prompts to the model gateway, but has no direct internet egress and no route to raw backend infrastructure.
  • The Protected Zone: Houses sensitive vector embeddings, semantic indexes, and reference datasets. Inbound access is strictly restricted to authorized queries from the execution zone. It has zero public internet access.
  • The Sandboxed Zone: Dedicated to parsing untrusted external files (PDFs, spreadsheets, HTML). Document parsing is historically prone to memory-safety bugs and zero-day parser vulnerabilities. By running parsers in an isolated network enclave, untrusted parser code never runs in the same network space as operational agents.
  • The Egress Zone: All external communication (calling model APIs or executing approved web tools) flows through an inspected egress layer with stateful firewalls.

How It Worked Well

  1. Strict Blast Radius Containment: If a prompt injection tricks an agent into attempting an unauthorized network scan, the network route simply does not exist. The packet is dropped at the virtual network boundary before it can reach internal databases.
  2. True Defense-in-Depth: Application-level input validation (such as URL regexes) can be bypassed by DNS rebinding, alternative IP encodings, or HTTP redirect chains. Enforcing drop rules at the network firewall guarantees that traffic to private IP spaces and metadata services is blocked regardless of what the application code does.
  3. Isolated File Ingestion: Separating document parsing into a sandboxed network prevented vulnerabilities in third-party document processing libraries from compromising the core agent runtime or accessing user session stores.
  4. Governed Managed Services: Using private interface endpoints (such as PrivateLink) kept database and storage traffic entirely on the cloud provider’s private physical backbone, eliminating exposure to public internet routing.

What to Watch Out For

  1. DNS Rebinding Attacks: An attacker can provide a domain name that resolves to a public IP during initial application checks, but points to a private internal IP by the time the agent’s HTTP client connects. Ensure your egress layer resolves DNS and validates the destination IP at connection time.
  2. Hidden HTTP Redirect Chains: A public URL may return an HTTP 302 redirect pointing to an internal IP or cloud metadata service. Ensure your HTTP client libraries or egress firewalls inspect redirect targets before following them.
  3. Cross-Zone Network Costs: Moving traffic across peered virtual networks or transit gateways incurs cloud data transfer fees. High-volume document embedding pipelines can generate terabytes of data. Keep tightly coupled services in the same region and optimize payload transfers to avoid unexpected network bills.
  4. Operational Overhead of Peering: Managing multiple isolated virtual networks with security groups and route tables manually is unsustainable. Define all networking zones in Infrastructure as Code (IaC) so that environments remain reproducible and auditable across development, staging, and production.