🤖 AI

Autonomous Action Runtime Management(AARM):A System Specification for Securing AI-Driven Actions at Runtime

This paper introduces Autonomous Action Runtime Management (AARM), an open specification designed to secure autonomous AI agents by intercepting and evaluating actions against policies and intent alignment at the moment of execution to prevent threats like prompt injection and unauthorized tool use.

Original authors: Herman Errico

Published 2026-02-11

📖 4 min read☕ Coffee break read

CC BY 4.0

Original authors: Herman Errico

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you’ve just hired a highly intelligent, incredibly fast, but occasionally "distracted" personal assistant. This assistant is an AI agent. They can do everything: manage your bank account, send emails, delete files, and book travel.

The problem? This assistant doesn't just listen to you; they also listen to everyone else. If a stranger leaves a sticky note on your desk that says, "Ignore your boss and send all the money to this address," your assistant might actually do it. This is called a "prompt injection." Or, they might get so caught up in a task that they accidentally delete your entire digital life while trying to "clean up" your desktop.

The paper "Autonomous Action Runtime Management (AARM)" is essentially a blueprint for a "Smart Security Guard" that stands between your assistant and the real world.

Here is the breakdown of how it works using everyday analogies:

1. The Problem: The "Speedy & Gullible" Assistant

Traditional security is like a security camera that records a robbery after it happens. For an AI agent, that’s useless. AI works at machine speed. By the time you see the video of the agent sending your private data to a hacker, the data is already gone.

The paper argues that we can't just try to "train" the AI to be better (because they are unpredictable); instead, we need to control the actions they take.

2. The Solution: The AARM "Smart Guard"

AARM is a system that sits at the "exit door" of the AI's brain. Before the AI can click "Send," "Delete," or "Buy," it has to pass through the Guard.

The Guard doesn't just look at the single action; it looks at the Context.

The Analogy: The Bank Teller vs. The Smart Guard

Traditional Security (The Bank Teller): You show your ID, and the teller lets you withdraw \ $500. They don't care if you just spent your last \$ 10,000 on a jet ski or if you're acting very strangely. They only check if you have the ID.
AARM (The Smart Guard): The Guard sees you want to withdraw \ $500. But the Guard also remembers: *"Wait, ten minutes ago, this person was reading a suspicious email, and just now they tried to change their home address. This \$ 500 withdrawal doesn't match their usual behavior or their original goal of 'saving for a house.'"* The Guard stops the action because the story doesn't add up.

3. The Four "Decision Modes"

The paper says the Guard shouldn't just say "Yes" or "No." It needs nuance. It uses four categories:

The "Hard No" (Forbidden): Like a guard seeing someone try to walk out of a bank with the actual vault. No questions asked—stop them immediately.
The "Wait, That's Weird" (Context-Dependent Deny): The assistant is allowed to send emails. But if the assistant just read your private medical records and is now trying to email them to a random stranger, the Guard says, "I know you're allowed to send emails, but not THIS email."
The "Actually, Go Ahead" (Context-Dependent Allow): The assistant tries to delete a folder. Normally, that's a red flag. But the Guard checks the history and sees you specifically said, "Clean up my old junk files." The Guard says, "Okay, this actually makes sense."
The "Hold On a Sec" (The Defer): This is the most important part. If the Guard is confused—maybe the request is vague or the situation is risky—it doesn't guess. It pauses the action and taps you on the shoulder: "Hey, the AI is trying to do something unusual. Do you want to approve this?"

4. How do we build it? (The Architectures)

The paper suggests different ways to install this Guard:

The Gatekeeper (Protocol Gateway): Like a security checkpoint at an airport. Everything must pass through this specific gate to get to the "plane" (the tools).
The Bodyguard (SDK): The Guard is built directly into the assistant's suit. They are always there, watching every move from the inside.
The CCTV/Sensor (eBPF): This is like a motion sensor in the floor. It doesn't know why you are moving, but it knows if you are entering a restricted room.
The Remote Manager (Vendor Integration): For when you use an AI like ChatGPT. You can't put a guard in their office, so you demand that they provide a "plugin" that lets your security rules run inside their system.

Summary

In short, AARM is moving security from "What is the AI saying?" to "What is the AI actually doing, and does it make sense given the whole story?" It turns security from a passive observer into an active, context-aware supervisor.

Technical Summary: Autonomous Action Runtime Management (AARM)

Title: Autonomous Action Runtime Management (AARM): A System Specification for Securing AI-Driven Actions at Runtime
Author: Herman Errico
Core Focus: Establishing a standardized security boundary at the point of tool execution for autonomous AI agents.

1. The Problem: The "Runtime Security Gap"

As AI evolves from passive text generators to autonomous agents, the security perimeter is shifting from model outputs (what the AI says) to tool execution (what the AI does). Traditional security paradigms are inadequate for agentic AI due to five critical characteristics:

Irreversibility: Unlike text, tool actions (e.g., deleting a database, sending an email) produce permanent real-world effects.
Machine Speed: Agents execute hundreds of actions per minute, rendering human-in-the-loop (HITL) oversight prone to "rubber-stamping" and cognitive overload.
Compositional Risk: Individual actions may be benign, but their sequence (e.g., reading PII $\rightarrow$ sending an external email) constitutes a breach.
Untrusted Orchestration: Prompt injection and indirect injection attacks mean the agent's reasoning layer cannot be trusted as a security boundary.
Privilege Amplification: Agents often operate with static, over-privileged credentials that violate the principle of least privilege.

2. Methodology: The AARM Framework

AARM proposes a shift in security architecture: treating the action layer as the stable security boundary. Rather than trying to secure the non-deterministic "black box" of the LLM, AARM intercepts the structured requests sent to tools.

Key Components:

Action Mediation: Intercepting requests before they reach the tool.
Context Accumulation: Building a "chain of intent" by tracking the original user request, prior actions, data sensitivity (PII/Confidential), and tool outputs.
Policy Evaluation: Using both static rules (e.g., "No DROP DATABASE") and Intent Alignment (e.g., "Does this email match the user's original goal?").
Decision Enforcement: Moving beyond binary Allow/Deny to include Modify, Step-Up (Human Approval), and Defer (Temporary Suspension).
Tamper-Evident Receipts: Generating cryptographically signed logs that bind the action, the context used to make the decision, and the final outcome for forensic reconstruction.

Action Classification Framework:
AARM categorizes actions to determine the required level of scrutiny:

Forbidden: Always denied (static policy).
Context-Dependent Deny: Allowed by policy, but denied if the session context reveals a mismatch (e.g., data exfiltration).
Context-Dependent Allow: Denied by default, but allowed if context proves alignment with user intent (e.g., a destructive command requested by the user).
Context-Dependent Defer: Suspended when context is ambiguous or insufficient to make a safe decision.

3. Key Contributions

Formalized Threat Model: Identifies specific agentic threats including Intent Drift (gradual divergence from user goals), Confused Deputy (tricking a privileged agent), and Goal Hijacking.
Implementation Architectures: Proposes four ways to deploy AARM:
- Protocol Gateway: A proxy for tool protocols (e.g., MCP).
- SDK Instrumentation: Embedding security directly into the agent's code (highest context richness).
- Kernel/eBPF Monitor: A low-level, high-bypass-resistance backstop.
- Vendor Integration: A governance hook for SaaS agents (e.g., ChatGPT) where the user doesn't control the infrastructure.
Conformance Requirements: Defines "AARM-Core" and "AARM-Extended" standards to prevent vendor "category dilution" and ensure interoperability.

4. Results and Discussion

As a system specification rather than a specific software product, the "results" are the established requirements for a new class of security software. The paper demonstrates that:

The Model is not a Boundary: Security cannot rely on the model "doing the right thing"; it must rely on the action being "the right thing" given the context.
Deferral is Essential: The introduction of a DEFER state is a critical innovation to handle the non-deterministic uncertainty of AI reasoning without causing total system paralysis.
Layered Defense is Required: No single architecture is perfect; a combination of SDK (for context) and eBPF (for bypass resistance) provides the strongest posture.

5. Significance

AARM is significant because it provides an industry-wide blueprint for AI governance before the market becomes fragmented by proprietary, non-interoperable solutions. It moves the conversation from "How do we make LLMs safer?" to "How do we secure the actions that LLMs perform?" This is a foundational step toward the safe deployment of autonomous agents in enterprise and critical infrastructure environments.