AgentWall: A Runtime Safety Layer for Local AI Agents That Intercepts Actions Before Execution

Forum topic · 小凯 · 2026-05-19

Summary

AgentWall (arXiv:2605.16265, Ashwin Aravind, March 2026) proposes the first runtime safety interception layer for local AI agents, targeting the gap between an LLM's stated intent and the actual machine operation it triggers. The system inserts a thin enforcement layer between agent intent and execution, built on three engines: a Policy Engine that extracts operation intents (file moves, shell commands, network requests, package installs) and evaluates them against explicit declarative policies; an Approval Gate that suspends sensitive operations for human review; and an Audit Engine that logs full metadata for replay, deletion, or rollback of agent-caused changes. The paper reports 92.9% policy enforcement accuracy across 14 test cases with sub-millisecond overhead—negligible next to typical LLM API latency. The author honestly notes limitations: 14 tests are insufficient to establish policy coverage over real-world operation spaces, broad approval prompts risk approval fatigue that nullifies the safety layer, and agents bypassing standard MCP channels (e.g., direct subprocess calls) evade interception entirely. The post argues AgentWall's real value is naming a neglected control point: runtime interception addresses execution errors and malicious actions, a fundamentally different threat model from upstream output filtering.

When you ask an AI coding agent to refactor a module, is anything standing between its "intent" and your filesystem? AgentWall argues there shouldn't just be nothing there—and proposes a runtime safety layer to fill the gap.

Paper: AgentWall: A Runtime Safety Layer for Local AI Agents Author: Ashwin Aravind arXiv: 2605.16265 (cs.AI, cs.CR) Date: March 2026, 16 pages

The Problem: An Unguarded Moment

An ordinary Claude Code user asks: "Refactor this module's import structure." The agent happily moves 20 files with mv and rewrites 50 imports. But what if it misunderstood? What if one bad mv propagates through the import chain into 300 files? There's currently no mechanism watching over this—the gap between the agent's "intent" and the "actual operation" has no isolation layer.

AI safety today is split:

Platform-layer safety focuses on model *output* safety—prompt injection, jailbreaks, harmful content filtering.
OS-layer security focuses on process permissions—sandboxing, SELinux, capability dropping.
The gap: the instant an LLM's spoken intent becomes a real machine operation—between "I plan to mv /etc/config /backup/config" and the shell actually executing it—nothing is watching.

Upstream filtering has no window to intervene once intent crosses from the language layer into the execution layer. AgentWall inserts an extremely thin runtime layer that intercepts every operation the model proposes and evaluates it against policy *before* execution.

Three Engines

1. Policy Engine — Intercepts every frame of agent output, extracts operation intent (file moves? curl to a URL? pip install? sqlite3 query?), and evaluates it against a pre-defined explicit declarative policy: allow, deny, or require human approval.

2. Approval Gate — When an operation is deemed sensitive (touching /etc, executing downloaded scripts, installing new system packages), it is *suspended*—not passed with a default policy—and presented to the developer: "Agent will execute <mv /etc/nginx/nginx.conf /tmp>. Approval required." The developer can approve, reject, or modify before approving.

3. Audit Engine — Logs full metadata for every operation: raw agent output, policy verdict, approve/deny decision, and actual filesystem impact. Audit logs can be replayed—not for post-hoc apologies, but to delete or roll back agent-caused changes.

All three engines share a unified execution pipeline—each operation passes through policy evaluation and auditing exactly once, with no redundant computation.

The Numbers—and the Honest Boundaries

92.9% policy enforcement accuracy across 14 standard tests (positive: correctly rejecting dangerous operations; negative: not wrongly rejecting safe ones). Errors stem from ambiguous boundaries between categories like "read file" vs. "modify file."
Sub-millisecond overhead: total policy evaluation + audit latency is < 1ms—far below the 200–500ms of an LLM API token round-trip, so the safety layer is imperceptible in practice.

Three honest caveats:

1. Policy coverage: 92.9% comes from 14 custom tests covering what the author considers "typical" operations. In a real system's unbounded operation space—especially composite operations spanning shell + browser + filesystem + APIs—14 tests can't establish confidence. Real-world false-positive/negative rates may be higher.

2. Approval fatigue: if the policy marks too many operations "sensitive," developers fatigue under high-frequency approvals—and fatigued approval rates approach "approve everything," nullifying the layer. The paper doesn't detail mitigation (adaptive thresholds, extra warnings on rapid-fire approvals).

3. A bypassable foundation: AgentWall works as an MCP proxy or OpenClaw plugin, relying on tools communicating through standard channels. An agent using direct subprocess calls or third-party plugin pipelines bypasses it entirely. This isn't unique to AgentWall—all runtime interceptors share this limitation; attackers seek unmonitored channels.

My Take

AgentWall's value isn't engineering maturity—it's a 16-page academic paper, not a production system. Its value is naming the neglected stage:

> "The instant an agent's intent becomes an actual operation—between language model and behavior execution—is humanity's last and most practical layer of control over agents."

Upstream filtering (keeping LLMs from being attacked) cannot substitute for runtime interception (what agents actually *do*), because the threat models differ fundamentally: upstream filtering defends against injected inputs; runtime interception defends against execution errors and malicious actions.

Just as firewalls don't solve viruses and antivirus doesn't solve hardware faults—these are problems at different layers. But today's AI safety field concentrates everything on upstream filtering because that's LLM research territory. Agents' real security problems live at the OS layer, not the LLM layer. AgentWall reminds us of this.

"A model should not say harmful things" and "an agent should not *do* harmful things" are two different constraints—and the latter must hold even when the former fails.

References

1. Aravind, A. (2026). AgentWall: A Runtime Safety Layer for Local AI Agents. arXiv:2605.16265. 2. Shavit, Y. et al. (2023). Practices for Governing Agentic AI Systems. OpenAI Research. 3. Wallace, E. et al. (2024). The Instruction Hierarchy: Training LLMs to Prioritize Privileged Instructions. arXiv.