AI agents do not create risk only when they generate the wrong answer. They create operational risk when they turn that answer into an outbound action: calling an API, querying a search service, downloading content, opening a ticket, sending a message, or changing a production system.
Most enterprise controls still focus on the agent’s intent. Prompts, guardrails, and model policies describe what the agent should do. They do not guarantee which destinations the workload can reach, which request was sent, or whether an unapproved path was used.
That gap calls for an agent egress boundary: a platform-enforced control through which every external tool call must pass, combined with traceable evidence that links the call to the originating agent interaction.
Guardrails are necessary, but they are not enforcement
Prompt-level guardrails are useful for shaping behavior. They can tell an agent not to disclose sensitive information, not to call unknown services, or to request human approval before a consequential action. But those controls operate inside the reasoning path they are intended to constrain.
Production systems need an independent layer. If an agent is compromised through prompt injection, a poisoned tool response, a vulnerable dependency, or a simple implementation mistake, the network should still prevent access to destinations outside the approved contract.
The distinction is familiar from other areas of security:
- application authorization expresses intended access;
- network enforcement limits reachable destinations;
- observability records what actually happened;
- human approval controls high-impact exceptions.
No single layer is sufficient. Together, they create defense in depth.
The platform contract
An agent egress boundary should answer four questions for every outbound request:
- Who initiated it? Identify the workload, agent, tenant, and user or workflow context.
- Where is it going? Resolve the approved destination, protocol, port, and application-level route.
- Was it allowed? Evaluate the call against a versioned policy rather than an application convention.
- What evidence remains? Record a traceable decision without leaking secrets or sensitive payloads.
This turns outbound connectivity into a platform contract. An agent receives only the network access required by its tools, while the platform provides a consistent control and evidence plane.
A practical cloud-native pattern
A recent CNCF implementation demonstrates the core idea using NGINX, Kubernetes, and OpenTelemetry. NGINX acts as both the inbound reverse proxy and the outbound forward proxy for an agent workload. Network rules drop direct egress so the proxy becomes the only approved path. The NGINX OpenTelemetry module emits a span for each request, and an OpenTelemetry Collector forwards the evidence to observability or security systems.
The important principle is architectural: the boundary is not a library the agent may choose to call. It is the only network path available.
A production-oriented request flow can look like this:
- A user or system invokes the agent through an authenticated gateway.
- The gateway propagates a trace context and workload identity.
- The agent selects a tool and issues an outbound request.
- Kubernetes egress controls permit traffic only to the designated proxy.
- The proxy evaluates destination, protocol, identity, and policy.
- Allowed traffic is forwarded; denied traffic returns a controlled error.
- OpenTelemetry records the decision and correlates it with the originating interaction.
The result is a chain of evidence from user request to external side effect.
Why Kubernetes NetworkPolicy alone is not enough
Kubernetes NetworkPolicy is a strong foundation. It can isolate workloads and restrict egress by IP block, port, and selected peers, provided the cluster’s network plugin enforces the policy. A default-deny egress policy should be the starting point for sensitive agent workloads.
However, many agent tools call dynamic external services over HTTPS. IP addresses change, destinations share infrastructure, and business rules are usually expressed in terms of domains, API routes, methods, or tool identities rather than static addresses.
That is why a layered design is useful:
- NetworkPolicy or equivalent CNI controls ensure the workload can only reach the approved proxy and essential platform services.
- The egress proxy enforces destination and application-aware rules.
- Workload identity distinguishes agents and tenants without relying only on source IP.
- OpenTelemetry provides correlated evidence for operations, security, and audit.
The network layer prevents bypass. The proxy layer understands enough context to make a useful decision.
Policy should follow the tool contract
Allowing an agent to reach an entire domain is often broader than the tool definition requires. A better policy starts with the declared tool contract.
For example, an incident-analysis agent may need to:
- read selected observability APIs;
- create, but not delete, incident tickets;
- query a controlled knowledge source;
- send notifications only to an approved channel;
- never call arbitrary internet destinations.
The platform can translate that contract into an egress policy covering destination, method, route, identity, rate, and approval requirements. High-risk actions can be routed through a separate approval service rather than granted as normal network access.
This also creates a cleaner ownership model. Domain teams define which tools are necessary. Security teams define control requirements. Platform teams provide the reusable enforcement mechanism.
Observability must produce evidence, not surveillance
OpenTelemetry is well suited to correlating inbound interactions with outbound HTTP client activity. Standard HTTP span conventions provide consistent attributes for requests and responses, while trace context links multiple services into one transaction.
But recording everything is not automatically safe. Agent traffic can include credentials, personal data, customer information, prompts, and tool payloads. The audit plane therefore needs its own policy.
Useful evidence
- trace and request identifiers;
- agent, workload, tenant, and tool identity;
- policy version and allow or deny decision;
- destination service and approved route classification;
- HTTP method and status class;
- latency, retries, and byte counts;
- model or agent configuration version;
- human approval reference where required.
Data to avoid by default
- authorization headers and API keys;
- full request or response bodies;
- raw prompts containing confidential data;
- URL query parameters unless explicitly sanitized;
- unbounded high-cardinality attributes.
The purpose is to prove and investigate behavior, not to create a second uncontrolled copy of sensitive data.
Controls that make the boundary credible
A proxy is only a boundary when bypass is demonstrably difficult. Platform teams should validate at least the following controls:
- Default-deny egress: direct external connectivity fails.
- DNS control: workloads cannot switch to an unmonitored resolver or exploit unexpected resolution paths.
- IPv4 and IPv6 parity: policy applies consistently to both address families.
- Protocol coverage: non-HTTP tools, WebSockets, streaming APIs, and message protocols have explicit handling.
- TLS design: the organization decides where TLS terminates and what metadata can be inspected without undermining privacy.
- Identity: decisions rely on authenticated workload identity, not only mutable labels or network location.
- Fail-closed behavior: proxy, collector, or policy failures do not silently open direct access.
- High availability: the control plane does not become an avoidable single point of failure.
These details determine whether the pattern is an architectural control or merely a useful demonstration.
Operational signals for platform teams
Once all tool traffic crosses the boundary, the same telemetry can improve reliability and cost control.
Useful service-level indicators include:
- allowed and denied tool calls by agent and policy version;
- unexpected destinations or repeated policy violations;
- external dependency latency and error rates;
- retry storms and rate-limit responses;
- egress volume and estimated third-party API cost;
- calls that required human approval;
- trace gaps where an outbound action lacks an originating interaction.
This gives security and operations teams a shared view. The same denied request may indicate an attack, an outdated policy, or a legitimate new tool requirement.
A phased adoption plan
- Inventory agent egress. Identify destinations, protocols, credentials, and business owners for each production tool.
- Introduce observation first. Capture sanitized outbound traces to understand real behavior before enforcing a narrow policy.
- Define tool-level contracts. Document approved destinations and actions rather than granting general internet access.
- Apply default deny. Force a low-risk agent through the proxy and prove that direct egress fails.
- Add policy-as-code. Version destination rules, ownership, exceptions, and approval conditions in Git.
- Connect the audit plane. Send sanitized OpenTelemetry data to the organization’s observability and SIEM platforms.
- Test failure modes. Validate DNS bypass, IPv6, proxy outage, collector outage, policy rollback, and certificate rotation.
- Scale by platform product. Offer the boundary as a reusable golden-path capability rather than a custom design for every agent.
Conclusion
Enterprises should not have to trust that an AI agent will respect its network boundaries. Those boundaries should be enforced by the platform and evidenced through telemetry.
NGINX, Kubernetes, and OpenTelemetry show that the core pattern can be built from mature cloud-native components: default-deny connectivity, an application-aware egress proxy, and correlated traces. The exact implementation will vary, but the platform contract should remain consistent.
Every agent tool call should be attributable, policy-checked, observable, and reversible where the downstream system allows it. That is the difference between experimenting with autonomous software and operating it responsibly.