Definition
Autonomous Action Runtime Management (AARM) is a runtime security system that:Core Principle
The action boundary is the security boundary.Not the model. Not the prompt. Not the orchestration layer. The moment an AI system attempts to execute a tool—that is where security must be enforced.
What AARM Is
| Property | Description |
|---|---|
| Inline enforcement | Decisions made and enforced before execution, not after |
| Semantic evaluation | Policies express meaning (what the action does), not just syntax |
| Compositional awareness | Evaluates action sequences, not just individual calls |
| Forensic completeness | Every action produces a signed, verifiable receipt |
| Agent agnostic | Works with any agent framework, model, or orchestration layer |
| Fail-secure | Denies actions when policy cannot be evaluated |
What AARM Is Not
Not a prompt filter
AARM operates on actions, not text. Prompt guardrails are complementary but insufficient.
Not an alignment technique
AARM does not attempt to make models safer. It constrains what they can do, regardless of intent.
Not an observability tool
AARM enforces policy, not just monitors. Logging without blocking is insufficient for irreversible actions.
Not an IAM replacement
AARM complements identity systems. It answers “should this action execute?” not “who is this?”
Trust Model
AARM’s security model treats different components with different trust levels:| Component | Trust Level | Rationale |
|---|---|---|
| AARM system | Trusted | Must be trusted to enforce policy correctly |
| Policy | Trusted | Defines organizational security requirements |
| Agent / Model | Untrusted | May be compromised via prompt injection or manipulation |
| User inputs | Untrusted | Primary vector for injection attacks |
| Retrieved content | Untrusted | Documents, emails, web pages may contain malicious instructions |
| Tool outputs | Untrusted | Responses may attempt to influence subsequent actions |
| Tools / APIs | Partially trusted | Assumed to execute as documented, but effects must be verified |
The critical insight: the AI orchestration layer cannot be trusted as a security boundary. Prompt injection is a fundamental property of current LLM architectures, not a bug to be fixed. Security must be enforced at a layer the model cannot influence.
Scope
In Scope
AARM addresses runtime authorization and audit for AI-driven actions:- Runtime action authorization (allow/deny/modify/step-up)
- Parameter validation and constraint enforcement
- Human approval workflows for high-risk actions
- Cryptographically signed action receipts
- Identity binding (human → service → agent → action)
- Telemetry export for SIEM/SOAR integration
Out of Scope
AARM does not address (but may complement):| Area | Why Out of Scope | Complementary Control |
|---|---|---|
| Model training | AARM operates at runtime, not training time | RLHF, constitutional AI |
| Prompt engineering | AARM secures actions, not text generation | System prompts, guardrails |
| Agent internals | AARM treats agents as black boxes | Agent-specific safety measures |
| Tool implementation | AARM mediates access, doesn’t secure tools | Tool-level security controls |
| Infrastructure security | AARM assumes secure deployment | Network security, container hardening |