Two altitudes: control-plane governance and in-path enforcement. A two-axis chart — horizontal from across-the-estate to in-the-action-path, vertical from observes-and-reports to rules-pre-execution. Control-plane governance sits estate-wide and observational; in-path enforcement sits in the action path, ruling pre-execution. A connector labels them complementary — different jobs, not a winner.
FIG. A — TWO DIFFERENT JOBSCONTAINMENT.AI
RUNTIME AGENT GOVERNANCE — AARM v1.0 ALIGNMENT

Judge us against a standard we didn't write.

A documented AI policy doesn't stop an agent's next action — you need an enforcement layer that intercepts, decides, and logs at runtime. We build ours to align with AARM v1.0, the Cloud Security Alliance's open runtime-governance specification, so you can evaluate us against a neutral yardstick instead of our own marketing.

FIG. 1 — WHAT AARM IS
The specification

AARM — Autonomous Action Runtime Management — is the Cloud Security Alliance's open specification for governing autonomous AI agents at runtime. Authored at Vanta, donated to the CSAI Foundation in April 2026, and governed by a working group spanning Microsoft, Vanta, Noma Security, Zenity, Elastic, Truist, and Darktrace. It requires that every agent action be intercepted before execution, evaluated against policy with full context, and logged in tamper-evident form — and defines four reference architectures: Protocol Gateway, SDK Instrumentation, Kernel/eBPF Hooks, and Vendor-Native Integration.

Why we anchor to it

The CSA is neutral, vendor-independent, and explicitly focused on agentic AI. A neutral standard lets a buyer evaluate every runtime-governance vendor against one yardstick instead of each vendor's own claims. We chose AARM as our public alignment anchor for exactly that reason — and because the Protocol Gateway pattern in its taxonomy describes the LLM-boundary proxy we had already built.

FIG. 2 — THE FIVE AARM DECISION VERBS

AARM R4 defines five decisions. All five ship today.

ALLOW

A benign call passes through — policy matched, no regulated content, decision logged.

DENY

Text that matches configured PHI, MNPI, or export-control rules is blocked at the boundary. The matched bytes never reach the LLM.

MODIFY

A secret or PII is redacted in-flight. The agent keeps working; the LLM never sees the bytes that matter.

DEFER

A borderline action holds in an approval queue for human review. The record captures signal and outcome.

STEP_UP

A sensitive action requires stronger authorization and holds until the challenge is satisfied. The decision and outcome are recorded.

FIG. 3 — AARM'S FOUR REFERENCE ARCHITECTURES, AND WHERE WE SIT

The spec names four patterns. We implement one, ship a second at the app layer — and say so about the rest.

OUR PATTERN
ARCH 01
Protocol Gateway
The LLM-boundary proxy: intercept, evaluate, receipt — before dispatch to the provider.
ARCH 02
SDK Instrumentation
Our guard SDK wraps tool dispatch at the application layer — see Agent Governance.
ARCH 03
Kernel / eBPF Hooks
In the spec; not our pattern. We flag it as out of scope rather than stretch the claim.
ARCH 04
Vendor-Native Integration
In the spec; territory we watch as agent platforms expose native governance hooks.
FIG. 4 — HOW WE ALIGN, AND WHAT WE ADD
We align at the boundary

Our proxy intercepts agent traffic to OpenAI, Anthropic, Bedrock, and Azure OpenAI before dispatch, evaluates it against policy in real time, and writes a tamper-evident receipt per decision — the Protocol Gateway pattern at the LLM-call boundary. We're precise about scope: direct HTTP from agent code, filesystem, shell, and raw database access are out of scope for the proxy and flagged as gaps in our attestation.

We add the detection vocabulary

AARM defines threat classes but is intentionally silent on how a runtime recognizes regulated content. That's the layer we bring: configurable detectors and rules for HIPAA PHI, SEC MNPI, export-control indicators, PII, secrets, source-code leakage, prompt injection, and more. The standard says "intercept and decide"; we supply the policy vocabulary. Containment enforces your configuration; it does not make legal classification determinations.

OUR CLAIM, STATED PRECISELY —
We publish "aligned with AARM v1.0" — not a certification. Our current self-attestation covers the connected-tier proxy and 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 document is the record you can diff; it outranks this page.
Two things a reader checking our work should know. CSA’s CS-1 First Edition — the successor circulating as “v3” — promotes R10 (action risk classification) and R11 (source provenance) from SHOULD to Core MUST and adds an Edge & Lifecycle profile (R12–R15). Our published position is stated against v1.0 and has not yet been restated against it; under v3 several requirements we record as satisfied would read as partial. And v3 re-frames “attested” as three witness classes — self-logged, assessor-engaged, independently-verified — of which ours is self-logged, the weakest. Both are stated on the Trust record, which outranks this page.
FIG. 5 — FOUR QUESTIONS TO ASK ANY VENDOR — INCLUDING US
Q1 — Is every governed action intercepted before execution, or observed after?
OURS: PRE-EXECUTION, IN-PATH — A LOG IS NOT A CONTROL.
Q2 — What does policy see at evaluation time, and is the decision deterministic?
OURS: PINNED CONTEXT, VERSIONED POLICY, NO AI MODEL MAKES THE ENFORCEMENT DECISION.
Q3 — What decision evidence is recorded, and when can policy be re-evaluated?
Ours: product-specific decision records; exact input + context + policy required for re-evaluation.
Q4 — Which AARM architecture do you implement, and where are your scope gaps published?
OURS: PROTOCOL GATEWAY — GAPS LISTED IN THE PUBLIC ATTESTATION.
ASK EVERY VENDOR THE SAME FOUR — THAT'S WHAT A NEUTRAL YARDSTICK IS FOR.
SEE THE DECISION VERBS RUN LIVE
A 30-minute demo against your own test prompts — every decision audited, tamper-evident, in an AARM-aligned shape.
Review your agent boundary See the enforcement product