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 High-Assurance 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 control plane 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 a catalog of regulated-content detectors (PHI, MNPI, ITAR/EAR export-control, PII, secrets, source-code leakage, and more) that sit at the LLM boundary and decide whether the data crossing it is allowed to leave.
The AARM decision verbs
AARM R4 defines five decisions every runtime must support. Containment.ai ships four of them today — ALLOW, DENY, MODIFY, and DEFER; STEP_UP is on the roadmap.
ALLOW
A benign agent call passes through, with an audit record written. Policy matched, no regulated content detected, decision logged.
DENY
A prompt containing HIPAA PHI, SEC MNPI, or ITAR-controlled text is blocked at the proxy. The agent receives a structured error; the regulated 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 (on the roadmap)
A sensitive action triggers a step-up auth challenge: the agent receives a structured re-auth prompt and the action holds until the human completes the challenge. This verb is on our roadmap and not yet shipping.
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 do not claim "AARM Core conformant" today. "AARM-aligned" is the strongest claim we publish until per-requirement implementation work in the attestation reaches a tier we can defend in a Conformance Program submission.
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, DEFER (STEP_UP on the roadmap) — every decision audited, tamper-evident, AARM-aligned shape.
Prefer email? Use the contact form.