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. Build systems that intercept, authorize, and audit autonomous actions before they execute.

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. 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 four characteristics of AI-driven actions:

• 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

An AARM system is built to:

1. Intercept AI-driven actions before they reach target systems
2. Accumulate Context Track session state, prior actions, data accessed, and intent
3. Evaluate Assess actions against static policy and contextual intent alignment
4. Enforce Implement authorization decisions: allow, deny, modify, or require approval
5. Record Generate tamper-evident receipts for forensic reconstruction

┌─────────────────┐         ┌─────────────────────────────────┐         ┌─────────────────┐
│                 │         │          AARM SYSTEM            │         │                 │
│  Agent / LLM    │ ──────► │  ┌─────────────────────────┐   │ ──────► │  Tools / APIs   │
│                 │  action │  │    Context Accumulator  │   │  allow  │                 │
│                 │         │  └────────────┬────────────┘   │   or    │                 │
│                 │ ◄────── │               ▼                │ ◄────── │                 │
│                 │  result │  ┌─────────────────────────┐   │  result │                 │
└─────────────────┘         │  │     Policy Engine +     │   │         └─────────────────┘
                            │  │   Intent Evaluation     │   │
                            │  └────────────┬────────────┘   │
                            │               ▼                │
                            │  ┌─────────────────────────┐   │
                            │  │   Receipts (+ context)  │   │
                            │  └─────────────────────────┘   │
                            └─────────────────────────────────┘

AARM recognizes that security decisions aren't binary. Actions fall into three categories:

Always blocked regardless of context. Hard policy limits defined by the organization.

• Example: DROP DATABASE production, send to known malicious domains
• Evaluation: Static policy → DENY

Allowed by policy, but blocked when context reveals inconsistency with the user's stated intent.

• Example: Agent can send emails, but just read sensitive data and recipient is external
• Evaluation: Policy ALLOW + context mismatch → DENY

Denied by default, but permitted when context confirms alignment with legitimate intent.

• Example: Agent wants to delete records; context shows user explicitly requested cleanup of test data
• Evaluation: Policy DENY + context match → STEP-UP or ALLOW

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.

An AARM-compliant system implements these six components:

Intercepts tool invocations and normalizes them to a canonical schema, enabling policy evaluation against a consistent format.

Tracks session state throughout an agent's execution: the user's original request, prior actions executed, data accessed, tool outputs, and intermediate model responses.

Evaluates actions against static policy rules and contextual intent alignment. Makes binary authorization decisions: allow, deny, modify, or require approval.

Human-in-the-loop mechanism for high-risk or ambiguous actions. Handles timeouts, multi-reviewer workflows, and escalation chains.

Cryptographically signed records binding action, context, policy decision, and outcome. Enables forensic reconstruction and compliance audit trails.

Structured events exported to SIEM/SOAR platforms for security monitoring and incident response.

AARM can be implemented through three architectures, each with distinct trust and integration properties:

For maximum security, organizations may deploy multiple architectures in layers.

To claim AARM compliance, a system must satisfy these nine requirements:

AARM addresses specific attack vectors unique to AI-driven actions:

• Prompt Injection: Malicious instructions hijack agent behavior
• Confused Deputy: Agents misuse legitimate credentials under manipulation
• Data Exfiltration: Compositional attacks extract sensitive data through seemingly legitimate actions
• Intent Drift: Agent behavior diverges from user's stated intent over time

1. Read the Introduction — Understand the problem and why existing tools fail
2. Study the Threat Model — Learn what attacks your system must defend against
3. Review System Components — Understand the architecture
4. Choose an Architecture — Select your implementation path

1. Implement Core Components — Build the action mediation, context accumulator, policy engine, approval service, receipt generator, and telemetry exporter
2. Select Architecture — Choose protocol gateway, SDK instrumentation, or kernel-level eBPF based on your trust requirements
3. Write Policies — Define forbidden actions, context-dependent rules, and approval workflows
4. Verify Conformance — Test against R1–R9 requirements using the conformance testing protocol

• Quickstart — Implement basic AARM patterns step by step
• First Policy — Learn policy syntax by writing common rules
• MCP Gateway Pattern — Build a protocol-level proxy for MCP tools
• Approval Flows — Implement step-up authorization with Slack/email

The market for AI agent security is emerging rapidly, with multiple vendors building proprietary solutions. AARM aims to:

• Establish Baseline — Define requirements before fragmentation forecloses interoperability
• Enable Evaluation — Let buyers objectively assess vendor claims against defined criteria
• Preserve Choice — Specify what systems must do, not how they must be built
• Accelerate Adoption — Provide implementation guidance, not just principles

The 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 grounded in academic research on AI agent security:

• Technical Paper — Full specification with formal definitions and threat analysis
• Research References — Literature on agent security, prompt injection, and runtime protection

AARM is an open specification. We welcome contributions from security researchers, agent framework developers, and enterprise practitioners.

• GitHub Repository — Specification source, issues, and discussions
• Report an Issue — Found a problem? Let us know
• Suggest Changes — Submit improvements or clarifications

This specification is published under the MIT License. Reference implementations and tooling may use different licenses.

• 🌐 Full Specification
• 📋 Conformance Requirements
• 🔒 Threat Model
• 🏗️ System Architecture
• 📚 Implementation Guides
• 📄 Research Paper

AARM is foundational infrastructure for AI agent security. Like OAuth for API security, AARM establishes what runtime security systems must do—enabling the ecosystem to build, compete, and innovate.