Egress control, restricting where an agent's outbound requests can actually go, deserves specific, dedicated attention beyond general network security, because it's the layer that directly closes the data exfiltration path covered throughout prompt injection guidance: a manipulated model that decides to send sensitive data somewhere it shouldn't has no path to actually pull that off if egress control keeps the outbound request from ever reaching an unauthorized destination.
Egress control is a distinct concern from inbound access control
Most security attention naturally focuses on inbound access, who can reach the agent and what they can ask it to do. Egress control addresses a different question: once the agent decides to send something outbound, through a tool call, an email, an API request, where can that outbound request actually go. This distinction matters because an agent can have perfectly correct inbound authorization while still having unrestricted outbound reach, which is exactly the combination that makes exfiltration through a manipulated decision possible.
Define an explicit allowlist of legitimate outbound destinations
For each agent and each of its tools with outbound capability, define an explicit allowlist of legitimate destinations the tool actually needs to reach for its intended function, rather than letting outbound requests go to any destination the model happens to specify. A tool that sends notifications to a specific internal service, say, should be restricted to that specific service's known endpoint, not free to send to an arbitrary destination the model's generated parameters might specify.
Treat model-specified destinations as untrusted input
If a tool's design lets the model specify or influence the outbound destination directly, treat that specified value as untrusted input requiring validation against the allowlist, following the schema validation discussion elsewhere, rather than trusting the model's generated destination value implicitly. A tool letting the model specify an arbitrary URL to send data to is a direct exfiltration path if the model ever gets successfully manipulated, and validating any model-influenced destination against a known-good allowlist closes this specific gap.
Apply egress control at multiple layers for redundancy
Implement egress restriction both at the application layer, within the tool's own logic, and at the network layer, through firewall or proxy rules restricting what destinations the underlying infrastructure can reach at all, following the defense-in-depth principle running throughout this content series. This redundancy means a gap in one layer's implementation doesn't hand over unrestricted exfiltration capability if the other layer's restriction still holds.
Monitor and alert on egress attempts to non-allowlisted destinations
Log every attempt to reach a destination outside the defined allowlist, even if the attempt got successfully blocked, and monitor this signal specifically, following the abuse and anomaly monitoring guidance covered elsewhere. A pattern of blocked attempts to reach unusual destinations is a strong, specific signal of either an active manipulation attempt or a misconfigured tool, and it deserves prompt investigation, not treatment as routine, successfully-handled noise.
Consider volume and content-based egress limits, not only destination
Beyond restricting which destinations are reachable, consider limits on the volume and nature of data sent to any single outbound destination within a given time window, and where feasible, apply content-based inspection to outbound data specifically checking for patterns consistent with sensitive data categories, following the exfiltration detection discussion in earlier prompt injection guidance. This provides a supplementary layer of protection even for legitimate, allowlisted destinations, in case a legitimate destination gets used in an unexpectedly large or sensitive way.
Review allowlists periodically as agent capabilities evolve
As an agent gains new tools or its existing tools' functionality expands, revisit the egress allowlist to confirm it still reflects only the destinations genuinely needed, rather than letting the allowlist grow permissively over time as new integrations get added with no corresponding review, following the least privilege discipline running throughout this content series.
Test egress restrictions directly with a deliberate attempt
Test the actual egress restriction by deliberately attempting to direct a tool toward a non-allowlisted destination in a controlled test, confirming the restriction actually blocks it, rather than assuming the configuration is correctly enforced with no direct verification, following the testing discipline running throughout secure development guidance.
Where TELEON fits
TELEON's policy enforcement, applied through the gateway or supported middleware, can apply destination-based restrictions to tool calls at the policy layer, and its audit trail supports monitoring for attempted egress to non-allowlisted destinations across the agent activity it observes.
Defining specific destination allowlists for each tool, implementing application-layer validation against them, and configuring network-layer egress restrictions remain application and infrastructure engineering work specific to each organization's own tools and integrations.
A short checklist
- Define an explicit allowlist of legitimate outbound destinations per
tool.
- Treat any model-specified destination value as untrusted input
requiring validation.
- Apply egress restriction at both the application and network layers.
- Monitor and alert on attempts to reach non-allowlisted destinations.
- Apply volume and content-based limits to outbound data, not only
destination restrictions.
- Review allowlists periodically as agent tools and capabilities evolve.
- Test egress restrictions directly with a deliberate, controlled
attempt.
Egress control closes the specific path a manipulated agent would need to actually exfiltrate data, and building it as an explicit, tested, multi-layered restriction, rather than an assumption that general network security already covers it, is what makes this containment reliable.