Description
AARM operates at the OS level using eBPF (Extended Berkeley Packet Filter) and LSM (Linux Security Modules) hooks to intercept system calls made by agent processes. This provides visibility into all I/O operations regardless of how the agent invokes them.
┌──────────────────────────┐
│ Agent Process │
│ (User Space) │
└────────────┬─────────────┘
│ syscall
▼
┌──────────────────────────┐
│ AARM eBPF Hooks │
│ (Kernel Space) │
└────────────┬─────────────┘
│ allow/deny
▼
┌──────────────────────────┐
│ System Calls │
│ (Network, File, Process)│
└──────────────────────────┘
Kernel-level (eBPF/LSM) implementations alone cannot satisfy AARM conformance for context-dependent allow, deny, or defer classifications. These require semantic understanding of actions and accumulated session context — information fundamentally unavailable at the syscall level.An eBPF-only deployment can enforce forbidden actions (static rules on IPs, file paths, syscalls) but cannot evaluate intent alignment, compositional violations, or context sufficiency.eBPF implementations SHOULD be positioned as defense-in-depth backstop layers alongside semantic-aware architectures (Gateway, SDK, or Vendor Integration). Vendors must not claim AARM compliance based solely on kernel-level monitoring.
Trust Properties
| Property | Value |
|---|
| Enforcement point | Kernel level — all syscalls pass through eBPF hooks |
| Bypass risk | Lowest of any architecture — requires kernel exploit to evade |
| Semantic visibility | Limited — sees connect(), write(), open(), not “send email” |
| Context access | None — no visibility into agent reasoning, user request, or session |
Action Classification Support
| Classification | Support | Notes |
|---|
| Forbidden | ✅ Strong | Block malicious IPs, sensitive file paths, dangerous syscalls |
| Context-Dependent Deny | ⚠️ Weak | Cannot correlate with application context without external integration |
| Context-Dependent Allow | ❌ Not feasible | Intent alignment requires semantic understanding |
| Context-Dependent Defer | ⚠️ Limited | Can flag for deferment but cannot resolve — requires higher-level layers |
When to Use
- Maximum bypass resistance is required
- Agent code cannot be modified
- Comprehensive syscall visibility needed for compliance
- Forbidden action enforcement is the primary concern
- As a backstop layer alongside other architectures
When Not to Use
- Context-dependent evaluation is critical (use Gateway or SDK as primary)
- Intent drift detection is a priority
- Agent runs on infrastructure you do not control (SaaS)
- Windows environments (eBPF not available without WSL2)
