Skip to main content

Documentation Index

Fetch the complete documentation index at: https://aarm.dev/llms.txt

Use this file to discover all available pages before exploring further.

​
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)│
└──────────────────────────┘
This follows the host-based security pattern of Falco, Sysdig, and Cilium: kernel-level observation that cannot be bypassed by user-space code.

​
Conformance Limitation

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

PropertyValue
Enforcement pointKernel level — all syscalls pass through eBPF hooks
Bypass riskLowest of any architecture — requires kernel exploit to evade
Semantic visibilityLimited — sees connect(), write(), open(), not “send email”
Context accessNone — no visibility into agent reasoning, user request, or session

​
Action Classification Support

ClassificationSupportNotes
Forbidden✅ StrongBlock malicious IPs, sensitive file paths, dangerous syscalls
Context-Dependent Deny⚠️ WeakCannot correlate with application context without external integration
Context-Dependent Allow❌ Not feasibleIntent alignment requires semantic understanding
Context-Dependent Defer⚠️ LimitedCan 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)