Default-Deny Network Egress — Frontier AI Security: Attack Surfaces

A frontier artificial intelligence (AI) system inside a test environment can reason, write code, and make plans, but most harmful outcomes still need one ordinary thing: a network path out. Default-deny network egress is the discipline of closing that path by default and opening only the few exits the work truly requires. It is not a complete security program, but it is one of the controls that most reliably turns a serious mistake into a contained incident.

Egress is the exit door

Egress means traffic leaving an environment. In ordinary network security, people often focus on ingress, which is traffic coming in. That matters, but for an isolated AI evaluation, the outbound direction is often the more important one.

Many risky actions require egress. A model or tool it controls may try to download a missing exploit utility, send data to an external server, contact a target it has identified, or receive updated instructions from somewhere outside the lab. If the environment has no usable outbound path, those actions cannot finish, even if earlier defenses fail.

This is why egress control is so useful: it does not need to understand the model’s intent. It only needs to enforce the simpler rule that the environment may reach approved places and no others.

Default-allow and default-deny fail in opposite directions

There are two basic ways to control outbound traffic. Default-allow permits outbound connections unless a rule blocks them. Default-deny blocks outbound connections unless a rule permits them.

That difference sounds small until something unexpected happens. In a default-allow design, a destination you forgot to block is reachable. The system fails open. In a default-deny design, a destination you forgot to allow is unreachable. The system fails closed.

Against an adaptive system, failing closed matters. You should assume the system may try routes you did not predict, including obscure domains, direct Internet Protocol (IP) addresses, alternate ports, or newly created infrastructure. Default-deny treats all of those as blocked unless someone deliberately approved them.

✅

The core idea. Default-deny changes the job from naming every bad place to naming the few good places.

Default-allow fails open when you forget a rule; default-deny fails closed and stays contained.

Allowlists scale; blocklists do not

A blocklist is a list of things to forbid. For egress, that might mean known malicious domains, suspicious IP ranges, or categories of websites. Blocklists have a role in defense, but they are a weak foundation for a high-risk evaluation because the set of bad destinations is too large and changes too quickly.

An allowlist is the reverse: a short list of approved destinations. For a controlled evaluation, the legitimate outbound needs should be small. Perhaps the environment needs one internal package mirror, one artifact store, and one logging endpoint. If a destination is not on that list, it is not reachable.

This is the burden shift that makes default-deny powerful. The bad set is open-ended. The good set should be finite, documented, and owned.

A blocklist asks, What do we already know is dangerous?
An allowlist asks, What does this workload actually need?
A blocklist is always behind the attacker’s next destination.
An allowlist automatically covers destinations that nobody has imagined yet.

What an evaluation should be allowed to reach

The safest answer is usually nothing. If an evaluation can run with no outbound network access, that should be the starting point. Offline datasets, prebuilt containers, pinned dependencies, and local documentation reduce both security risk and experimental noise.

When egress is necessary, allow the narrowest destination that supports the work. A package registry proxy is a common example: instead of letting the environment reach the public package ecosystem, it reaches one controlled proxy that caches approved packages and records what was requested. The evaluation gets reproducible dependencies without opening the internet.

The same logic applies to telemetry and results. If logs or metrics must leave the environment, send them to a specific internal collector with a known purpose, not to arbitrary external services.

Prefer no outbound access when the evaluation can run offline.
Use internal mirrors or proxies instead of direct public internet access.
Allow exact destinations, protocols, and ports rather than broad network ranges.
Make every allowed destination traceable to a named evaluation requirement.
Expire temporary exceptions when the run or project ends.

Enforce the rule in layers

Default-deny egress should not live only in application code. A model-controlled process should not be trusted to enforce the rule that limits the model-controlled process. Put enforcement below and around the workload.

Useful layers include host firewalls, container or workload network policies, cloud routing controls, dedicated egress proxies, and domain name controls. A proxy is an intermediary service that makes the outbound request on behalf of the workload, after checking policy. The more sensitive the evaluation, the more the final outbound path should pass through infrastructure that the workload cannot modify.

Layering also reduces the chance that one configuration error opens the whole environment. If a container policy is wrong but the proxy still denies the destination, the system remains contained. If the proxy rule is too broad but the firewall allows traffic only to the proxy, direct escape routes stay closed.

Egress control lives below the workload across firewalls, workload policy, a proxy, and DNS.

Expect attempts to slip through the cracks

A serious egress design assumes that a model, an exploit, or a malicious dependency may look for any route that still works. It may try direct IP addresses instead of names, uncommon ports instead of standard ones, or the Internet Protocol version 6 path when only Internet Protocol version 4 was filtered.

It may also abuse something that is legitimately allowed. For example, if the only permitted destination is a package proxy, that proxy must not become a general-purpose tunnel to the public internet. If logs are allowed out, they must not become a place to smuggle large secrets. If the Domain Name System (DNS), which translates names into network addresses, is allowed, it should not be usable as a hidden data channel.

None of this means egress control is fragile. It means the allowlist must describe real allowed behavior, not just allowed hostnames. Good policies constrain the destination, protocol, port, request type, authentication, and expected volume.

⚠️

Allowed is not unlimited. Every allowed path needs its own guardrails, because attackers often try to turn a narrow exception into a broad tunnel.

An adaptive system probes any path that still works, from direct IPs to abusing an allowed proxy.

The real decision: convenience or containment

Leaders and practitioners often face the same tradeoff. Broad internet access makes experiments easier to run. Strict egress makes them safer, more reproducible, and easier to explain after an incident. The right default for high-risk AI evaluations is containment, with exceptions handled deliberately.

A useful review question is not, Can the team do its work with internet access? Of course it can. The better question is, What exact outside service is required, what data will cross the boundary, who owns the exception, how will it be logged, and when will it expire?

Treat every egress rule as a dependency in the evaluation safety case. If a destination is important enough to allow, it is important enough to document, monitor, and revisit.

What destination is being requested, and why is it necessary?
Can the same need be met with an offline artifact or internal mirror?
What data can leave through this path?
Who approves and owns the exception?
What logs prove the rule was used as intended?
When does the rule automatically expire?

Every egress exception should name the service, the data crossing, the owner, and an expiry.

What egress control does not replace

Default-deny egress is high leverage, not magic. It does not remove the need for sandboxing, least privilege, secret management, safe dependency handling, dataset hygiene, or monitoring. A model that cannot reach the internet may still damage local files, reveal information in evaluation outputs, or interfere with the measurement itself.

Its value is that it makes many other failures less catastrophic. If a dependency is malicious, it cannot easily call home. If a sandbox escape works, the escaped process still has no general internet route. If a secret is exposed inside the environment, it is much harder to send that secret elsewhere.

Good egress control also improves incident response. Denied connection attempts become signals. Unexpected requests reveal what the workload tried to do. Logs from the proxy and firewall can help reconstruct whether a run stayed inside its intended boundary.

📌

Defense in depth. Egress control is strongest when it backs up other controls rather than standing alone.

Key takeaways

Egress is outbound network traffic, and many harmful model-driven actions require it.
Default-deny blocks all outbound traffic unless a specific destination is approved.
Default-allow fails open when you miss a destination; default-deny fails closed.
Allowlists work better than blocklists because the legitimate destinations should be few and knowable.
Allowed paths still need limits, logging, ownership, and expiration.
Default-deny egress does not replace sandboxing or secret hygiene, but it makes many failures survivable.

Glossary

Egress: Network traffic leaving an environment for another system or network.
Default-deny: A policy that blocks actions by default and permits only explicitly approved exceptions.
Allowlist: A list of destinations, actions, or identities that are specifically permitted.
Blocklist: A list of destinations, actions, or identities that are specifically forbidden while everything else is allowed.
Fail closed: A control fails closed when unexpected conditions result in denial rather than permission.
Exfiltration: The unauthorized movement of data out of an environment.
Proxy: An intermediary service that handles a request on behalf of a workload and can enforce policy before forwarding it.
Domain Name System: The internet naming system that translates human-readable names into network addresses.