Check Point acquired Lakera for $300 million. CrowdStrike added AI usage monitoring. Cloudflare launched AI Gateway with guardrails. AWS shipped Bedrock Guardrails. Every major security vendor now has an “AI Security” checkbox on their product page.
And yet none of them can tell you whether your AI agent just read .env, stored the contents in context, and exfiltrated them three tool calls later in a POST request disguised as a webhook test.
The reason isn’t that these companies lack engineering talent or resources. It’s that their architecture makes it structurally impossible to do runtime agent security. Here’s why.
1. Architecture Path Dependency
Every major security vendor’s AI security product is a variation of the same pattern: take their existing deployment model and bolt on content filtering.
| Vendor | Core Product | AI Security Approach |
|---|---|---|
| Check Point | Network firewall | Add AI content filter at network boundary |
| CrowdStrike | EDR/XDR | Add AI usage monitoring to endpoint telemetry |
| Cloudflare | CDN/WAF | Add guardrails to reverse proxy layer |
| F5 | Load balancer/WAF | Add prompt inspection at app gateway |
| AWS/Azure | Cloud infrastructure | Add guardrails at API call layer |
Check Point didn’t pay $300M for Lakera because their DeBERTa classifier was uniquely advanced — anyone can train one. They paid for the fastest path to adding an “AI Security” line item to their firewall product for existing enterprise customers.
This is rational behavior. But it means every acquisition gets squeezed into a pass-through filtering architecture that was designed for HTTP request inspection, not agent behavior analysis.
2. The Information Boundary Problem
This is the most important structural issue, and it’s rarely discussed.
A security gateway sits between a client and an API. It sees individual requests and responses. That’s it.
| What a gateway sees | What a gateway can’t see |
|---|---|
| Request/response content | Agent session state (what it did last turn, what it plans next) |
| Individual tool call parameters | Cross-call semantic chains (read .env → POST external = theft chain) |
| API key patterns in text | MCP tool registration changes, tool tampering |
| Prompt injection text | Agent intent drift, persistent memory mutations, context window state |
Gateways are stateless by design. Each request is processed independently, then forgotten. They fundamentally cannot do cross-request behavioral analysis.
This isn’t a limitation that can be fixed with better engineering. It’s determined by deployment position. The information simply doesn’t exist at the gateway layer.
Analogy: A highway toll booth can check every car’s license plate. But it has no idea where each car came from, where it’s going, or which other toll booths it passed through. A dashcam inside the car knows all of this.
What This Means in Practice
Consider this attack sequence:
Turn 1: Agent reads a webpage containing hidden instructions
Turn 2: Agent runs `cat ~/.aws/credentials` (looks like a config check)
Turn 3: Agent writes credentials to a variable in working memory
Turn 4: Agent sends a POST request with the credentials embedded in a "webhook test"A gateway sees four independent, individually-normal requests. It might flag the credentials in Turn 4, but only if they appear in plaintext — and a sophisticated attack would encode them.
A runtime security layer inside the agent session sees the complete chain: external content → credential access → data staging → exfiltration. It can flag the pattern at Turn 2, before data ever leaves.
3. Business Model Priorities
Even if gateways could do runtime security, the business case doesn’t align.
| Dimension | Gateway model | Runtime model |
|---|---|---|
| Buyer | Network/security team | Dev/platform team |
| Budget | Security budget (existing) | Dev tools budget (must be justified) |
| Integration | Change DNS/proxy config | Embed in application deployment |
| Sales cycle | Short (existing relationship) | Long (requires developer buy-in) |
| Scale | One customer = entire company | Project-by-project adoption |
For a company like Check Point, integrating an acquisition into the existing firewall product and selling it to existing customers is the highest-ROI path. Building a fundamentally different product that targets a different buyer in a different budget? That requires a strategic pivot few large companies are willing to make while the current approach still generates revenue.
4. The Timing Gap
The market dynamics create a structural window:
- 2024–2025: 80% of AI deployments are chatbots and RAG pipelines. Gateway-level content filtering is sufficient. No urgent demand for runtime security.
- 2025–2026: AI agents are growing rapidly. Runtime security needs are emerging, but the market is small. Big vendors are watching.
- 2026–2027: Agents become mainstream. Runtime security becomes a hard requirement for production deployments.
Large vendors are rationally waiting for the market to mature before investing (or acquiring). They have money and customers — they don’t need to bet on early-stage markets.
This creates a 12–24 month window where the runtime security space is structurally underserved by incumbents.
The Runtime Alternative
What does “runtime security” actually look like?
Gateway: Client → [Cloud Gateway] → LLM
(sees request/response pairs only)
Runtime: Client → [Local Proxy] → LLM
(sees full session, tool chains, state, local environment)A local proxy deployed alongside the agent has access to:
- Complete session history — every turn, every tool call, every response
- Cross-request correlation — detecting multi-step attack chains
- Tool chain monitoring — what tools are registered, what’s been modified, what’s being called
- Local environment context — file system access patterns, environment variables, process state
- Real-time intervention — blocking a dangerous tool call before it executes, not after
This isn’t about having better ML models or more training data. It’s about information access. The runtime layer simply has more signal to work with than a gateway ever can.
What This Means for the Industry
The implications are clear:
-
Gateway AI security products will converge on commodity content filtering. Every vendor will have roughly equivalent prompt injection detection and DLP scanning within 12 months. Differentiation will collapse.
-
Runtime security will become a distinct category. Just as EDR didn’t replace firewalls but created a new category alongside them, agent runtime security will complement gateway security rather than replace it.
-
The EU AI Act accelerates the shift. Article 15 requires detailed logging and monitoring of AI system behavior. Gateway-level request logs don’t meet this standard. Runtime-level session recording does. Data sovereignty requirements also favor local deployment over cloud gateways.
-
Developer adoption is the moat. Gateway security is sold top-down to CISOs. Runtime security is adopted bottom-up by developers who are actually building agent applications. Different go-to-market, different competitive dynamics.
The security giants aren’t wrong to invest in gateway-level AI security. It solves real problems for chatbot and RAG deployments. But as agents become the dominant AI application pattern, the architectural limitations of the gateway model become impossible to ignore.
The toll booth catches cars without plates. The dashcam catches the ones that are stealing.
Bastion is an open-source local security proxy for AI agents. It provides DLP, prompt injection detection, tool call blocking, and full audit logging — all running locally, with zero cloud dependency.