AgentWall: Runtime Safety for AI Agents
- AgentWall is a runtime safety and observability layer that intercepts local AI agent actions to prevent unsafe operations and enable audit trails.
- It enforces explicit declarative policies and requires human approval for sensitive commands, balancing automation with user control.
- AgentWall integrates with multiple agent platforms, achieving 92.9% policy enforcement accuracy with sub-millisecond decision latency.
AgentWall is a runtime safety and observability layer for local AI agents that sits between an agent’s proposed action and the host machine, so that tool use is not executed blindly. It is designed for local environments in which agents can run shell commands, modify files, call APIs, browse the web, and interact with developer machines. Its core mechanism is to intercept every proposed action before it reaches the host environment, evaluate it against an explicit declarative policy, require human approval for sensitive operations, and record a complete execution trail for audit and replay. The system is implemented as a policy-enforcing MCP proxy and native OpenClaw plugin, works across Claude Desktop, Cursor, Windsurf, Claude Code, and OpenClaw with a single install command, and reports 92.9% policy enforcement accuracy with sub-millisecond overhead across 14 benchmark tests (Aravind, 24 Mar 2026).
1. Problem setting and security rationale
AgentWall is motivated by a gap between agent intent and machine execution. A LLM may produce a plausible next step, yet that step can still be unsafe because it may delete files, access credentials, run destructive shell commands, or follow prompt-injected instructions from a webpage or repository. In local settings the risk is amplified because the agent often has access to the user’s filesystem, terminal, browser, credentials, and project directories (Aravind, 24 Mar 2026).
The paper frames local agent safety as a systems and runtime enforcement problem rather than only a model-alignment problem. The motivation is operational: once a tool call is executed, mistakes become real-world events. AgentWall therefore addresses accidental destructive actions, actions outside the intended workspace, unsafe shell usage, risky or unexpected network access, prompt injection that causes dangerous tool requests, poor model judgment about tool choice or scope, and the inability to reconstruct what happened after the fact (Aravind, 24 Mar 2026).
The system does not claim to replace model alignment, containers, or endpoint security. It also does not claim to fully defend against kernel-level attacks, malicious users with administrative access, sophisticated adversaries who already control the host, all side-channel data exfiltration, complete model misbehavior, or general replacement for containers, VMs, or endpoint security. Its stated purpose is narrower: to provide a practical middle layer that makes local agent use safer, more inspectable, and more controllable (Aravind, 24 Mar 2026).
A related formulation in the contemporaneous literature is AIRGuard’s claim that “Data can inform; only authority can authorize,” which similarly relocates the decisive security check from prompt interpretation to action-time control (Qin et al., 27 May 2026). This suggests a broader shift in agent security research from output filtering toward runtime mediation of side effects.
2. Architecture and execution boundary
AgentWall is described as a mediation layer composed of seven components: Agent Runtime, Action Interceptor, Policy Engine, Approval Engine, Execution Adapter, Event Log and Trace Store, and Inspection Interface (Aravind, 24 Mar 2026).
| Component | Role |
|---|---|
| Action Interceptor | Intercepts proposed agent actions before host execution |
| Policy Engine | Returns Allow, Deny, or Ask |
| Approval Engine | Requests explicit human approval for sensitive actions |
| Execution Adapter | Performs filesystem, shell, network, or browser operations after approval/policy checks |
| Event Log and Trace Store | Records action proposals, decisions, approvals, and outcomes |
| Inspection Interface | Supports later inspection of traces |
The decisive architectural feature is action interception. The “wall” sits exactly at the point where model output becomes potentially dangerous execution. The paper describes three implementation modes. In wrapper mode, tools are invoked through AgentWall-managed adapters instead of directly. In gateway mode, AgentWall sits in front of a local agent service and mediates all action requests. In hybrid mode, it combines explicit tool wrappers with a higher-level policy and event gateway. This allows deployment across different local agent runtimes rather than requiring a monolithic new framework (Aravind, 24 Mar 2026).
The execution path is intentionally simple. A user gives a task to an agent; the agent proposes actions; AgentWall intercepts them; the policy engine evaluates them; sensitive ones are escalated to the user; allowed ones are executed; and all outcomes are logged. The host is therefore reached only after policy and approval checks, not directly by the agent (Aravind, 24 Mar 2026).
The integration strategy is also central. AgentWall is implemented as a policy-enforcing MCP proxy and a native OpenClaw plugin, and the abstract states that it works across Claude Desktop, Cursor, Windsurf, Claude Code, and OpenClaw with a single install command. In the paper’s framing, this runtime-agnostic proxy-and-plugin architecture is important because it lets AgentWall sit in front of multiple local agent products without requiring each product to be rewritten (Aravind, 24 Mar 2026).
3. Declarative policy model and approval semantics
The policy model is rule-driven and legible rather than classifier-only. Policies may inspect action type, target path, command pattern, file pattern or extension, destination domain or endpoint, workspace boundary, and confidence or risk level from a rule set. Every policy evaluation returns one of three outputs: Allow, Deny, or Ask (Aravind, 24 Mar 2026).
The examples in the paper are concrete and local-agent-specific. Policies can allow reads inside the current project directory, deny access to SSH keys, cloud credentials, and password stores, allow safe package-inspection commands, require approval for deletions, overwrites, or recursive operations, allow outbound traffic only to configured domains or APIs, and deny clearly destructive shell patterns. The paper emphasizes that AgentWall is not trying to infer safety from a black-box classifier alone; it uses explicit, inspectable, runtime rules (Aravind, 24 Mar 2026).
Human approval is the mechanism for the Ask branch. When the policy engine returns Ask, the action is surfaced to the user and is not executed immediately. The paper presents this as the appropriate path for actions that are high impact, ambiguous, context-dependent, or potentially useful but risky. Examples explicitly mentioned include file deletion, overwrites, recursive operations, sudo apt-get, and some SQL delete operations. The system therefore distinguishes between actions that are unsafe enough to block and actions that may be valid but require a human in the loop (Aravind, 24 Mar 2026).
This three-way design differs from adjacent runtime security systems. AIRGuard, for example, uses a larger enforcement set—allow, audit, ask, inspect, sandbox, quarantine, and block—and derives decisions from normalized capabilities, task authority, and source-target trust (Qin et al., 27 May 2026). OpenClaw PRISM, by contrast, distributes enforcement across ten lifecycle hooks and couples thresholded responses with conversation-scoped and session-scoped risk accumulation with TTL-based decay (Li, 12 Mar 2026). AgentWall is narrower in scope but correspondingly simpler: it inserts a structured decision point into the path from model output to host action (Aravind, 24 Mar 2026).
4. Observability, audit, and threat boundaries
A major part of AgentWall is observability. Every action proposal, policy decision, approval decision, and execution outcome is written to a structured Event Log and Trace Store. The log is described as structured, durable, and independent of the AI client, and as suitable for audit and replay. This addresses a practical failure mode of local agents: after a run, users often cannot reconstruct why the agent changed certain files or issued certain commands (Aravind, 24 Mar 2026).
The benchmark session was recorded in a JSONL log, with each entry containing timestamp, runtime, decision, deciding mechanism, and tool or command involved. The paper presents this as a way to solve the “black box” problem of local agents by making agent activity inspectable at the level of concrete actions and policy decisions rather than only model traces (Aravind, 24 Mar 2026).
The threat model is explicitly practical and narrower than a full host security model. AgentWall aims to reduce risk from accidental destructive actions, actions outside the intended workspace, unsafe shell usage, risky or unexpected network access, prompt injection that causes dangerous tool requests, and poor model judgment about tool choice or scope. It does not claim complete protection against fully compromised hosts or universal exfiltration channels (Aravind, 24 Mar 2026).
The importance of these boundaries is reinforced by attacks studied elsewhere. ClawWorm shows that when an agent ecosystem combines persistent configuration, unconditional startup execution, broad tool access, and peer-to-peer messaging, a single malicious message can become a restart-surviving worm. Its analysis identifies failures at the context boundary, configuration boundary, skill boundary, tool boundary, and supply-chain boundary (Zhang et al., 16 Mar 2026). AgentWall is not a complete response to those ecosystem-level issues, but it occupies the same strategic location: the runtime boundary where proposed actions can still be checked before side effects are committed.
5. Benchmark results and operational properties
The paper evaluates AgentWall v0.8.1 on a benchmark suite of 14 representative local-agent tool calls on macOS, using the AgentWall MCP proxy with the default ~/.agentwall/policy.yaml. The benchmark script sends tool calls through the proxy and records decision, latency, and pass/fail outcome (Aravind, 24 Mar 2026).
| Benchmark result | Value | Note |
|---|---|---|
| Policy enforcement accuracy | 92.9% | 13 of 14 tests correct |
| Average decision latency | 0.198 ms | Reported as negligible relative to tool execution |
| p95 latency | 0.745 ms | Sub-millisecond overhead |
| Minimum latency | 0.058 ms | Benchmark result |
| Maximum latency | 0.745 ms | Benchmark result |
| Session log decisions | 50 | Captured in audit trail |
The reported 92.9% accuracy corresponds to 13 of 14 tests enforcing the expected decision. The benchmark results show that secrets access attempts were denied correctly; destructive shell patterns such as curl | sh, eval 1-\text{ASR}$, emphasizing cross-framework comparability rather than deployable enforcement (Wu et al., 13 Jan 2026). AgentWall’s evaluation is therefore narrower and more runtime-specific: it measures whether a policy boundary correctly mediates representative local tool calls.
6. Position within the broader “agent wall” landscape
Within the 2025–2026 literature, “wall”-like concepts appear in several distinct forms. AgentWall denotes a runtime safety and observability layer for local agents (Aravind, 24 Mar 2026). AIRGuard denotes a runtime authority-control layer that treats untrusted resources as informative but not authorizing, and evaluates whether each normalized action is covered by scoped authority before execution (Qin et al., 27 May 2026). OpenClaw PRISM denotes a zero-fork, defense-in-depth runtime security layer for OpenClaw-based agent gateways that distributes enforcement across message ingress, prompt construction, tool execution, persistence, outbound messaging, sub-agent spawning, and startup (Li, 12 Mar 2026). These systems share an execution-boundary orientation, but they differ in enforcement vocabulary, runtime scope, and coupling to specific agent stacks.
A different use of wall-like language appears in interoperability research. The position paper on universal interoperability argues that LLM agents can act as “universal adapters” and become an antidote to “walled gardens,” meaning closed proprietary application layers that restrict data exchange and user portability (Marro et al., 30 Jun 2025). AWCP addresses another boundary: it introduces temporary workspace delegation so that agents can cross a “workspace wall” and operate directly on delegated files rather than reconstructing environments from messages alone (Nie et al., 24 Feb 2026). These are not security walls in AgentWall’s sense; they concern service interoperability and workspace projection.
A further boundary concept appears in AgentWebBench, which studies decentralized coordination in an Agentic Web where each website is a closed domain guarded by its own content agent and the user agent has no direct corpus access (Zhong et al., 13 Apr 2026). The paper does not define an AgentWall component, but it operationalizes a wall-like access boundary at the website level. This suggests that the term “AgentWall” can be misleading if detached from its specific paper: in current usage, it may refer to execution mediation, workspace delegation, platform lock-in, or controlled access boundaries, depending on context.
Taken specifically, AgentWall is best understood as an execution-boundary system for local AI agents. Its distinctive contribution is not a novel detector or a general theory of trust, but a concrete runtime architecture that interposes on every proposed action, enforces declarative policy, escalates sensitive operations for human approval, and preserves a replayable trace. In the emerging agent-security literature, that places it squarely within the line of work that treats safety as enforceable control over side effects at runtime rather than solely as alignment of model outputs (Aravind, 24 Mar 2026).
