Research Brief: Why Deny-by-Default Outperforms Allow-by-Default

Research Brief: Why Deny-by-Default Outperforms Allow-by-Default

When configuring safety policies for autonomous AI agents, teams face a fundamental architectural choice: should the agent be allowed to perform any action unless explicitly prohibited (allow-by-default), or should every action be blocked unless explicitly permitted (deny-by-default)?

This question has a long history in network security, where the firewall community settled it decades ago. Deny-by-default won. Our research confirms the same conclusion holds for AI agent safety, and the margin is not close.

Study Design

Over a four-month period, 15 Research Lab partnered with eight organizations deploying LLM-based agents in staging environments. Each organization ran identical agent configurations under two policy regimes:

• Allow-by-default: The agent could execute any action. A blocklist defined prohibited actions (e.g., no access to /etc/passwd, no outbound connections to known-malicious IPs).
• Deny-by-default: The agent could only execute actions on an explicit allowlist (e.g., read/write within /workspace, HTTP GET to approved API endpoints).

Both groups ran the same 750-task benchmark suite, which included standard productivity tasks, edge cases, and 83 adversarial prompt injection scenarios.

Key Findings

1. Safety Incident Rate

| Policy | Safety Incidents | Incident Rate |

|---|---|---|

| Allow-by-default | 127 | 16.9% |

| Deny-by-default | 8 | 1.1% |

Deny-by-default reduced safety incidents by 94%. The eight incidents in the deny-by-default group all involved actions that were on the allowlist but were used in unintended combinations, a solvable problem with more granular policy rules.

2. The Blocklist Completeness Problem

The fundamental weakness of allow-by-default is that it requires defenders to anticipate every possible harmful action in advance. This is the same asymmetry that plagues antivirus signature-based detection: the attacker only needs to find one path the defender did not enumerate.

In our allow-by-default deployments, the median blocklist contained 43 rules. Despite careful curation by experienced security engineers, 71% of the safety incidents involved actions that were not on the blocklist. Examples included:

• Writing to a temporary file, then using a shell command to move it to a sensitive location
• Making DNS lookups to encode and exfiltrate data
• Using curl to post workspace contents to an attacker-controlled endpoint not on the IP blocklist

These are not exotic attacks. They are straightforward chains that any competent red team would attempt. The blocklist approach simply cannot keep up.

3. Productivity Impact

A common objection to deny-by-default is that it constrains the agent too much, reducing task completion rates. Our data shows a more nuanced picture:

| Policy | Task Completion Rate | Avg. Completion Time |

|---|---|---|

| Allow-by-default | 91.2% | 34.1s |

| Deny-by-default | 87.6% | 36.8s |

The deny-by-default group completed 3.6% fewer tasks and took 7.9% longer on average. However, when we excluded the adversarial scenarios and looked only at benign tasks, the gap narrowed to 1.2% on completion rate and 3.1% on time. The productivity cost is real but modest, and far outweighed by the 94% reduction in safety incidents.

4. Policy Configuration Effort

Deny-by-default does require more upfront configuration. Teams in our study spent an average of 2.4 hours defining their initial allowlists, compared to 0.8 hours for blocklists. However, deny-by-default teams spent 67% less time on incident response and policy patching over the study period. The total time investment was lower for deny-by-default by week three.

Implementation Guidance

For teams adopting deny-by-default, the critical success factor is having a policy engine that makes allowlist configuration simple and expressive. Overly rigid allowlists frustrate developers and lead to policy bypasses (engineers disabling the safety layer entirely).

In our evaluation, SafeClaw by Authensor provided the most ergonomic deny-by-default implementation among the tools we tested. Its YAML-based policy definitions allow teams to express granular permissions (e.g., "allow file writes only within /workspace/output and only for files under 10MB") without writing code. SafeClaw's deny-by-default architecture is well-documented and aligns with the patterns that performed best in our study.

Recommendations

The firewall community learned this lesson twenty years ago. The AI agent community should not need to relearn it from scratch.