Resource / Definition

What is AARM?

AARM (Autonomous Action Runtime Management) is the Cloud Security Alliance system-category specification for agentic runtime security: it defines what an agent security system must do to govern what an AI agent is allowed to do at runtime, before the action executes. Buyers use it to compare gateways and control planes against a shared bar instead of a vendor feature list.

Scroll for definition
Nolan Sullivan headshotBy Nolan Sullivan, Founding Growth Engineer
Published
Definition

AARM

AARM (Autonomous Action Runtime Management) is the Cloud Security Alliance system-category specification for agentic runtime security: it defines what an agent security system must do to govern what an AI agent is allowed to do at runtime, before the action executes. It is a specification rather than a product; buyers use it to compare gateways and control planes against a shared bar (intercept, evaluate, decide, record) instead of a vendor feature list.

Agentic runtime securityDefinitionSpeakeasy

An AI agent can draft a response without touching a production system. When it calls create_refund, writes a file, or sends data to an external API, the security decision is whether that action may run. AARM defines the runtime requirements for an AI control plane that makes that decision before the action reaches its target.

The specification is AARM v1.0, published in February 2026 under the Cloud Security Alliance (CSA) Technical Working Group, authored by Herman Errico, archived as arXiv:2602.09433, and licensed CC BY 4.0. The CSA AARM Working Group develops the specification, and its source is public on GitHub.

Runtime carries a specific meaning in the spec. The controls operate on the action an agent is about to take, the API call, file write, shell command, or network request, and they operate before it reaches the target system. A filter that inspects model output after generation is not runtime management under this definition, because by then the consequential thing has already happened or is already in flight.

What is the AARM agent runtime security model?

The spec’s abstract identifies the shift. As AI systems evolve from advisory tools into agents that take consequential actions, the security boundary moves from model outputs to tool execution. A response filter can evaluate generated text, but it does not sit in the path of an API call. Why the rest of the existing security stack misses this layer is mapped in AI security.

AARM names an agent runtime security layer. The control plane sits between the agent and everything it can affect, through which every agent-initiated action passes and where each one is intercepted, evaluated, decided on, and recorded before execution, regardless of the model, framework, or environment behind it.

What are the AARM Core and Extended requirements?

The spec defines nine requirements, R1 through R9, using RFC 2119 keywords. The six MUST requirements form AARM Core, the baseline for any conformance claim. Adding the three SHOULD requirements on top forms AARM Extended.

The six Core requirements:

  • R1, pre-execution interception. Every agent-initiated action is intercepted before it executes, with no path around the control plane.
  • R2, context accumulation. The system maintains the agent’s stated intent, its prior actions, and the task thread, and makes that context available at decision time.
  • R3, policy evaluation with intent alignment. Each action is evaluated against policy that considers both the action itself and whether it aligns with the agent’s stated intent, so no action is judged in isolation.
  • R4, five authorization decisions. The policy engine can return ALLOW, DENY, MODIFY (execute a transformed version of the action), STEP_UP (require human approval first), or DEFER (delay pending more context).
  • R5, tamper-evident receipts. Every evaluated action produces a verifiable receipt recording the action, the decision, the timestamp, and the policy context used.
  • R6, identity binding. Every receipt is cryptographically bound to a verifiable agent identity, supporting non-repudiation.

The three Extended requirements:

  • R7, semantic distance tracking. The system tracks how far proposed actions have drifted from the agent’s original stated intent over long task horizons.
  • R8, telemetry export. Action telemetry exports in a standard, interoperable format such as OpenTelemetry for SIEM ingestion; a proprietary-only export format does not satisfy the requirement. The distinction between engineering telemetry and identity-bound audit is covered in the agent observability platform comparison.
  • R9, least-privilege enforcement. Credentials are scoped to the minimum each action needs at execution time, not granted session-wide or system-wide. Task-scoped credentials are one implementation of that pattern.
AARM pre-execution decision flowAn agent proposes an action. The AARM control plane accumulates task context, evaluates policy and intent alignment, returns one of five decisions, and creates a tamper-evident action receipt before an allowed action reaches a tool.AARM · RUNTIME DECISION FLOWGovern the action before it runsR1–R6 form AARM CoreAGENTProposed actioncreate_refund()AARM CONTROL PLANER1–R2 · intercept and accumulate contextintent, prior actions, and the task threadR3 · evaluate policy and intent alignmentthe action is evaluated in its task contextR4 · ALLOW · DENY · MODIFY · STEP_UP · DEFERTOOL OR APIExecutes onlyafter ALLOWR5–R6 · ACTION RECEIPTDecision, timestamp, policy context, and bound identity

Which threat classes does AARM address?

The threat model enumerates eleven classes, T1 through T11. A conformant implementation must address all of them. For buyers, the list becomes a set of coverage questions for every product evaluation:

  • Instruction and goal attacks. Prompt injection (T1), confused deputy (T2), goal hijacking (T4), memory poisoning (T5), environmental manipulation (T10), and malicious tool output (T11).
  • Access and data exposure. Data exfiltration (T3), over-privileged credentials (T8), and side-channel leakage (T9).
  • Long-running and multi-agent risks. Intent drift (T6) and cross-agent propagation (T7).

For each class, ask which AARM requirement the product uses to address it and what evidence supports that claim.

What are AARM’s four implementation architectures?

The spec is implementation-neutral and recognizes four architectures, each with its own trust trade-off:

  • Protocol gateway. A proxy on the network path between agents and tools that intercepts traffic at the protocol level. Strong isolation guarantees, at the cost of routing all agent traffic through it.
  • SDK instrumentation. Interception integrated into the agent framework’s SDK. Lower deployment friction, but it only sees actions that pass through instrumented paths.
  • Kernel eBPF. Kernel-level hooks on the system calls agent processes make. Difficult for an agent to bypass, and it requires elevated privileges and kernel compatibility.
  • Vendor integration. The AI platform or tool vendor provides interception natively in its own API surface. The lowest friction, with coverage that depends entirely on the vendor.

Speakeasy’s public architecture is the protocol gateway: an MCP gateway on the path between agents and the Model Context Protocol (MCP) servers they call, so interception happens at the protocol level before a tool call reaches the server.

What do AARM Core, Extended, and Aligned mean?

A conformance claim is reviewed rather than self-declared. Claiming Core means satisfying R1 through R6. Claiming Extended means satisfying all nine. Either way, the vendor compiles an evidence package for each requirement, operates the system in production with real agent workloads, and submits the package to the AARM Technical Working Group, which reviews it and publishes a conformance report, with up to 14 days allowed for the review.

The builder registry records three statuses. Core and Extended mean a completed formal review at that level. Aligned means the company builds in the same problem space and has not completed one. The registry changes as builders join and complete reviews. At the time of writing, it identifies Runlayer as Extended and MintMCP as Core.

Speakeasy is listed on the registry as Aligned and has not completed a formal conformance review. For readers weighing registry status alongside product fit, the comparisons with those two conformant vendors are at Speakeasy vs Runlayer and Speakeasy vs MintMCP.

How is AARM different from ISO 27001 and ISO 42001?

ISO 27001 and ISO 42001 are management-system standards. An auditor certifies how an organization runs its information security or AI management program. AARM specifies what a runtime system does to an individual action before it executes, so the standards answer different questions and neither substitutes for the other. What each ISO standard asks of an agentic deployment is covered in ISO 27001 for agentic AI and ISO 42001 for agentic AI.

How do you evaluate agent runtime security products against AARM?

Use the registry to identify products, then examine their evidence. Compare documented behavior with R1 through R9:

  • Interception and context. Does the product catch every in-scope action before execution, and does its policy decision use the task and prior-action context?
  • Decision and record. Which authorization outcomes can it return, and can it show that its action records are tamper-evident?
  • Identity and least privilege. How does it bind actions to an agent identity, scope credentials, export telemetry, and detect intent drift?

Speakeasy is listed as Aligned rather than Core or Extended. The registry says that Aligned builders operate in the same problem space; it does not establish conformance. A Core or Extended claim requires the working group to review an evidence package. That distinction is useful for any vendor evaluation: separate documented product capabilities from a completed conformance review.

To evaluate the gateway against the nine requirements on your own agent traffic, talk to us.

Frequently asked questions

What is AARM?

AARM (Autonomous Action Runtime Management) is the Cloud Security Alliance system-category specification for agentic runtime security. It defines what an agent security system must do to govern what an AI agent is allowed to do at runtime, before the action executes: intercept every agent-initiated action, evaluate it against policy and the agent's stated intent, return a decision, and record a tamper-evident receipt. Version 1.0 was published in February 2026 by the CSA Technical Working Group.

Is AARM a product?

No. AARM is a specification, published under CC BY 4.0, that defines what a runtime security system must do rather than how to build one. Vendors implement it in products such as gateways and control planes, and buyers use it to evaluate those products against a shared set of requirements instead of a vendor's own feature list.

What is the difference between AARM Core and AARM Extended?

AARM Core requires the six MUST requirements, R1 through R6: pre-execution interception, context accumulation, policy evaluation with intent alignment, five authorization decisions, tamper-evident receipts, and identity binding. AARM Extended requires all nine, adding the three SHOULD requirements: semantic distance tracking, telemetry export in a standard format, and least-privilege credential scoping at action time. Core is the baseline for any conformance claim, and Extended indicates a more mature implementation.

Does Speakeasy conform to AARM?

Speakeasy is listed on the AARM builder registry as Aligned, which means it builds in the agentic runtime security space and has not completed a formal conformance review. Core and Extended status require an evidence package reviewed by the AARM working group, which Speakeasy has not completed.

How is AARM different from ISO 27001 and ISO 42001?

ISO 27001 and ISO 42001 are management-system standards: an auditor certifies how an organization runs its information security or AI management program. AARM is a runtime specification that defines what a system must do to each agent action before it executes. An organization can hold both ISO certificates and still have no runtime interception, so the standards answer different questions rather than substituting for each other.

Does AARM require an MCP gateway?

No. The specification is implementation-neutral and recognizes four architectures: protocol gateway, SDK instrumentation, kernel eBPF, and vendor integration. An MCP gateway is the protocol gateway pattern applied to the Model Context Protocol, the path most enterprise agents take to tools, but a conformant system can also intercept actions in the agent framework's SDK, at the kernel, or natively inside the AI platform vendor's own surface.

AI everywhere.

Control here.

Talk to usLearn more