Heron and AARM
AARM — Autonomous Action Runtime Management — is an open specification for securing what an AI agent actually does at runtime. Heron is built to it. Conformance in progress, not claimed.
What AARM is
AARM was published in 2026 by Herman Errico as an open specification, not a product. It defines what any runtime security system for AI agents must do: intercept every action before it runs, accumulate the session's context, evaluate the action against both policy and the user's intent, enforce a decision, and record a tamper-evident receipt of what happened.
The gap it closes
Traditional security can block, but it can't understand. A SIEM, an API gateway, or a firewall sees "an API call" — not "the agent is emailing customer data to an outside address right after reading the database." They judge each action in isolation. AARM judges it in context: what the user actually asked for, what the agent has already touched, and whether this action still matches the intent.
That matters because agent actions are different. Many are irreversible. They run at machine speed — hundreds of tool calls a minute, too fast for a human to sign off on each one. A sequence that looks fine step by step can add up to a breach. The orchestration layer can be hijacked by prompt injection. And agents often run with far more privilege than the task needs.
How it decides
always blocked, whatever the context. Dropping the production database, sending data to a known-bad domain.
allowed by policy, but blocked when the context breaks intent. Reading customer PII, then emailing it outside.
denied by default, but allowed when the context confirms intent. The user said "clean up my test data," so deleting those records goes through — directly, or after a quick human confirm.
when the context is unclear or conflicting, hold the action for a human or for more information instead of guessing.
Why an open standard, not a vendor's word
AARM defines what a runtime must do, not how to build it. So a buyer's security team can hold every vendor to one bar, instead of taking each vendor's word for it. We think of it as SOC 2 for AI agents: a shared bar a buyer recognizes, published early, before the market fragments into proprietary approaches. Heron is a builder, not the author: the standard sets the bar, not us.
Heron connects through the platform
AARM describes four ways to implement it — a gateway every call is routed through, an SDK embedded in each agent, a kernel-level monitor, or an integration through the platform the agents run on. Heron takes the last one.
You don't wire every agent through a proxy or embed code in each one. Heron plugs into the platform your agents already run on, through the same surface a platform exposes for extensions. The spec's insight: if a platform lets you add plugins that expand what an agent can do, it can expose the mirror-image hook that constrains it. Connect once, and every action the platform runs through that hook is covered — the agents you run today and the ones you ship next month.
The hook is synchronous: nothing runs until Heron returns a decision, and every decision is written to a signed receipt. One integration at the platform level, not a code rewrite. AARM standardizes what that hook must expose — the way OAuth standardized delegated auth without dictating anyone's internals — so it's a standard shape, and the same pattern repeats on any platform that exposes it, instead of a bespoke gateway per agent.
What Heron does at the hook
At the hook, Heron runs an AARM-style decision: it checks each action against policy and the user's intent (R3), enforces the outcome — allow, deny, modify, defer, or step up to a human — and writes a signed, tamper-evident receipt a buyer's security team can verify offline (R5), backed by an append-only hash-chained log (R2).
Conformance is in progress, not claimed.