| title | Autonomous Action Runtime Management (AARM) |
|---|---|
| description | AARM is an open system category specification for securing AI-driven actions at runtime. Build systems that intercept, authorize, and audit autonomous actions before they execute. |
Autonomous Action Runtime Management (AARM) is an open system specification for securing AI-driven actions at runtime. It defines what a runtime security system must do — not how to build it. An AARM system intercepts AI-driven actions before execution, accumulates session context including prior actions and data accessed, evaluates actions against organizational policy and contextual intent alignment, enforces authorization decisions (allow, deny, modify, defer, or require approval), and records tamper-evident receipts binding action, context, decision, and outcome for forensic reconstruction.
AARM is not a product, library, or service you install. It is a specification that describes the components, behaviors, and conformance requirements for systems that secure AI agents. You use AARM to design and build your own runtime security system, or to evaluate whether existing solutions meet the specification.
The security posture of AI systems is increasingly determined not by what models say but by what they do. Traditional security paradigms fail to address five characteristics of AI-driven actions:
| Characteristic | Why It Matters |
|---|---|
| Irreversibility | Tool executions produce permanent effects. Once a database is dropped or data exfiltrated, the damage is done. |
| Speed | Agents execute hundreds of actions per minute — far beyond human review capacity. |
| Compositional risk | Individual actions may satisfy policy while their composition constitutes a breach. |
| Untrusted orchestration | Prompt injection and indirect attacks mean the AI layer cannot be trusted as a security boundary. |
| Privilege amplification | Agents operate under static, high-privilege identities misaligned with least privilege. Small reasoning failures produce large-scale impact. |
Existing tools don't solve this:
- SIEM observes events after execution — too late to prevent harm
- API gateways verify who is calling, not what the action means
- Firewalls protect perimeters — but agents operate inside with legitimate credentials
- Prompt guardrails filter text, not actions — and are easily bypassed
- Human-in-the-loop doesn't scale, and can itself be exploited
- IAM / RBAC evaluates permissions in isolation — cannot detect compositional threats
These systems primarily support automated response: deterministic enforcement of pre-specified rules. They do not support autonomous response, in which a system reasons over accumulated context to decide whether an action should be permitted, modified, delayed, or blocked.
The gap lies at the intersection of prevention and context-awareness. AARM fills this gap.
AARM recognizes that security decisions aren't binary. Actions fall into four categories:
Always blocked regardless of context. Hard policy limits defined by the organization. Allowed by policy, but blocked when context reveals inconsistency with the user's stated intent. Denied by default, but permitted when context confirms alignment with legitimate intent. Temporarily suspended when available context is insufficient, ambiguous, or conflicting for a confident decision.| Category | Example | Evaluation |
|---|---|---|
| Forbidden | DROP DATABASE production, send to known malicious domains |
Static policy → DENY |
| Context-Dependent Deny | Agent can send emails, but just read sensitive data and recipient is external | Policy ALLOW + context mismatch → DENY |
| Context-Dependent Allow | Agent wants to delete records; context shows user explicitly requested cleanup of their own test data | Policy DENY + context match → STEP_UP or ALLOW |
| Context-Dependent Defer | Agent initiates credential rotation outside maintenance window; context is ambiguous | Policy indeterminate → DEFER until resolved |
This is why AARM requires both static policy evaluation and context accumulation. An action that looks fine in isolation might be a breach in context. An action that looks dangerous might be exactly what the user asked for. And some actions simply cannot be resolved into a binary allow/deny without additional assurance.
Detailed classification framework with examples and evaluation logicA system conforming to AARM:
Captures AI-driven actions before they reach target systems Tracks session state: the user's original request, prior actions, data accessed, and tool outputs — in a tamper-evident, append-only log Assesses the action against static policy *and* contextual alignment with stated intent Implements one of five authorization decisions: allow, deny, modify, defer, or require human approval Generates tamper-evident receipts capturing action, context, decision, and outcome<img src="/images/aarm-system-diagram.png" alt="AARM System Architecture" style={{ maxWidth: "100%", height: "auto" }} />
AARM addresses eleven attack vectors specific to AI-driven actions:
Malicious instructions hijack agent behavior via direct or indirect injection Adversarial tool responses manipulate subsequent agent reasoning Agents misuse legitimate credentials under manipulation Excessive token scopes amplify the blast radius of compromise Compositional attacks extract sensitive data across individually-permitted actions Injected objectives alter the agent's planning and prioritization Agent reasoning gradually diverges from user intent without adversarial input Persistent context manipulation corrupts future decision-making Compromised agents escalate or delegate through multi-agent workflows Sensitive data leaks through logs, debug traces, or API metadata Adversaries alter system state to influence agent decisions Full threat summary table, attack lifecycle, and trust assumptionsAn AARM-compliant system implements these components:
Intercepts tool invocations and normalizes to canonical schema Tracks session state in an append-only, hash-chained log Evaluates actions against static policy and contextual intent alignment Human-in-the-loop for high-risk or ambiguous actions (STEP_UP) Manages temporarily suspended actions pending additional context (DEFER) Signed records binding action, context, decision, and outcome Structured events for SIEM/SOAR integration Full component architecture with data flow diagramsAARM defines four implementation architectures, each with distinct trust properties:
| Architecture | You Control | Bypass Resistance | Context Richness | Defer Support | AARM-Conformant Alone |
|---|---|---|---|---|---|
| Protocol Gateway | Network | High | Limited | Partial | Yes |
| SDK / Instrumentation | Code | Medium | Full | Full | Yes |
| Kernel / eBPF | Host | Very High | None | Limited | No |
| Vendor Integration | Policy only | Vendor-dependent | Vendor-dependent | Limited–Moderate | If hooks sufficient |
For defense-in-depth, organizations should deploy multiple architectures in layers.
When to choose each architecture based on your control level Combining architectures for redundant enforcementTo claim AARM compliance, a system must satisfy these requirements:
| ID | Level | Requirement |
|---|---|---|
| R1 | MUST | Pre-execution interception — block or defer actions before execution |
| R2 | MUST | Context accumulation — track prior actions, data classifications, original request |
| R3 | MUST | Policy evaluation with intent alignment — forbidden, context-dependent deny/allow/defer |
| R4 | MUST | Five authorization decisions — ALLOW, DENY, MODIFY, STEP_UP, DEFER |
| R5 | MUST | Tamper-evident receipts — cryptographically signed with full context |
| R6 | MUST | Identity binding — human, service, agent, session, and role/privilege scope |
| R7 | SHOULD | Semantic distance tracking — detect intent drift via embedding similarity |
| R8 | SHOULD | Telemetry export — structured events to SIEM/SOAR platforms |
| R9 | SHOULD | Least privilege enforcement — scoped, just-in-time credentials |
AARM Core (R1–R6): Baseline runtime security guarantees. AARM Extended (R1–R9): Comprehensive runtime security with operational maturity features.
Detailed requirements with verification criteria How to verify your implementation conformsAARM addresses runtime action security, but several challenges remain open:
Can we build reliable intent classifiers for agent actions? How to track data lineage through non-deterministic LLM transformations? Coherent authorization across distributed agent boundaries Balancing safety against operational usability Industry-wide governance hook standards for SaaS agents Protecting the security system itself as a high-value target Full research directions with open questionsStudy the [threat model](/threats/overview) to understand what attacks your system must defend against — all eleven threat categories. Build the [core system components](/components/overview): action mediation, context accumulator, policy engine with intent evaluation, approval service, deferral service, receipt generator, and telemetry exporter. Select an [implementation architecture](/architectures/overview) based on your control level: protocol gateway, SDK instrumentation, kernel eBPF (as backstop), or vendor integration. Test your implementation against the [conformance requirements](/conformance/requirements) (R1–R9) using the [testing protocol](/conformance/testing).
Once you understand the specification, the Guides tab provides practical implementation help:
Implement basic AARM patterns step by step Learn policy syntax by writing common rules Build a protocol-level proxy for MCP tools Implement step-up authorization with Slack/email Implement deferral workflows with progressive context collection Cryptographic receipt generation and offline verificationThe market for AI agent security is emerging rapidly, with multiple vendors building proprietary solutions. AARM aims to:
Define requirements before fragmentation forecloses interoperability Let buyers objectively assess vendor claims against defined criteria Specify what systems must do, not how they must be built Provide implementation guidance, not just principlesThe goal is not to build AARM, but to define what an AARM-conformant system must do — enabling the market to compete on implementation quality rather than category definition.
AARM is an open specification. We welcome contributions from security researchers, agent framework developers, and enterprise practitioners.
Specification source, issues, and discussionsIf you reference AARM in academic or professional work:
Errico, H. "Autonomous Action Runtime Management (AARM):
A System Specification for Securing AI-Driven Actions at Runtime."
AARM Specification v0.1, 2025. https://aarm.dev