Yesterday, OpenAI announced its acquisition of Promptfoo — the open-source LLM evaluation and red-teaming framework already used by over 25% of Fortune 500 companies. Terms weren’t disclosed, but Promptfoo’s last round valued it at $85.5 million.

This isn’t an isolated move. It’s the latest in an $8.5 billion acquisition wave across 175 AI security companies in just 24 months:

  • Palo Alto Networks → Protect AI (AI app testing + runtime)
  • Check Point → Lakera (prompt injection detection, ~$300M)
  • SentinelOne → Prompt Security (endpoint AI security)
  • CrowdStrike → Pangea + SGNL ($740M, agent security + identity)
  • Snyk → Invariant Labs (runtime AI guardrails)
  • Proofpoint → Acuvity (AI governance)
  • Zscaler → SPLX (AI asset discovery + red teaming)
  • Cato Networks → Aim Security (network-layer AI protection)

The message is clear: AI security is no longer optional. Every major security vendor is scrambling to add it to their portfolio.

But there’s a pattern hidden in this acquisition spree that most people are missing.

The Gap Everyone Is Buying Around

Look at the list again. Almost every acquisition falls into one of two categories:

  1. Dev-time testing — Find vulnerabilities before deployment (Promptfoo, Protect AI, SPLX)
  2. Network-layer filtering — Inspect individual API requests in transit (Lakera, Aim, Prompt Security)

Both are valuable. Neither is sufficient.

Here’s why.

Dev-time testing can’t cover what hasn’t happened yet

Promptfoo is excellent at what it does: you define test cases, run adversarial prompts against your LLM application, and get a report. It’s the SAST/DAST equivalent for AI.

But agents don’t fail the way chatbots fail.

An agent doesn’t just answer questions — it reads files, calls APIs, writes code, sends emails, and chains these actions across dozens of turns. The attack surface isn’t a single prompt. It’s a sequence of actions that has never been tested because it has never happened before.

Microsoft’s own Magentic-One multi-agent framework demonstrated this: researchers found a 97% execution rate of arbitrary malicious code — not because any single request looked dangerous, but because the attack unfolded across multiple steps, each appearing normal.

You can’t write a test case for every possible 15-turn conversation that an agent might have with untrusted data it encounters at runtime. Testing reduces risk. It doesn’t eliminate it.

Network-layer gateways can’t see the attack

The second category — API gateways and content filters — works like a traditional WAF: inspect the request, inspect the response, forget.

This is fine for chatbots. For agents, it’s catastrophic. Here’s what a gateway sees vs. what actually matters:

Gateway Can SeeGateway Cannot See
Individual request contentSession state across turns
Known injection patternsTool chain semantics
API key formatsData flow between tools
Single-turn anomaliesIntent drift over time
Memory/context poisoning

Consider this real attack pattern documented by Palo Alto Unit 42’s research on Agent Session Smuggling:

Turn 1: Research agent asks a normal question
Turn 2: Financial agent responds with its capabilities
Turn 3: Research agent subtly probes system instructions
Turn 4: Financial agent leaks tool configuration
Turn 5: Research agent smuggles a hidden instruction
Turn 6: Financial agent executes an unauthorized stock trade

Every single message passes content filters. The sequence is the attack.

Or consider the classic credential exfiltration chain:

read_file("~/.aws/credentials") → search_web("pastebin.com") → http_post(stolen_creds)

Three tool calls. Each one benign in isolation. Together, they’re data theft. A gateway inspecting each API call independently will never catch this — it has no concept of “this data was read from a sensitive file two turns ago and is now being sent to an external URL.”

“The deployment position defines the information boundary. A highway toll booth can check every car’s license plate, but it can’t tell you where the car came from, where it’s going, or whether it picked up stolen goods three exits back.”

The Missing Layer: Runtime Security

Traditional security has a well-established layered model:

  • SAST/DAST catches bugs in development → That’s Promptfoo
  • WAF/IPS filters known attack patterns at the network edge → That’s Lakera, Cloudflare AI Gateway
  • EDR/Runtime protection monitors behavior in production → That’s… missing

The AI security stack has a gaping hole where runtime protection should be. We have testing tools and we have request filters, but we don’t have anything watching what agents actually do over the course of a session.

This isn’t theoretical. The numbers tell the story:

  • Cisco State of AI Security 2026: 83% of organizations plan to deploy agentic AI, but only 29% feel capable of protecting it
  • Q4 2025: 520 reported tool misuse and privilege escalation incidents — the most common AI agent threat category
  • 82% of 2,614 analyzed MCP server implementations were vulnerable to path traversal
  • GTG-1002 (Sept 2025): The first AI-orchestrated cyber espionage campaign completed 80-90% of its intrusion autonomously

The companies being acquired right now are solving yesterday’s threat model (chatbot safety). The threat model has moved to autonomous agents with tool access, multi-turn memory, and cross-system privileges.

What Runtime Security Actually Requires

Runtime agent security isn’t just “a better WAF.” It requires fundamentally different architecture:

1. Session-level state tracking

Every tool call, every piece of data read, every external request — tracked across the entire agent session. Not per-request. Per-session.

2. Data flow analysis

If an agent reads ~/.env in turn 3 and makes an HTTP POST in turn 7, the system needs to know whether the POST body contains data from that .env file. This is taint tracking — a technique from systems security applied to LLM tool chains.

3. Chain pattern detection

Individual actions are benign. Sequences are attacks. Runtime security needs pattern matching across tool call sequences: credential read → external send = exfiltration. File listing → bulk read → email = data theft. Reconnaissance → config access → privilege escalation.

4. Dynamic permission adjustment

Static permissions (“this agent can read files”) aren’t enough. If prompt injection is detected mid-session, the security posture should escalate — tighter tool restrictions, more aggressive blocking. Detection should feed into control, not just logging.

5. Local execution

Sending all your LLM traffic through a third-party cloud for security inspection defeats the purpose. Your agent is reading credentials, processing customer data, executing code. That telemetry shouldn’t leave your machine.

The Market Timing

Right now, we’re in a transition:

  • 2024-2025: 80% of LLM usage was chatbots and RAG. Gateway filtering was sufficient.
  • 2025-2026: Agents are growing fast. Runtime needs are emerging. The gap is becoming visible.
  • 2026-2027: Agents go mainstream. Runtime security becomes mandatory.

The big security vendors know this. They’re acquiring the testing and gateway layers now because those markets are proven. Runtime security is next — but the window for independent solutions is 12-24 months before the next acquisition wave absorbs them too.

“Agents are being deployed as employees, not tools. They’re going to make mistakes just like employees do… just much faster. Companies are lined up around the block to sign up for more agents. We aren’t going back.”

What We’re Building

This is why we built Bastion — an open-source, local-first AI security firewall that operates at the runtime layer.

Bastion runs as a transparent HTTPS proxy on your machine. No code changes. No cloud dependency. It sees every LLM API call your agent makes and applies five security layers:

  • DLP Scanner: 5-layer pipeline (structure parsing → entropy analysis → regex → semantic analysis → AI validation) with 62 built-in rules. Catches API keys, credentials, PII before they leave your machine.
  • Prompt Injection Detection: 36 regex rules + local ML classifier (ProtectAI/DeBERTa, 7-20ms inference). Regex catches explicit patterns; ML catches semantic camouflage.
  • Tool Guard: 26 rules across 9 categories. Blocks destructive operations, credential access, network exfiltration, and dangerous code execution patterns.
  • Session Threat Intelligence: Cross-turn threat scoring with chain detection. Tracks data flow across tool calls. Detects the multi-step attack patterns that gateways miss.
  • Detection→Control Loop: When PI is detected, Tool Guard automatically escalates — lowering the blocking threshold from critical-only to medium-severity. Detection feeds control in real-time.

Everything runs locally. Your data never leaves your machine. The ML model runs via local ONNX inference, not a cloud API.

It’s not a replacement for Promptfoo — test your prompts in development, absolutely. But when your agent hits production and encounters data, tools, and conversation patterns that no test suite anticipated, you need something watching.

Promptfoo is the smoke detector you install during construction. Bastion is the fire suppression system that runs 24/7 after you move in.

Bastion is open-source and free. Try it: github.com/aiwatching/bastion

npm install -g @aion0/bastion
bastion start

If you’re working on AI agent security, I’d love to hear from you — open an issue or find me on Twitter/X.

References

  1. OpenAI acquires Promptfoo — OpenAI, March 2026
  2. Cisco State of AI Security 2026 — 83% plan agentic AI deployment, 29% feel prepared
  3. Promptware Kill Chain — Harvard Berkman Klein Center / Lawfare, 2026
  4. MITRE ATLAS Agent Techniques — 14 agent-specific attack techniques added Oct 2025
  5. Palo Alto Unit 42: Agent Session Smuggling — A2A protocol attack research
  6. Magentic-One Vulnerability Analysis — 97% malicious code execution rate
  7. ControlValve: Multi-Agent Control Flow Integrity — Microsoft Research, 2025
  8. Unpacking the 2025 AI Security Acquisitions — Latio Tech
  9. AI Security Market 2025 Funding Data — Software Strategies Blog