Reference

What AARM is

Autonomous Action Runtime Management— a specification for the layer that sits between an AI agent and the things it can actually do. It is the framework the block at the top of every evidence page is answering, and it was written because “the agent is safe” is not a claim anybody can check.

The one-line version. AARM says: intercept every action before it runs, remember what the agent has already done, judge the action against a policy and against what the agent was asked to do, answer with one of five decisions, and leave a signed receipt that names the agent. Nine requirements, and they are numbered R1 to R9.

Who is behind it

AARM is developed in the open by a working group at the Cloud Security Alliance, and published at aarm.dev/spec. It is vendor-neutral and model-agnostic: it says what a runtime security system must do, never which product you must buy to do it.

There is a public builder registry, and this is worth understanding before you read anyone’s badge — including ours:

Conformant — the builder completed a testing protocol, submitted an evidence package, and the AARM Technical Working Group reviewed it. Verified by people, not self-declared.
Aligned— the company says it is building in this space. It is a listing, not a verification. If a vendor waves “we’re in the AARM registry” at you, this is the question to ask: which of the two?

The nine requirements

Core is R1–R6 and every one is a MUST. Extended adds R7–R9, which are SHOULD. In plain terms:

#	Name	What it actually asks for
`R1`	Pre-execution interception	Every action passes through the control plane before it runs, and there is no fail-open path around the policy check. The hard one.
`R2`	Context accumulation	The session remembers: what was asked, what the agent has already done. Ideally in a tamper-evident log, so the memory itself can be checked.
`R3`	Policy evaluation with intent alignment	The action is judged against a policy and against what the agent was asked to do. An action cannot be judged in isolation.
`R4`	Five authorization decisions	Exactly one of `ALLOW`, `DENY`, `MODIFY`, `STEP_UP`, `DEFER`. Not a score, not a warning — a decision.
`R5`	Tamper-evident receipts	Every evaluated action leaves a receipt whose integrity a third party — you — can verify.
`R6`	Identity binding	The receipt is cryptographically bound to which agent acted. Nobody can disown an action afterwards.
`R7`	Semantic distance tracking	Watch for drift: an agent that, over a long task, ends up proposing something far from what it was originally asked.
`R8`	Telemetry export	Action telemetry leaves in a standard format a SIEM can read (e.g. OpenTelemetry).
`R9`	Least privilege enforcement	The agent’s credentials are scoped down at the moment of execution, rather than handed a session-wide key to everything.

Why our page says “coverage” and never “conformant”

Because those are different claims, and only one of them is ours to make. Conformance is claimed by a builder for a product and reviewed by the working group. It is not something a dashboard grants, and it does not transfer: a vendor does not become conformant by routing its agents through us, any more than a company becomes SOC 2 certified by hosting on a certified cloud.

So the block at the top of an evidence page answers a narrower question, the one we can actually answer with data: for each requirement, what does this evidence show, what does it not show, and who — if anyone — closes it? If a vendor tells you their Heron page proves AARM conformance, they are telling you something the page itself denies.

The five statuses, and what each is worth

Status	Read it as
Verified here	You can check it yourself, from this page, without trusting our server — recompute the chain, verify the signature against the public keys. This is the only status that does not ask you to believe anybody.
Failing	The evidence in this window contradicts the requirement. Nobody at the vendor can clear this: it goes away when the evidence stops contradicting it, and not before.
Partial	Done, but not to the letter of what the requirement asks.
Vendor-declared	It rests on what the vendor sent us. We cannot prove it is complete — see self-bypass. Treat it as the vendor’s word, with our record as corroboration.
Not covered	We do not do this, and the card says why. A requirement we honestly mark red is worth more to you than one that went green because somebody configured it.

The statuses are computed, not configured. There is no setting anywhere in Heron that turns a requirement green. They are derived from the same evidence you can download: a broken chain fails R2, an invalid vendor signature fails R5, an execution for an action we never saw fails R1 and R6. The assessment travels inside the JSON bundle — recompute it yourself and check that our badges agree with our own data.

What Heron closes, and what it does not

On a healthy window today: R2, R5 and R6 come out verified — the session hash chain, the Ed25519 receipts over canonical JSON, and the agent identity bound inside the signed bytes. Those are the three you can check with your own hands.

R1 is vendor-declared: the hook runs before execution, but an action taken around the hook leaves no trace, so coverage is a number we show you rather than a guarantee we hand you. R3 and R7 are not covered — judging intent needs the content of a request, and Heron deliberately does not hold it. R9 is not covered: credential scoping happens inside the vendor’s own execution path, where we are not. R4 and R8 are partial.

If the deployment you are looking at is observing rather than enforcing, every live decision will be ALLOW and the page will say so — R4 stays partial until a real DENY appears in the data. That status changes on evidence, not on a release note.

There is a third case, and it is the one worth knowing about: refusals were returned and nothing in the record says what became of them. A call that never happened looks the same whether the vendor obeyed or its agent simply never reached the tool, so we do not read that silence as compliance — the posture says UNCONFIRMED, and R1 claims interception without claiming the vendor waited. Obedience can only ever be the vendor’s own counter-signed statement (BLOCKED, ESCALATED); disobedience is the half we can prove for ourselves.

What to ask a vendor who mentions AARM

Registry status: Conformant (reviewed) or Aligned (self-declared)?
Core (R1–R6) or Extended (R1–R9)? Core is the one with the MUSTs.
Is the control plane actually enforcing, or observing? A DENY that is never returned to the agent is a measurement, not an authorization decision.
When a DENY isreturned, how do you show it was obeyed? “The call does not appear” is not an answer — an agent that never reached the tool produces the same absence. Ask for the counter-signed statement that names the verdict as the reason.
Is the hook on the only path an agent has to a tool — and how would you know if it were not?
Which requirements are you not meeting, and why? A vendor with no red is a vendor not telling you everything.

The last one is the point of this whole page. Read how to read an evidence page next — it goes through the numbers underneath these badges, and how to check them without trusting us.