AI Agent Workload Containment

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. 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.

​

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. 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

​

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.