> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aviatrix.com/llms.txt
> Use this file to discover all available pages before exploring further.
# AI Agent Workload Containment
> How Aviatrix DCF closes the network security gap for AI agent workloads: threat model, east-west containment, selective TLS inspection, and the business case for default-deny enforcement across any agent platform or framework.
AI agents are autonomous by design. They decide which APIs to call, which tools
to invoke, and what data to pass between them. They do all of this with
unrestricted outbound internet access unless a network control explicitly limits
it. Whether agents run on a managed cloud platform, a self-hosted orchestration
framework, or a containerized custom runtime, that default-allow posture is the
starting state. Closing it is the operator's responsibility, not the platform's.
**Aviatrix AgentGuard** is the network enforcement plane for AI agent
workloads. It applies DCF default-deny containment, SmartGroup East-West
isolation, and WebGroup egress allow-lists consistently across every agent
platform and framework, closing the network security gap that managed platforms
and self-hosted runtimes leave open by default.
## Business Challenge
AI agents operate differently from traditional application workloads. A
conventional service calls a fixed set of upstream dependencies; its outbound
traffic is deterministic and auditable. An AI agent's outbound traffic is
decided at runtime by the model, based on input the model received. That input
can be crafted by an attacker. Prompt injection, compromised tool dependencies,
and supply chain attacks against model providers or MCP servers all exploit the
same weakness: the agent's autonomous decision-making gets redirected to serve
the attacker's intent, not the operator's.
The network security gap is structural, and it applies across every agent
deployment model. Managed platforms route agent egress through
provider-controlled infrastructure with no in-line enforcement point the
enterprise security stack can observe. Self-hosted frameworks running on
Kubernetes or VMs start with the default-allow posture of the environment. In
both cases, the shared responsibility model covers the platform or runtime. It
does not cover what the agent inside it chooses to call. An agent that executes
a prompt injection and attempts to exfiltrate data to an attacker-controlled
endpoint is operating within the platform's design. The platform forwards that
traffic without restriction.
**March 2026: LiteLLM supply chain compromise.** The [LiteLLM supply chain
attack](https://www.theregister.com/2026/03/24/trivy_compromise_litellm/)
compromised four widely deployed AI tooling packages across five package
registries in twelve days. LiteLLM operates under the same trust model as AI
agents: trusted code making real outbound API calls in trusted pipelines. One
engineer added four command-and-control IPs to a DCF Global IP Blocklist. That
single update reached every gateway in the environment before the compromised
packages could communicate. Zero credentials were exfiltrated. Without a
network enforcement point, the outcome is a detection problem after the fact,
not a prevention problem before it.
Two distinct threat vectors apply to AI agent workloads, regardless of how or
where they are deployed.
**Egress to the internet.** An agent making tool calls, invoking MCP servers, or
running a code interpreter does so over outbound connections that are
indistinguishable from legitimate traffic at the application layer. A
compromised dependency or an injected prompt redirects those connections to
attacker infrastructure. Without an enforcement point, the first signal is a
detection event after exfiltration has already occurred.
**Lateral movement to adjacent workloads.** AI agent spokes in an enterprise
transit fabric sit alongside other workload spokes: internal APIs, data
platforms, finance and HR systems. A compromised agent that can reach the open
internet can also reach adjacent spokes unless East-West policy explicitly
prevents it. The blast radius extends not just outward to the internet, but
inward to the rest of the enterprise.
Supply chain attacks add a third dimension that simple FQDN filtering cannot
address. A compromised dependency can redirect the agent to a malicious path on
a sanctioned host. Both `raw.githubusercontent.com/legitimate-path` and
`raw.githubusercontent.com/attacker-path` present the same TLS endpoint;
SNI-based filtering cannot tell them apart. Catching this class of attack
requires decrypting the connection to inspect the URL path, which means
selective TLS decryption scoped to the supply-chain risk surface.
## Business Case for AI Agent Containment
### Risk Mitigation
Without an enforcement point in the agent's egress path, the blast radius of any
compromise extends to every destination the agent can reach (the entire internet
by default). Containment inverts this: the default is deny, and only explicitly
declared destinations are reachable. When prevention fails at the application
layer, the network boundary determines whether a compromised agent exfiltrates
data or fails to open a socket.
The egress risk does not exist in isolation. AI agent spokes in an enterprise
transit fabric sit alongside other workload spokes: internal APIs, data
platforms, finance and HR systems. A compromised agent that can reach the open
internet can also pivot to those adjacent workloads unless East-West policy
explicitly prevents it. SmartGroup deny rules between the agent spoke and every
other spoke in the fabric contain the lateral movement risk to the agent
boundary. The blast radius stops at the spoke, not at the edge of the
enterprise.
DCF selective TLS decryption closes the supply-chain gap directly. Tool-call
egress is decrypted and inspected at the URL-path level. Platform control-plane
traffic is explicitly excluded from decryption to preserve runtime
compatibility. The decryption surface is scoped to the highest-risk traffic
only: not a blanket intercept, but a targeted capability applied where passive
filtering falls short.
### Regulatory and Compliance
AI agents handling regulated data create a concrete compliance exposure when
their egress is unrestricted. The same audit requirements that apply to other
workloads apply here, with the added complexity that agent traffic is harder to
characterize than traditional application traffic.
| Framework | Requirement | How Aviatrix addresses it |
| ----------------- | ------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **SOC 2 Type II** | CC6.6, CC6.7: logical access controls restricting communication to authorized destinations | Default-deny containment enforces allow-lists at the network layer; per-connection logs in CoPilot provide the continuous audit evidence the control is operating |
| **HIPAA** | ยง164.312(e)(1): transmission security for ePHI | Workload-scoped containment limits which destinations an agent handling health data can reach; TLS inspection provides payload-level visibility on tool-call traffic |
| **PCI-DSS v4** | Requirement 1.3: network access controls between trusted and untrusted networks | Spoke gateway enforcement at the VPC/VNet boundary; per-connection logs covering all agent egress, inbound and outbound |
| **FedRAMP** | SC-7: boundary protection with continuous monitoring | DCF enforces boundary protection at the spoke gateway; CoPilot provides the continuous monitoring and per-connection log evidence required for annual authorization |
### Operational Excellence
**Policy as code, deployed with the agent.** Aviatrix DCF policy is
Terraform-native. The WebGroup allow-list for an agent's permitted tool
destinations lives in the same repository as the agent configuration and deploys
in the same pipeline run. When an agent adds a new tool endpoint or changes its
model provider, the network policy update is a pull request, not a separate
change ticket to a different team.
**East-West containment across the transit fabric.** SmartGroups define
identity-aware East-West policy between the agent spoke and adjacent workload
spokes. A compromised agent cannot pivot to internal APIs, data platforms, or
adjacent cloud workloads unless those paths are explicitly declared permitted.
The default posture between the agent spoke and every other spoke is mutual
deny.
**Selective TLS decryption without operational risk.** DCF applies decryption
per-rule, scoped to a specific destination SmartGroup. Platform control-plane
endpoints are explicitly excluded from decryption, preserving
certificate-pinning behavior and runtime compatibility regardless of which
platform or framework the agent runs on. The decryption surface covers only the
external tool-call traffic where supply-chain risk is highest.
**Unified visibility across platforms.** The same CoPilot dashboard governs
agent egress whether agents run on managed cloud platforms, self-hosted
orchestration frameworks, or containerized custom runtimes. Security teams can
answer "what can any of our agents reach?" from a single console, without
maintaining separate policy engines per platform.
**Rapid policy propagation.** When a new indicator of compromise emerges, an
updated containment policy reaches every gateway in the environment before the
threat can communicate, with no per-region rollout and no per-platform change
window.
### Competitive Differentiation
Enterprises do not end up running a single agent on a single platform. The
operational reality is concurrent deployment across managed platforms such as
AWS Bedrock AgentCore and Microsoft Foundry, self-hosted orchestration
frameworks like LangGraph, AutoGen, and CrewAI, and new platforms that will be
adopted next quarter. Each has its own insertion model, service endpoint
requirements, and policy syntax. Managing agent network security with
per-platform firewalls means a different policy engine for every agent type, no
unified audit trail, and no consistent enforcement primitive across the estate.
Aviatrix brings the same unification to AI agent network security that it
brought to multicloud networking: one control plane, one policy model, and one
audit log across every agent platform and framework. SmartGroups and WebGroups
apply consistently whether the agent runs on a managed cloud platform or a
self-hosted runtime in a Kubernetes cluster.
[Gartner projects that 40% of enterprise software will embed agentic AI by 2028](https://www.gartner.com/en/newsroom/press-releases/2024-10-21-gartner-says-more-than-40-percent-of-agentic-ai-will-be-embedded-in-enterprise-software-tools-by-2028).
Organizations that standardize on Aviatrix as the agent enforcement plane now
are positioned to extend that policy consistently as the agent estate grows,
rather than re-architecting security for each new platform.
## Key Components
Default-deny enforcement at the spoke gateway in the agent VPC or VNet. All
agent egress (tool calls, MCP server connections, model provider traffic,
code interpreter outbound) is intercepted and evaluated against declared
policy before any packet leaves the network boundary.
Identity-aware source and destination matching keyed to agent workload
primitives: subnet CIDRs for agent instances, cloud provider Service Tags
for platform endpoints, and FQDN patterns. SmartGroups define the egress
source and the East-West boundaries between the agent spoke and adjacent
workload spokes in the transit fabric.
FQDN-based destination filters for permitted tool-call targets: model
provider endpoints, sanctioned MCP servers, and approved REST APIs.
WebGroups enforce the agent's declared egress allow-list, and serve as the
target scope for DCF selective TLS decryption for URL-path enforcement on
supply-chain-risk hosts.
Centralized dashboard for all agent containment policies, real-time traffic
flows, and per-connection logs across every agent spoke, cloud, and
platform. Security teams get continuous visibility into what every agent can
reach and has actually reached, without querying individual VPCs or
correlating logs across cloud consoles.
## Implementation Guides
The containment pattern is the same regardless of the agent platform: deploy a
spoke gateway in the agent VPC or VNet, route agent egress through it, and
enforce default-deny DCF policy scoped to that workload.
* AWS Bedrock AgentCore:
spoke gateway insertion in the AgentCore VPC, AWS route table enforcement, IAM
guardrails preventing PUBLIC-mode runtimes, and DCF policy with selective TLS
decryption for supply-chain risk scenarios.
* Microsoft Foundry: With Transit:
Foundry BYOVNet spoke attached to an existing Aviatrix Enterprise Transit,
with UDR enforcement, ACA runtime exclusions, selective TLS inspection, and
East-West containment across the transit fabric.
* Microsoft Foundry: Standalone:
minimum viable AgentGuard footprint for Foundry: a standalone spoke gateway
in the Foundry VNet with no Aviatrix Transit required. A natural on-ramp that
can be extended to the Transit topology later.
* Self-Hosted Agents on Kubernetes:
pod-scoped containment policy for LangGraph, AutoGen, CrewAI, and custom agent
runtimes deployed as Kubernetes workloads.