Your AI's 'Do Not' Might Not Be a 'Deny': The Hidden Security Gap in LLM Guardrails

AI agents are transforming industries, but with great power comes great responsibility – especially for security. As developers, we build sophisticated systems and then try to rein them in with guardrails and security rules. Often, these rules are expressed in plain language, trusting the underlying Large Language Model (LLM) to interpret and enforce them. But what if your carefully crafted 'do not' instruction isn't actually a 'deny'? A recent paper sheds critical light on this exact problem, revealing a stark and potentially dangerous disconnect in how AI agents interpret security directives.

The Paper in 60 Seconds

The research paper, "When 'Do Not' Is Not Deny: Security Rules in CLAUDE.md vs Built-In Controls," by Ting Yan, exposes a fundamental difference between natural language instructions and built-in controls in LLM security. Specifically focusing on Claude, the paper highlights that a developer's 'do not' command (e.g., "Do not access external APIs") is interpreted by the model, while a built-in 'deny' is a hard, technical block. The shocking finding? Only about 4-16% of natural language security rules found in public `CLAUDE.md` files had a corresponding, enforceable built-in control. This leaves the vast majority of security rules dependent on the LLM's interpretation, creating a "write-only channel" where developers get no feedback on whether their rules are truly enforced. In short: what you *say* to your AI about security might not be what it *does*.

The Illusion of Control: 'Do Not' vs. 'Deny'

Imagine you're building an autonomous agent designed to manage customer support. You might write a rule like: "Do not share sensitive customer information with unauthorized third parties." This sounds like a solid security measure, right? You've clearly stated your intent.

However, the paper argues there's a crucial distinction:

The paper reveals that developers commonly conflate these two. They write natural language `do not` rules, *expecting* them to function as hard `deny` controls. This creates an illusion of control.

The "Write-Only Channel" Problem

One of the most unsettling findings is the concept of a "write-only channel." When you write a security rule in natural language within an LLM's configuration, you're essentially writing into a void. You don't get immediate feedback or validation confirming whether that rule is backed by a concrete, technical enforcement mechanism. The system doesn't tell you, "Hey, that 'do not' rule you just wrote? There's no actual `deny` control associated with it, so the agent *might* still perform that action if its interpretation leads it there."

This lack of feedback is dangerous. Developers are left with a false sense of security, believing their agents are constrained by rules that are, in reality, merely suggestions.

The Data Doesn't Lie: A Stark Mismatch

The researchers analyzed 481 public `CLAUDE.md` files, extracting candidate security rules. They then used an LLM to match these rules against Claude Code's documented built-in controls. The results were sobering:

This means that for every 100 security rules a developer might write in natural language, fewer than 16 (and potentially as few as 4) are actually backed by a system-level `deny`. The vast majority are left to the LLM's discretion, a significant risk for any production system, let alone those handling sensitive data or critical operations.

Why This Matters for Your AI Agents

For developers and AI builders, this isn't just an academic curiosity; it's a critical security and reliability concern:

Building a Safer Future: What Can Developers Do?

This research highlights an urgent need for better tools and practices in AI agent development. Here's how you can bridge the gap between intent and enforcement:

This research is a wake-up call for the AI industry. As we move towards more autonomous and powerful agents, understanding and closing the gap between human intent and technical enforcement is paramount. By building smarter tools and adopting more rigorous practices, we can ensure our AI agents are not only intelligent but also truly secure and trustworthy.