How Containment.ai aligns with AARM — requirement by requirement.
This is the spec-level reference: what AARM v1.0 requires, its decision verbs, and exactly where our coverage matches the standard and where it does not. Containment.ai aligns with AARM's Protocol Gateway pattern at the LLM-call boundary — delivered through our connected tier proxy and, at the highest-assurance end, the flagship in-path Mission Authorization Gateway — and adds the data-layer detection vocabulary the spec leaves open. For the product overview and the buyer's-eye view of runtime agent governance, start with the canonical AARM page.
This is the in-depth alignment reference. The canonical product page is products/aarm.html — the buyer-facing overview of how Containment.ai delivers runtime agent governance and aligns with AARM.
Why AARM matters
The agentic-AI governance gap, the specification that closes it, and where Containment.ai fits.
What AARM is
AARM (Autonomous Action Runtime Management) is the Cloud Security Alliance's open specification for governing autonomous AI agents at runtime. Authored at Vanta and donated to the CSAI Foundation in April 2026, AARM is governed by a working group including Microsoft, Vanta, Noma Security, Zenity, Elastic, Truist, and Darktrace. The spec defines nine requirements: every agent action MUST be intercepted before execution, evaluated against policy with full context, and logged in tamper-evident form. AARM also defines four reference architectures — Protocol Gateway, SDK Instrumentation, Kernel / eBPF Hooks, and Vendor-Native Integration.
Why it matters for enterprise buyers
GRC platforms document what AI policy says. They do not intercept, block, or log agent actions in real time. As autonomous agents move from pilot to production inside Fortune-500 environments, that gap becomes the dominant compliance and data-loss risk: a documented policy doesn't stop a paste, a tool call, or an LLM-mediated exfiltration of regulated content. AARM specifies the runtime enforcement layer that closes the gap — what to intercept, how to decide, what to log — in a form that procurement, audit, and security teams can evaluate against a single neutral standard.
How Containment.ai aligns
Containment.ai aligns with the Protocol Gateway pattern in AARM's reference-architecture taxonomy at the LLM-call boundary. Our proxy intercepts agent traffic to OpenAI, Anthropic, Bedrock, and Azure OpenAI before the call is dispatched, evaluates against policy in real time, and writes a tamper-evident audit receipt for each decision. We do not mediate every protocol AARM contemplates — direct HTTP from agent code, local filesystem, shell, and raw database access remain out of scope for the LLM-boundary proxy and are flagged as gaps in our attestation. Where we extend the spec is at the data layer: AARM defines threat classes but is intentionally silent on detection vocabulary, so we bring configurable detectors and rules for PHI, MNPI, export-control indicators, PII, secrets, source-code leakage, and more. Containment enforces the organization's configuration; it does not make legal classification determinations.
The AARM decision verbs
AARM R4 defines five decisions every runtime must support. Containment.ai ships all five today — ALLOW, DENY, MODIFY, STEP_UP, and DEFER.
ALLOW
A benign agent call passes through, with an audit record written. Policy matched, no regulated content detected, decision logged.
DENY
A prompt that matches a configured HIPAA, SEC, or export-control rule is blocked at the proxy. The agent receives a structured error; the matched bytes never reach the LLM.
MODIFY
A prompt containing a secret or PII is allowed through with the sensitive content redacted. The agent keeps working; the LLM never sees the bytes that matter.
STEP_UP
A sensitive action requires stronger authorization. The action holds until the challenge is satisfied, and the decision plus outcome are recorded.
DEFER
A borderline action is paused for human review. The request holds open in an approval queue until the designated approver acts; the audit record captures both the original signal and the approval outcome.
See all five live
A 30-minute walkthrough against your own test prompts. Every decision lands in audit_events with full context.
AARM v1.0 alignment
Our public claim is intentionally conservative. The full per-requirement status lives in the attestation document, not on this page.
| Specification | Containment.ai claim |
|---|---|
|
AARM v1.0
Cloud Security Alliance / CSAI Foundation, April 2026
|
Aligned with AARM v1.0
See our self-attestation for per-requirement status.
|
We publish "AARM-aligned," not a certification. The current self-attestation records R1–R6 as satisfied at the Core level and R8 as satisfied, with R7 still a gap and R9 out of scope for our architecture. The public attestation is the controlling record.
Why we chose AARM
The Cloud Security Alliance is neutral, vendor-independent, and explicitly focused on agentic AI as a category. AARM's working group spans hyperscaler, GRC, runtime-security, large-enterprise, and defense-relevant constituencies — Microsoft, Vanta, Noma Security, Zenity, Elastic, Truist, and Darktrace among them — which makes it the convergence point the industry has been waiting for. We chose AARM as our public alignment anchor because it lets enterprise buyers evaluate every runtime-governance vendor against a single neutral standard, instead of against each vendor's bespoke marketing claims. The Protocol Gateway pattern in AARM's reference-architecture taxonomy describes the LLM-boundary proxy we already built; the per-requirement attestation tracks where our coverage matches the spec and where it does not.
See the five verbs run live
A 30-minute demo against your own test prompts. ALLOW, DENY, MODIFY, STEP_UP, and DEFER — every decision audited in an AARM-aligned shape.
Prefer email? Use the contact form.