What is AARM? Autonomous Action Runtime Management, explained
AARM (Autonomous Action Runtime Management) is an open specification from the Cloud Security Alliance for securing AI-driven actions at runtime. Instead of only controlling which systems an agent can access, AARM frames security around the action itself, evaluated across four dimensions: context, policy, intent, and behavior. It is one of the first attempts by a standards body to name and structure the layer where autonomous agents actually create risk: the moment they act.
Where AARM came from
The Cloud Security Alliance is the industry body whose cloud security guidance and shared-responsibility frameworks became the default language of cloud procurement over the past decade. In 2026 its agentic AI work produced two anchor documents: an Agentic Trust Framework applying zero-trust principles to autonomous agents, and AARM, the runtime-action specification. The motivating observation is the same one driving the whole category: identity and access controls decide whether an agent may act, and nothing standard decides whether a given action should proceed.
That gap is not theoretical. A March 2026 study, Before the Tool Call, found no standard authorization layer at the tool-call boundary and reported that 27.2% of engineering teams had abandoned framework-provided controls in favor of hardcoded, hand-rolled checks.
The four dimensions
- Context. What situation is the action happening in: which customer, which conversation, which prior commitments, which channel. An 18% discount means something different in a renewal negotiation than in a cold outbound message.
- Policy. The explicit rules the action must satisfy: authority limits, forbidden commitment types, required language, blocked topics. Policy is the part a business can actually write down, version, and show an auditor. Structuring it is covered in writing commercial policies for AI agents.
- Intent. What the action is trying to accomplish, and whether that goal is one the agent is authorized to pursue. A message that technically violates no rule can still pursue an unauthorized goal.
- Behavior. The pattern of actions over time: velocity, repetition, escalation, drift. One approved refund is fine; forty in an hour from the same agent is a behavioral signal no single-action check sees.
What AARM means in practice
For teams deploying agents, the spec's near-term value is as a checklist shape. A runtime action control that holds up under AARM's framing looks like this:
- Actions are intercepted before execution, not sampled after.
- An explicit, versioned policy is evaluated against the action's actual content.
- The decision space is richer than pass/fail: approve, transform, escalate to a human, or refuse.
- Every decision produces a durable record: what was checked, what was found, what was decided.
Readers who have seen EvalLayer's authorization layer will recognize the shape: policy in, one of four decisions out (allow, rewrite, require_approval, block), violations named, audit record stored. That convergence is not a coincidence; it is what happens when a standards body and a product team stare at the same incidents.
What to do about it now
Nobody fails an AARM audit in 2026, because formal AARM audits do not exist yet. The practical move is the same one that preceded every prior compliance wave: adopt the substance early, cheaply, while it is an engineering decision instead of a remediation project. Put a pre-action gate in front of consequential agent actions, write the policy down, keep the records. When the questionnaires start referencing the spec by name, the answer is already running in production. The governance framework covers how these controls map to the compliance conversations that already exist today.