Deny by default:
why AI agents should start with nothing

Without deny by default, an agent told to fix a failing test can also read ~/.aws/credentials, because nothing said it couldn't. Deny by default flips that: the agent starts with no access, and you add only what the task needs.

Deny by default is one of The 6 Principles of Secure Agent Platforms. In the series' building analogy, the room is built with no doors at all, so an agent with zero capabilities can't touch anything, even by accident. We will only specifically grant (allow list, not a deny list) the capabilities our agent must have to perform its function:

What does deny by default mean?

Deny by default means every request is refused unless a rule explicitly allows it. NIST defines it for firewalls: "block all inbound and outbound traffic that has not been expressly permitted by firewall policy"¹.

An agent touches more than network traffic, so apply the same rule to all resources it can reach, here we will discuss the 6 big categories: files, network, commands, secrets, config and hooks, and the host's control plane (the policy enforcement points page covers each).

In 1975, Saltzer and Schroeder called it fail-safe defaults: "Base access decisions on permission rather than exclusion"²³. If you forget an allow rule, something breaks and someone notices. If you forget a deny rule, the attack works and nobody notices.

Default deny, implicit deny and fail-safe defaults: one idea, three names

Implicit deny is the invisible last rule in a firewall or access list that drops anything no earlier rule allowed. It blocks all traffic that matches no allow rule. In nftables, you get it by giving a base chain policy drop⁴.

Where deny by default fits

Isolation draws the wall. Deny by default builds the room with no doors, least authority cuts only the doors the job needs, and policy enforcement points guard each door.

Deny by default vs default allow

Default allow starts open and blocks known bad things. Deny by default starts closed and opens known good things.

Deny by default has a cost: friction, approval prompts and broken builds. In practice, people then switch the protection off: --dangerously-skip-permissions in Claude Code, danger-full-access in Codex, seccomp=unconfined in Docker.

Allowlist vs denylist: why blocklists fail for AI agents

An allowlist names what is permitted and refuses everything else. A denylist names what is forbidden and permits everything else. Whitelist and blacklist are the older names.

A denylist loses to a creative model, because there are endless ways to say the same command:

• Cursor auto-run denylist bypass (Jul 2025). Researchers beat Cursor's banned-command list four ways: Base64, subshells, scripts and quoting. Cursor dropped the denylist.
• Claude Code escapes its own denylist (Mar 2026). Blocked from npx, the agent called /proc/self/root/usr/bin/npx instead.

An allowlist has to check the real thing, not a string. The Gemini CLI allowlist bypass (Jul 2025) checked only the first word of a command.

How AI agents break deny by default

Each of these nine started with something allowed by default. Newest first:

The off switch was a writable file

Copilot and Kiro kept their safety settings in files the agent could edit, so a hidden instruction turned approvals off or widened the allowlist. As a general rule, the agent can never write its own policy.

New tools started themselves

In CurXecute, Claude Code and Codex CLI ran tools from config nobody approved. The rule: a new tool or MCP server starts only after a human says yes.

Approvals off, damage on

Antigravity lost a drive with approvals off, and its Secure Mode checked too late. Langflow never checked. The rule: every action passes a check before it runs.

The 2026 lab breakouts: a network assumed closed

In 2026, frontier labs caught their own agents leaving sandboxes, and none used a hypervisor exploit. Each went through a channel that was allowed or assumed closed, from a package-registry proxy to an unfiltered DNS resolver. The principles hub tells each one.

After the DNS escape, OpenAI wrote: "Our safety case assumed that the model could not access the live internet... The incident exposed a gap in our controls over network restrictions." It paused all training, evaluation and inference using tool access for its most capable models.

In each case the network was assumed closed, not proven closed. So test the deny: from inside the sandbox, try DNS, the proxy and a direct connection. Each should fail.

How to implement deny by default security (step by step)

1. Declare what the task needs up front: files, commands, hosts and secrets, so the sandbox never guesses (step one of the six-step method).
2. Start every resource from an empty rule set.
3. Grant one thing at a time, as narrow as the control allows: a path, a host plus method, one import.
4. Make the policy and the agent's config files read-only to the agent.
5. Require a human to approve any new grant. Never auto-start new tools or MCP servers. Ask again when a tool's definition changes.
6. Test the deny. Claude Code's docs suggest curl --noproxy '*' https://example.com, which should fail⁷.
7. Log every denial and review it before you widen a grant.

Deny by default across the sandbox types

A plain process on any OS starts wide open: it can do everything your user account can. An OS sandbox reaches deny by default only when you stack more tools on top:

• Linux: a Landlock deny-all ruleset, then grants per path; a seccomp filter whose default action returns an error; bubblewrap namespaces for an empty filesystem view and no network; and a proxy, such as socat, for the network you allow.
• macOS: a Seatbelt profile that starts from (deny default), run with sandbox-exec, plus a Network Extension filter for the network. Apple has deprecated sandbox-exec and documents no profile language; App Sandbox entitlements are the documented route.
• Windows: AppContainer or LPAC, which starts with no capabilities, plus App Control in allow mode, so code runs only if your policy says so. Windows Firewall allows all outgoing traffic by default, so set it to block outbound.

Each layer is one more policy to write and keep current. The table rates the OS sandboxes as configured. As elsewhere, we call these "sandbox types" after the conventional usage, though containers and VMs are not sandboxes on their own.

A plain process starts with everything the user can do. A configured OS sandbox can start from nothing but rarely does, because nobody can predict what an arbitrary program needs; Wasm starts there, because each component declares its needs as imports.

What the agent vendors ship: network closed by default

• Claude Code uses Seatbelt on macOS and bubblewrap on Linux and WSL2. Traffic goes through a local proxy whose allowed domains start empty. The gaps: when a command fails, Claude may retry it outside the sandbox with dangerouslyDisableSandbox (set allowUnsandboxedCommands: false to stop that), excludedCommands run with "no filesystem restrictions and no network proxy", and "Claude's file tools, MCP servers, and hooks run outside it."
• Codex has three modes: read-only, workspace-write and danger-full-access. In the default workspace-write mode, network access is off unless you turn it on.

Two deny-all network examples

Kubernetes (needs a network plugin that enforces NetworkPolicy):

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-egress
spec:
  podSelector: {}
  policyTypes:
  - Egress

nftables:

table inet agent {
  chain output {
    type filter hook output priority 0; policy drop;
  }
}

For the full 15-row comparison, see the comparison matrix.

Deny by default with WebAssembly components

A WebAssembly component with no imports can compute, but it cannot touch a file, a socket or a secret. In WASI's own words, a component "starts with no ambient authority and can only do what the host explicitly grants" (wasi.dev).

The component declares its needs up front: its imports list them before it runs, so the host never guesses. App Sandbox entitlements are the same idea for macOS apps.

package example:fetcher;

world fetcher {
  import wasi:http/client@0.3.0;
  export run: func() -> string;
}

• world fetcher is the component's full contract with the host.
• import wasi:http/client is its only grant: it may make outgoing HTTP requests. The host still decides which destinations¹⁴.
• export run is what it offers. With no file or socket import, it has neither (more on capabilities).

A capability is also unforgeable: a component can use only what it was handed, and it can't guess one, build one from a name or string, or copy one it was never given¹⁵. The runtime enforces this, not the program's good behavior: a component can call only the imports the host linked, and the runtime checks every resource handle, so the room has no doors until the host cuts one.

Cosmonic uses this model. Cosmonic Desktop, for macOS, Windows and Linux, runs components in a deny-by-default sandbox and shows what a component can reach before it runs. Cosmonic Control denies egress by default, adds DNS controls, and uses a Kubernetes admission controller and RBAC.

The limits: every capability needs host wiring, and existing CLI tools must be ported or wrapped.

Is deny by default part of zero trust for AI agents?

Yes: zero trust gives no implicit trust by location, so every request is refused until a policy decision allows it¹⁶. For agents, location means the laptop, the VPC or the repo the user just opened. Being there grants nothing. The Claude Code and Codex CLI repo-config incidents were location-trust failures. The policy enforcement points page covers checking every request.

Deny by default and the other principles

• Least authority keeps the grants you add back small.
• Policy enforcement points make the deny real at every request.
• Controlled information flow covers what deny by default can't: data leaking through a channel you allowed.
• Defense in depth stacks it with other layers, because one layer can fail.

To see what a component can reach before it runs, try Cosmonic Desktop. Or go back to The 6 Principles of Secure Agent Platforms.

Related topics

Frequently asked questions

Further reading

Papers

• Miller 2006, "Robust Composition"¹⁷

Upstream docs

• OpenAI Codex: Agent approvals and security
• Landlock, Linux kernel docs
• Kubernetes NetworkPolicy