AARM: For Securing AI Agents at Runtime
AARM: For Securing AI Agents at Runtime is a Cloud Security Alliance Agentic AI Summit session by Herman Errico of Vanta. It introduces Autonomous Action Runtime Management as a proposed system category for AI-agent runtime security. The useful move is categorical: instead of asking only what the model said, who authenticated, or which firewall rule matched, AARM asks whether a proposed agent action should execute now, in this context, for this stated intent.
The core argument is that agent security becomes action security once systems call tools, write files, mutate databases, issue network requests, or communicate externally. A prompt filter can reduce bad text. A SIEM can collect events after the fact. IAM can confirm that some identity has permission. None of those alone proves that this specific action is aligned with the user's original task after several tool calls, retrieved documents, and intermediate outputs have changed the state of the session. That is why this session belongs beside the limits of traditional IAM for agents, CISO agent control, AI Agent Identity, Prompt Injection, and Confused Deputy Problem.
The strongest part of the presentation is the decision model. AARM is not just "allow or deny." The AARM specification defines a control plane that intercepts agent actions before execution, accumulates session context, evaluates policy with intent alignment, and records each decision. Its five authorization decisions are allow, deny, modify, step up to human approval, or defer until more context is available. That gives security teams a more realistic vocabulary for agents: some actions are forbidden, some are context-dependent, some need transformation, and some should pause until a human or another signal resolves ambiguity.
The conformance requirements make the concept operational. AARM Core requires pre-execution interception, context accumulation, policy evaluation with intent alignment, five decision types, tamper-evident receipts, and identity binding. AARM Extended adds semantic drift tracking, telemetry export, and least-privilege enforcement. The point is not that every product must look the same. The point is to set a baseline for evaluating claims across protocol gateways, SDK instrumentation, kernel or eBPF hooks, and vendor-native integrations. That maps cleanly to the site's Agent Tool Permission Protocol, AI Agent Observability, AI Audit Trails, Agent Audit and Incident Review, and enterprise MCP security.
The CSA context matters because category names can harden into markets before anyone agrees what minimum security means. CSA's AARM Working Group describes the effort as a vendor-neutral specification for securing AI-driven actions at runtime. The accompanying arXiv paper frames action execution as the stable security boundary and names threats including prompt injection, confused deputy attacks, data exfiltration, and intent drift. CSA's own blog is appropriately cautious: AARM does not solve every problem, but it gives practitioners a structure for talking about runtime governance while agents are operating.
Evidence and limits: this is a founder-authored summit talk about a specification that Vanta later donated to CSA, not an independent benchmark of AARM-conformant products. The Vanta announcement is useful context for the transition to CSA, but it is still a vendor-authored source. The review value is therefore architectural rather than evidentiary. AARM is strongest as a checklist for buyers and builders: intercept before execution, preserve context, bind identity, evaluate intent, produce receipts, export telemetry, and avoid fail-open shortcuts. The hard work is proving coverage across real agents, opaque SaaS tools, long-horizon workflows, and adversarial environments where the agent, the tool output, or the orchestration layer may be compromised.