Cloud Security Alliance · Technical Working Group Specification

Autonomous Action Runtime Management

System Category Specification

Version: 1.0
Status: Published
Date: February 2026
Author: Herman Errico
DOI: arXiv:2602.09433
License: CC BY 4.0

Abstract

This specification establishes a framework for securing artificial intelligence systems during action execution. As AI systems evolve from advisory tools into autonomous agents capable of consequential real-world actions, the security boundary shifts from model outputs to tool execution. AARM defines a control plane that intercepts, evaluates, decides on, and records every agent-initiated action before it is executed — regardless of the underlying model, framework, or environment.

The framework provides vendor-neutral requirements organized into nine specification requirements (R1–R9), grouped into Core (R1–R6, all MUST) and Extended (R7–R9, SHOULD) conformance levels. It formalizes protections against eleven threat classes including prompt injection, confused deputy attacks, data exfiltration, and intent drift.

Status of This Document

This document is the v1.0 specification of AARM, published February 2026 under the Cloud Security Alliance Technical Working Group. It is a stable, published specification.

Feedback and contributions are welcome via the GitHub repository. Errata will be tracked as issues.

Work on v2.0 is planned. Version 2 will extend the threat model, introduce multi-agent coordination requirements, and add guidance for stateful long-horizon task governance.

1. Definitions

Keywords MUST and SHOULD in this document are to be interpreted as described in RFC 2119.

Autonomous Action: A decision made by an AI system that produces a real-world consequence without continuous human intervention. Distinct from advisory or informational outputs. Examples include API calls, file writes, shell commands, and network requests.
Runtime Management: Governance mechanisms that operate during action execution — not preprocessing or planning phases. The temporal distinction is critical: runtime controls can intercept and halt actions before consequences are incurred.
Control Plane: The infrastructure layer that sits between an agent and the environments it can affect. Every agent-initiated action passes through the control plane before execution.
Agent Intent: The stated objective or task assigned to an agent at the beginning of a session or task thread. Used as the reference point against which proposed actions are evaluated for alignment.
Action Receipt: A tamper-evident record produced for each evaluated action. Contains the action, decision, timestamp, agent identity, and relevant evaluation context. Serves as the basis for audit and forensic analysis.
AARM Core: Conformance level requiring satisfaction of all six MUST requirements (R1–R6). Baseline for claiming AARM conformance.
AARM Extended: Conformance level requiring satisfaction of all nine requirements (R1–R9), including the three SHOULD requirements (R7–R9). Indicates a mature governance implementation.

2. Threat Model

AARM systems are designed to defend against the following eleven threat classes. A conformant implementation must address all of them.

T1

Prompt Injection — Malicious content in the agent's environment causes it to execute attacker-controlled actions in place of the user's intent.

T2

Confused Deputy — An agent is manipulated into using its legitimate credentials or access to perform actions on behalf of an unauthorized party.

T3

Data Exfiltration — Sensitive data accessed by the agent during a task is extracted to an unauthorized destination via tool calls or output channels.

T4

Goal Hijacking — An agent's objective is covertly replaced or corrupted mid-session, causing it to pursue goals inconsistent with user intent.

T5

Memory Poisoning — Persistent state (conversation history, retrieved documents, tool outputs) is contaminated to influence future agent decisions.

T6

Intent Drift — An agent gradually deviates from its original stated intent over a long task horizon, performing actions that are technically permitted but misaligned.

T7

Cross-Agent Propagation — Malicious instructions or compromised state spreads from one agent to another in a multi-agent pipeline.

T8

Over-Privileged Credentials — An agent operates with broader access rights than required for its task, amplifying the blast radius of any compromise.

T9

Side-Channel Leakage — Information is inferred from agent behavior, timing, or tool call patterns rather than direct output.

T10

Environmental Manipulation — The environment an agent interacts with is modified by an attacker to cause unintended behavior (e.g., altered file contents, injected API responses).

T11

Malicious Tool Output — A tool or external service returns adversarial content designed to hijack the agent's subsequent actions.

3. Core Requirements

All six requirements in this section are MUST. Satisfying R1–R6 qualifies a system for AARM Core conformance.

R1Pre-execution interceptionMUST

The system MUST intercept every agent-initiated action before it is executed. No action may bypass the control plane. This requirement is non-negotiable: a system that allows any action to execute without interception provides no meaningful runtime guarantee.

R2Context accumulationMUST

The system MUST accumulate and maintain context about the agent's stated intent, prior actions in the current session, and the conversation or task thread. Context must be available to the policy evaluation layer at the time of each decision.

R3Policy evaluation with intent alignmentMUST

The system MUST evaluate each intercepted action against a policy that considers both the action itself and its alignment with the agent's stated intent. Policies that evaluate actions in isolation without intent context do not satisfy this requirement.

R4Five authorization decisionsMUST

The policy engine MUST be capable of producing exactly one of five decisions for each evaluated action: ALLOW (execute as-is), DENY (block execution), MODIFY (execute a transformed version), STEP_UP (require human approval before execution), or DEFER (delay execution pending additional context).

R5Tamper-evident receiptsMUST

The system MUST produce a tamper-evident action receipt for every evaluated action. Each receipt must include at minimum: the original action, the decision, the timestamp, and the policy context used in evaluation. Receipts must be verifiable against unauthorized modification.

R6Identity bindingMUST

Every action receipt MUST be cryptographically bound to an agent identity. The binding must be verifiable and must uniquely identify the agent that initiated the action, supporting non-repudiation.

4. Extended Requirements

The three requirements below are SHOULD. Satisfying R1–R9 qualifies a system for AARM Extended conformance.

R7Semantic distance trackingSHOULD

The system SHOULD track the semantic distance between proposed actions and the agent's original stated intent, flagging drift over long task horizons. This requirement addresses T6 (intent drift) and is especially relevant for agents operating autonomously over extended sessions.

R8Telemetry exportSHOULD

The system SHOULD export action telemetry in a standard, interoperable format (e.g., OpenTelemetry) suitable for ingestion by SIEM platforms and observability infrastructure. Proprietary-only export formats do not satisfy this requirement.

R9Least privilege enforcementSHOULD

The system SHOULD enforce least-privilege scoping of agent credentials and tool access at the time of action execution. Credentials should be scoped to the minimum necessary for each action, not granted session-wide or system-wide.

5. Conformance Criteria

A system may claim conformance to one of two levels. Claims must be supported by an evidence package reviewed by the AARM Technical Working Group.

AARM Core

R1 – R6

All six MUST requirements satisfied. Baseline conformance.

AARM Extended

R1 – R9

All nine requirements including R7–R9 SHOULD requirements.

How to claim conformance

01Satisfy all MUST requirements (R1–R6) for Core, or R1–R9 for Extended.
02Complete the testing protocol and compile evidence for each requirement.
03Engage with the working group community before submitting.
04Operate the system in a production environment with real agent workloads.
05Submit your evidence package. Allow up to 14 days for the conformance report.

6. Implementation Architectures

The specification is implementation-neutral. Four reference architectures are recognized, each with distinct trust properties and deployment trade-offs.

6.1Protocol Gateway

A network-layer proxy that intercepts agent-to-tool communication at the protocol level. Provides strong isolation guarantees but requires routing all agent traffic through the gateway. Suitable for environments where network topology can be controlled.

6.2SDK Instrumentation

Intercepts action calls via integration with the agent framework's SDK. Lower deployment friction than the gateway model but requires trust in the SDK integration. May not intercept actions made through non-instrumented paths.

6.3Kernel eBPF

Uses kernel-level eBPF hooks to intercept system calls made by agent processes. Provides deep visibility and is difficult for an agent to bypass, but requires elevated privileges and kernel compatibility. Best suited for containerized production environments.

6.4Vendor Integration

Action interception is provided natively by the AI platform or tool vendor as part of their API surface. Lowest deployment friction but dependent on vendor implementation quality and coverage.

References

[1]Errico, H. (2026). Autonomous Action Runtime Management (AARM): A System Specification for Securing AI-Driven Actions at Runtime. arXiv:2602.09433 [cs.CR].

[2]Bradner, S. (1997). Key words for use in RFCs to Indicate Requirement Levels. RFC 2119. IETF.

[3]Cloud Security Alliance. (2026). AARM Conformance Testing Protocol. CSA Working Group Publication.