Vanta donates AARM to the Cloud Security Alliance

Vanta has donated the Autonomous Action Runtime Management (AARM) system category specification to the Cloud Security Alliance (CSA). 

‍

The AARM specification defines a new system category: runtime security for AI agents.

‍

Today, agents do more than simply generate text. They call tools, mutate systems, and make decisions at machine speed. Traditional security tools weren't built for this: They can't understand agent intent, they can't reason over session context, and they can't tell the difference between an action that looks fine in isolation and one that's clearly wrong in context. 

‍

That gap demands a new type of system, one that intercepts agent actions before they execute, evaluates them against the full session context, and approves, modifies, defers, or denies them while maintaining the observability and audit trail that enterprise security teams actually need. 

‍

I coined AARM as the name for that system category through technical product research at Vanta. Naming a category is one thing, but making it durable is another. That requires the people building the systems and the practitioners using them to shape where it goes next. That's why we released the specification openly from day one in early February, and it's why we're donating it to CSA now. Already, 42 security companies listed in the AARM builder registry have independently reached the same conclusion: Agents need stronger runtime security around the actions they take. 

‍

AARM will be developed and stewarded going forward as part of both CSA and the newly-funded CSAI's “Securing the Agentic Control Plane” initiative. I'll continue leading the technical direction as Founding Co-Chair of the new AARM Working Group at CSA.

‍

What follows is a walkthrough of why system category specifications matter for emerging security markets, what an AARM-conformant system looks like under the hood—including its components, implementation architectures, and conformance tiers—how the ecosystem of Aligned and Conformant builders is taking shape, the agent-driven conformance program we're bringing to CSA, and what the partnership unlocks for the broader effort to secure the agentic control plane.

‍

Why a system category matters

AARM is a system category specification. That term carries weight in cybersecurity. System categories are how the industry organizes itself around a problem. They define what a class of system must do, give buyers a common vocabulary to evaluate vendors against, and give builders a shared target to converge on. Without a category, every vendor invents its own framing, every buyer compares apples to oranges, and the market stays fragmented for years longer than it needs to.

‍

There's more than one way a category gets defined. Some come from analysts. Gartner named SIEM in 2005 by combining two adjacent capabilities into a single class of system, and the entire security event management market organized itself around that label. Others come from communities. The FIDO Alliance defined modern passwordless authentication standards by bringing together vendors, identity providers, and enterprise practitioners around shared specifications. OAuth grew the same way through open working groups, rather than a single analyst's framework. 

‍

Both models work. What they share is that the category eventually outgrows whoever named it and becomes infrastructure that the whole industry builds on.

‍

Vanta has done this twice. We named “compliance automation” when we founded the company, defining a category that didn't exist before and that now has dozens of vendors competing in it. More recently, we named the “agentic trust management” platform, the category for how enterprises will manage trust as agents increasingly act on their behalf. 

‍

Naming categories is something we've learned to do carefully, because the goal isn't to plant a flag for marketing reasons. The goal is to give the industry a shared framework to organize around so the actual problem gets solved faster.

‍

Runtime security for AI-driven actions is a category that didn't exist as a named system class. The failure modes are real and already in production: prompt injection, confused deputies, intent drift, scope creep on over-privileged tool credentials. The controls we'd built for human-driven systems weren't designed for any of them. AARM defines what a runtime security system for AI agents must do, just as SIEM defines what a security event management system must do. And like the categories that came before it, AARM is being handed to the people who will actually shape what it becomes.

‍

What an AARM system actually looks like

An AARM-conformant system sits at the action layer, the boundary where an agent's reasoning becomes a tool call against an external system. You can find the full specification, threat model, and reference designs live at aarm.dev, but the shape of the system is worth understanding at a glance.

‍

The spec defines seven required components: 

‍

• The Action Mediation Layer intercepts every tool invocation and normalizes it into a canonical schema before anything executes
• The Context Accumulator maintains an append-only, hash-chained log of session state, including the original user request, prior actions, data accessed, and tool outputs, so every decision can be made against the full picture rather than a single isolated call
• The Policy Engine evaluates each action against both static policy and contextual intent alignment, classifying it as forbidden, context-dependent deny, context-dependent allow, or context-dependent defer
• The Approval Service handles step-up authorization for high-risk or ambiguous actions where a human needs to be in the loop
• The Deferral Service suspends actions when context is insufficient or conflicting, and resolves them once enough information exists to make a confident call
• The Receipt Generator produces cryptographically signed records, binding action, context, decision, and outcome, which is the artifact a forensic investigator needs to reconstruct what happened months later
• And the Telemetry Exporter pushes structured events into existing SIEM and SOAR pipelines, so AARM integrates with the rest of the security stack instead of becoming another silo

‍

Those components can be deployed across four reference architectures, each with different trust properties: 

‍

• A Protocol Gateway sits in front of the agent's tool protocol (MCP, for instance) and intercepts every call at the network boundary, offering high bypass resistance with limited context richness.
• SDK Instrumentation lives inside the agent's code, giving it full context but requiring code-level integration.
• Kernel / eBPF enforces at the host level with the strongest bypass resistance of any architecture, but cannot satisfy AARM conformance on its own. It lacks the semantic visibility needed for context-dependent decisions and must be deployed as a defense-in-depth backstop. 
• Vendor Integration uses governance hooks exposed by the agent platform itself, with the requirement that those hooks execute synchronously and before any side-effectful execution. Most production deployments end up combining architectures in layers, which is the recommended pattern.

‍

Conformance comes in two tiers: 

‍

• AARM Core (R1 through R6) covers the baseline runtime security guarantees: pre-execution interception, context accumulation, intent-aware policy evaluation, the five authorization decisions (allow, deny, modify, step-up, defer), tamper-evident receipts, and identity binding
• AARM Extended (R1 through R9) adds the operational maturity layer: semantic distance tracking for intent drift detection, structured telemetry export, and least-privilege credential enforcement

‍

The ecosystem: Aligned and Conformant

The Builders page at aarm.dev tracks the 42 companies currently shipping in the AARM problem space, organized into two statuses that reflect very different commitments. The strongest signal that AARM is solving a real problem is this builder community itself. These are the companies shipping the actual systems that secure agents in production today.

‍

AARM Aligned is self-declared. It signals that a company is building toward the AARM problem, runtime security for AI agents, and that their product addresses one or more aspects of what the spec defines. Aligned status is the entry point. It tells buyers a vendor is in the right category and thinking about the right failure modes, without making claims that haven't been verified.

‍

AARM Conformant is independently verified. To claim Conformant status, a system must satisfy the full conformance protocol against either AARM Core (R1–R6) or AARM Extended (R1–R9). The organization itself must also meet the surrounding requirements: active participation in the AARM community, a real production deployment serving customers, a recognized security certification (SOC 2 Type II, ISO 27001, FedRAMP), and a commitment to ongoing benchmarking. Conformant is the bar that enterprise buyers can actually procure against. Today, Noma Security, Runlayer, and Formal are the only companies to have achieved conformance to date.

‍

“AARM formalizes the architectural model we've been building Noma around since day one—securing agentic AI requires a control plane that operates at the content and behavior layer. The spec's core primitives—pre-execution interception, session-long context accumulation, and policy evaluation that combines static rules with contextual intent alignment—describe exactly how intent-based runtime protection has to work once swarms of agents are taking hundreds of consequential actions per minute on behalf of users.”

—Gal Moyal, Office of the CTO, Noma Security

‍

“Tools like OpenClaw show that scaling AI agents comes down to trust through visibility and control. Formal is that trust layer, and AARM conformance gives customers independent verification of that. Huge credit to Herman and the Vanta team for pushing this forward.“​​​​​​​​​​​​​​​​

-Mokhtar Bacha, CEO, Formal

‍

The pathway from Aligned to Conformant is the natural adoption funnel for the standard. As the ecosystem matures, watching companies move from one tier to the other will be one of the clearest signals of how the category is consolidating.

‍

“Most 'agent security' shipping today is theater. Slide-deck policies, controls no one can enforce, dashboards that prove nothing. AARM raised the floor. Intercept at runtime, enforce at the decision point, sign every receipt, or it doesn't count.”

—Tal Peretz, CTO, Runlayer

‍

Agent-driven conformance testing

When AARM first launched in February 2026, the conformance reviews were manual. I'd sit on calls with vendors, walk through each requirement, ask for evidence, and write up findings. It worked, but it didn't scale. With a working group north of 40 companies, the queue of vendors wanting their systems reviewed against the AARM spec was getting longer than the hours in a week.

‍

So we went agentic. We built an MCP server—a hosted AI tool that any vendor can connect to from Claude or another AI client and run themselves. The agent interviews them across the AARM requirements, the same way I would on a call. Every answer gets recorded against their organisation in a registry. The whole thing runs in about an hour instead of a half-day call.

‍

The risk with this kind of automation is the obvious one: Vendors might just answer "yes" to everything and walk away with a clean report. So we made the agent push back hard. If you say "we have that," it asks which policy, which system, and who owns it. If you can't show evidence, it tells you the honest answer is "no," and asks you to describe the gap. Every "yes" answer requires a screenshot or document you've actually shown the agent—verbal claims aren't enough. The server rejects vague evidence at the database level, so even if the agent slips up, the wall holds.

‍

The results so far have been encouraging. Vendors who started reviews thinking they were close to conformant ended up with honest gap lists they could actually act on. The agent is catching things human reviewers would catch, but in a fraction of the time. We're keeping the final sign-off in human hands—the working group still reviews every submission—but the heavy lifting of evidence collection and structured questioning has moved to the agent.

‍

This matters for buyers because the agent-security market is filling fast with vendors claiming "AARM-conformant" the way every product five years ago claimed "AI-powered." If conformance is self-attestation, that label is worthless. If it means a vendor sat through a rigorous interview, produced concrete evidence, and had their gaps recorded, the label becomes a signal you can actually use when comparing tools that govern your agents.

‍

We're going to keep experimenting. The next questions are interesting ones: Can the agent compare a vendor's evidence against past submissions to spot inconsistencies? Can it flag patterns that the working group should pay attention to? Conformance has been a slow, manual ritual for as long as software has had standards. AI gives us a chance to make it faster without making it weaker.

‍

Why CSA, and why now?

A system category specification only works if implementers, buyers, and competitors all believe it will remain stable, neutral, and well-governed for the long term. That belief is what turns a spec from a research artifact into infrastructure. Building that belief requires a permanent, neutral governing body with the authority to maintain the specification, run conformance programs, and bring the industry together at one table.

‍

CSA is the right home for AARM. It’s the most recognized standards body in cloud security, with a track record on frameworks like the AI Controls Matrix and STAR for AI that the enterprise market already trusts. CSA has the global community of practitioners and vendors needed to evolve a specification at the pace this category demands. 

‍

And with the launch of the CSAI Foundation and its 2026 mission of “Securing the Agentic Control Plane,” AARM slots cleanly into a broader programmatic effort to govern identity, authorization, orchestration, runtime behavior, and trust assurance across autonomous AI systems. AARM is the runtime piece of that picture, and CSA is building the rest of it in parallel.

‍

“AI agents operate in a way that challenges many of our preconceived notions about how computer systems can fail and should be secured. AARM is a well-thought-out articulation of the dimensions we must consider for agentic runtime execution assurance, and is an excellent addition to our portfolio to secure the agentic control plane."

— Jim Reavis, CEO, Cloud Security Alliance.

‍

What's next for AARM

AARM is being formally introduced to the industry at CSA's Agentic AI Security Summit 2026. From here, the focus shifts to standing up the AARM working group under CSA governance, expanding membership across practitioners, end-users, and vendors, and operationalizing the conformance program (the agent included) so that Conformant status carries the weight of a CSA-administered audit. 

‍

If you're building runtime security for agents, deploying agents in production, or evaluating vendors in this category, the spec is at aarm.dev, and the working group is the place to plug in.

‍

Specifications don't get written alone. AARM exists in its current form because of the technical working group that shaped it. A special thank-you to Phil Venables, whose mentorship and guidance throughout this work have been formative for how AARM is structured and where it's headed. And to the rest of the TWG: Ken Huang, Anthony Scarfe, Camille Stewart Gloster, Hema Kak Kalsi, Alex Foley, Kavya Pearlman, Krti Tallam, Matthew Rosenquist, Prasenjit Sinha, Saikiran Rallabandi, Shanita Sojan, and Akul Loomba. AARM is a much better specification because of all of you.