AI Safety — Software Engineering

Why AI Agent Rules Almost Always Fail — And How the Operating System Fixes That

A fresh study counted 2,116 instructions written into AI-agent project files and found that most of them are impossible to enforce without looking inside the operating system kernel. The fix is a technology called eBPF.

• 64% of the 2,116 instructions were real policies — requirements, prohibitions, or conditions on agent actions, not just background notes.
• Only 45% of all policies can be enforced at the OS level at all; the rest depend on context that no single tool-call guardrail can see.
• 83% of policies are "system-observable," but 64% of those still need to read the specific code repository to even know what rule to enforce.

Most people think of AI-agent safety as a problem of writing better instructions — telling a coding agent "run the tests before you commit," or "do not touch this file." A recent paper from the eunomia project, published on Hacker News with 351 points, starts from a different question: given the rules developers already write, which ones can a system actually check?

The team studied 64 popular open-source repositories (median 20,000 GitHub stars) containing CLAUDE.md and AGENTS.md instruction files, then classified each of their 2,116 statements individually. They sorted every policy into tiers by what it takes to enforce it. "Semantic-only" rules are about tone or reasoning style. "Content" rules inspect a file. "Per-event" rules watch a single command or file access. "Cross-event" rules need to know the order of several actions over time — exactly the kind needed for "run tests before committing."

Here is the catch: cross-event and multi-step rules cannot be judged from a single event. The rule "update the documentation whenever behavior changes" needs the system to remember both that a source file was edited and whether docs were edited too. Eighty-one percent of the repositories contained at least one such cross-event policy. And these are also the rules that rarely say which exact command or path to watch.

Tool-call guardrails and prompt instructions each have a blind spot. Prompt rules rely on the model's compliance and compete with the user's task for attention; a tool-call guardrail sees only the requests the harness forwards, but a subprocess, shell-out, or compiled binary can quietly bypass it entirely. OS-level mechanisms like seccomp or AppArmor control access to resources, not the kind of actions developers actually write about, and they tend to return opaque errors that confuse the agent rather than explaining the rule that was broken.

The eunomia team's proposed answer is ActPlane, an eBPF-based policy engine that sits inside the Linux kernel and can observe and enforce agent behavior at the system-call level. eBPF has become the standard way Linux lets programs safely attach small monitors to the kernel, so it is already used for tracing, networking, and security. In the ActPlane model, repository and task context is compiled into concrete state first, then deterministic kernel-level checks evaluate each action against it.

The study is a sobering map of the gap between what humans ask AI agents to do and what current guardrails can verify. The headline is not that agent rules do not work; it is that most of them were never written to be enforced at all — and closing that gap means moving enforcement down, out of the prompt, and into the operating system itself.