Technical Summary: AgentWall – A Runtime Safety Layer for Local AI Agents

1. Problem Statement

The paper addresses a critical gap in the deployment of autonomous AI agents: the transition from passive text generation to active execution on local machines. While modern agents can execute shell commands, modify files, and call APIs, existing safety mechanisms (such as model alignment, input filtering, and general sandboxing) fail to address the specific risks at the execution boundary.

In local environments, developers often run agents directly against their filesystems and credentials without full virtualized isolation. This creates operational risks where agents may:

• Execute unintended destructive commands due to ambiguous prompts or poor reasoning.
• Act on malicious instructions hidden in external content (prompt injection).
• Access sensitive directories (e.g., SSH keys, credentials) outside their intended scope.
• Operate as "black boxes," making it difficult to audit or replay actions after the fact.

The core problem is the lack of a runtime control layer that can observe proposed agent actions, evaluate them against explicit policies, and enforce boundaries before they reach the host environment.

2. Methodology and Architecture

AgentWall is proposed as a practical, application-level runtime safety and observability layer. It functions as a mediation boundary between the agent runtime and the host environment, intercepting actions before execution.

High-Level Architecture

The system operates through the following conceptual components:

1. Agent Runtime: The execution system (e.g., OpenClaw, Claude Desktop) that plans and proposes actions.
2. Action Interceptor: A proxy or wrapper (implemented as an MCP proxy or OpenClaw plugin) that captures proposed actions.
3. Policy Engine: A rule-evaluation component that inspects action attributes (type, target path, command pattern, destination) against a declarative policy.
4. Approval Engine: A human-in-the-loop mechanism that escalates sensitive or ambiguous actions for explicit user approval.
5. Execution Adapter: The component that performs the action only if it is allowed or approved.
6. Event Log & Trace Store: A structured, tamper-evident record of all proposals, decisions, and outcomes for audit and replay.
7. Inspection Interface: A UI (terminal or web) for users to review the audit trail.

Policy Model

AgentWall utilizes a three-tier decision model:

• Allow: The action is deemed safe based on rules (e.g., reading files within the workspace).
• Deny: The action violates policy (e.g., accessing ~/.ssh, executing rm -rf on system paths).
• Ask: The action is potentially valid but high-risk, requiring explicit user confirmation (e.g., sudo commands, file overwrites).

Policies are declarative and can inspect action types, target paths, command patterns, file extensions, and network destinations.

Implementation Approach

The paper describes a prototype implementation (v0.8.1) that operates in wrapper mode or gateway mode. It routes shell commands, file operations, and network requests through a policy-aware interface. The system supports hot-reloading of policies without restarting the agent or proxy.

3. Key Contributions

The paper makes three primary contributions:

1. Problem Formulation: It defines the problem of "bounded local agent execution," arguing that safe deployment requires a control layer between agent intent and host-machine action.
2. System Design: It presents the architecture of AgentWall, combining action interception, explicit policy evaluation, approval gates, and structured trace collection.
3. Prototype Evaluation: It provides a concrete evaluation setup and results demonstrating the system's effectiveness in safety coverage, usability, and runtime overhead.

4. Evaluation Results

The authors evaluated AgentWall v0.8.1 on macOS using a benchmark suite of 14 representative local-agent tool calls.

• Policy Correctness: The system achieved 92.9% accuracy (13/14 tests).
  • It correctly denied all attempts to access credentials (~/.ssh, ~/.aws), dangerous shell patterns (curl | sh, eval), and destructive SQL operations (DROP TABLE).
  • It correctly escalated high-impact operations (e.g., sudo apt-get, DELETE SQL) for approval.
  • It correctly allowed safe workspace reads and writes.
  • Failure Case: One test (rm -rf /tmp/test) returned a DENY instead of the expected ASK. This was attributed to a policy precision issue where a prefix-matching deny rule (rm -rf /) subsumed a more specific ask rule. The authors note this is a conservative failure (blocking rather than permitting).
• Runtime Overhead: Policy evaluation latency was negligible.
  • Average decision latency: 0.198 ms.
  • P95 latency: 0.745 ms.
  • This is insignificant compared to the tens or hundreds of milliseconds required for actual I/O or network operations.
• Additional Features:
  • Rate Limiting: Successfully enforced call caps (e.g., blocking the 31st call in a sequence of 35).
  • Hot-Reload: Policy changes were applied immediately without restarting the proxy.
  • Audit Trail: All decisions were logged in a structured JSONL format, enabling full replay and debugging.

5. Significance and Claims

The paper modestly positions AgentWall not as a complete solution to agent safety, nor as a replacement for model alignment, containerization, or operating system security. Instead, it claims significance as a missing middle layer in the local agent ecosystem.

The central thesis is that safe local agent adoption requires runtime infrastructure that translates broad autonomy into bounded execution. By inserting a policy-aware boundary, AgentWall aims to:

• Provide developers with confidence and control over local agent actions.
• Make agent behavior auditable and transparent through structured tracing.
• Reduce the risk of accidental or adversarial damage without introducing excessive friction.

The authors argue that as agents move from text generation to active software execution, the gap between model output and machine action becomes a critical systems concern that cannot be solved by better models alone. AgentWall is presented as a practical step toward making local AI agents a trustworthy part of developer workflows.