Skip to main content

​
From Text to Actions

Large language models began as text generators. Security meant filtering harmful outputs—profanity, misinformation, toxic content. If the model said something wrong, you could discard it before displaying. That model is obsolete. Today’s AI systems do things:
  • Query databases and modify records
  • Send emails and Slack messages
  • Create, edit, and delete files
  • Execute code and shell commands
  • Call external APIs and webhooks
  • Manage cloud infrastructure
  • Process financial transactions
When an AI agent executes DROP TABLE customers, no output filter helps. The data is gone.

​
The Runtime Security Gap

AI-driven actions have four characteristics that break traditional security:
Unlike text generation—which can be filtered before display—tool executions produce immediate, permanent effects. Database mutations, sent emails, financial transfers, credential changes.Once executed, the damage is done.
    # This can't be "filtered"
    agent.execute("rm -rf /important/data")
Agents execute hundreds of actions per minute. No human can review them in real time.
ActorActions per minute
Human operator2-5
AI agent100-500
Human reviewer capacity5-10
Security decisions must be automated and instantaneous.
Individual actions may each satisfy policy. Their composition violates it.
    Action 1: db.query("SELECT * FROM customers")  
      → ALLOW (user has read access)
    
    Action 2: email.send(to="[email protected]", body=results)  
      → ALLOW (user can send email)
    
    Composition: PII exfiltrated to external party  
      → VIOLATION
Traditional security evaluates actions in isolation.
Prompt injection, jailbreaks, and indirect attacks mean the model’s “intent” cannot be trusted.The agent might be:
  • Following malicious instructions embedded in a document
  • Manipulated by a crafted error message
  • Deceived about what action it’s actually taking
The AI layer must be treated as potentially compromised.

​
Why Existing Security Fails

SIEM

Built for: Event analysis and correlationFailure mode: Observes after execution. By the time SIEM alerts, the database is dropped.SIEM answers “what happened?” — but can’t prevent it.

API Gateways

Built for: Authentication, rate limiting, routingFailure mode: Verifies who is calling, not what the action means. A valid token making a destructive call passes through.Gateway sees credentials, not intent.

Firewalls

Built for: Network perimeter defenseFailure mode: Agents operate inside the perimeter with legitimate credentials. The call comes from an authorized service.The threat is already inside.

Prompt Guardrails

Built for: Filtering model outputsFailure mode: Filters text, not actions. Easily bypassed. Can’t evaluate whether db.execute(query) is safe—only whether the text describing it looks harmful.Guardrails see words, not operations.

IAM / RBAC

Built for: Identity and access managementFailure mode: Evaluates permissions in isolation. User can read customers. User can send email. System doesn’t know doing both in sequence is exfiltration.Permissions don’t understand composition.

Human-in-the-Loop

Built for: Manual approval of sensitive actionsFailure mode: Doesn’t scale to agent speed. Leads to rubber-stamping. Can itself be exploited through forged approval dialogs.Humans become the bottleneck—or the vulnerability.

​
The Missing Layer

There’s a gap in the security stack: 
┌─────────────────────────────────────────────────────────────┐
│                     EXISTING SECURITY                       │
├─────────────────────────────────────────────────────────────┤
│  Perimeter        │  Network firewalls, WAF                 │
│  Identity         │  IAM, RBAC, OAuth                       │
│  Application      │  Input validation, output filtering     │
│  Data             │  Encryption, DLP                        │
│  Observability    │  SIEM, logging, monitoring              │
├─────────────────────────────────────────────────────────────┤
│                     ??? GAP ???                              │
│                                                             │
│  Where do you enforce policy on AI-initiated actions        │
│  BEFORE they execute?                                       │
│                                                             │
├─────────────────────────────────────────────────────────────┤
│                     TOOLS / APIS                            │
│  Databases, email, files, cloud, external services          │
└─────────────────────────────────────────────────────────────┘
This gap is where AARM operates: runtime enforcement at the action boundary.

​
What’s Needed

A security system that:
RequirementWhy
Intercepts before executionPrevention, not just detection
Evaluates action semanticsUnderstands what is happening, not just who
Enforces policy inlineAllow, deny, modify, or escalate in real time
Handles compositionDetects multi-action violations
Treats agent as untrustedAssumes orchestration may be compromised
Creates forensic trailTamper-evident record of every decision
Scales to agent speedAutomated, millisecond decisions
No existing security tool does all of this.

​
Next

What is AARM?

How AARM fills the runtime security gap