Egress Lockdown (No-Exfiltration Channel)
Puts the agent behind a default-deny egress firewall with allowlisted destinations so stolen data has no outbound channel
View .md
Edit on GitHub
Add to Pack
or
Saved locally in this browser for now.
Cite This Pattern
APA
Nikola Balic (@nibzard) (2026). Egress Lockdown (No-Exfiltration Channel). In *Awesome Agentic Patterns*. Retrieved October 14, 2026, from https://agentic-patterns.com/patterns/egress-lockdown-no-exfiltration-channel
BibTeX
@misc{agentic_patterns_egress-lockdown-no-exfiltration-channel,
title = {Egress Lockdown (No-Exfiltration Channel)},
author = {Nikola Balic (@nibzard)},
year = {2026},
howpublished = {\url{https://agentic-patterns.com/patterns/egress-lockdown-no-exfiltration-channel}},
note = {Awesome Agentic Patterns}
} Use when
- Agent has access to private data and reads untrusted input
- Agent runs in a container or VM where you control outbound network rules
- Needed external APIs can go through an internal proxy
Avoid when
- The agent must reach many arbitrary external sites to do its job
- The agent has no access to sensitive data
- You cannot build proxy stubs for essential integrations
Problem
Even with private-data access and untrusted inputs, attacks fail if the agent has no way to transmit stolen data. As an analogy of this pattern's author (not a framing from the source article), the design echoes the Bell-LaPadula "no write down" property: high-privilege subjects cannot write to low-trust destinations. Many real-world fixes simply removed or filtered outbound channels.
Solution
Implement an egress firewall for agent tools:
- Allow only specific domains, methods, or payload sizes.
- Strip or hash content in any permitted outbound call.
- Forbid dynamic link generation (e.g.,
attacker.example/exfil?q=REDACTED). - Where external communication is essential, run it in a separate "dumb" worker that cannot see private data.
# Docker file example
RUN iptables -P OUTPUT DROP # default-deny
RUN iptables -A OUTPUT -d api.mycompany.internal -j ACCEPT
# For L7-aware filtering: eBPF/XDP (Linux 4.19+) or Cilium
How to use it
- Place the agent inside a sandboxed VM or container with outbound rules.
- Provide needed APIs via an internal proxy; audit that proxy's request schema.
- Apply seccomp profiles or AppArmor policies to block network syscalls directly.
- Log any DROP events for forensic follow-up.
Trade-offs
Pros: Drastically reduces high-impact leaks; easy to reason about. Cons: Breaks legitimate integrations; requires proxy stubs for essential calls.
References
- Willison's article cites the Microsoft 365 Copilot, GitHub MCP, and GitLab Duo Chatbot incidents as "almost all... promptly fixed by the vendors, usually by locking down the exfiltration vector." It gives no per-vendor fix details and does not claim egress lockdown was the first patch in every case.
- Primary source: https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/ - describes the threat model this pattern mitigates; the default-deny egress firewall implementation itself is this pattern's contribution
- Parent threat model: Lethal Trifecta Threat Model
- Beurer-Kellner et al. (2025). "Design Patterns for Securing LLM Agents against Prompt Injections." arXiv:2506.08837.