AI Agent Security vs WAFs: Why Web Controls Are Not Enough

Security teams already have a long list of controls around web applications: WAFs, API gateways, rate limits, authentication, authorization checks, logging, bot detection, vulnerability scans, and manual penetration tests. Those controls still matter when a product adds AI.

But they do not become AI agent security by default.

A WAF can inspect HTTP traffic. An API gateway can enforce routes, tokens, policies, and quotas. Those are important layers. The problem is that agentic AI systems introduce behavior that does not live cleanly inside a single request signature. A malicious prompt may look like ordinary text. A risky agent action may use a perfectly valid API call. A RAG data leak may happen because the wrong context entered the model, not because the network request looked malformed.

So the real question is not whether WAFs are useful. They are. The question is what they cannot see.

What WAFs are good at

WAFs are designed for web traffic. They help detect or block known patterns like SQL injection, cross-site scripting, protocol abuse, suspicious request shapes, automation, and common exploit attempts. API gateways can centralize authentication, request validation, routing, rate limits, and service-level policy enforcement.

For AI applications, those controls remain valuable. The AI feature still runs inside a web or API surface. Users still authenticate. Requests still hit endpoints. Backend services still need authorization. Attackers can still probe ordinary application weaknesses around session handling, tenant isolation, input validation, and exposed infrastructure.

In other words, adding AI does not make normal application security obsolete.

It makes normal application security incomplete.

What AI agents add to the attack surface

AI agents add a reasoning layer between the user's request and the system's action. That layer is non-deterministic, context-sensitive, and often influenced by untrusted data.

An agent may read a support ticket, summarize a document, retrieve knowledge-base content, decide which tool to call, pass parameters into an API, and preserve context for later turns. Each step may look legitimate at the HTTP layer. The issue is whether the behavior stayed inside the intended security boundary.

A WAF usually cannot tell whether a retrieved document contained indirect prompt injection. It cannot evaluate whether the agent should have trusted that document. It cannot decide whether a tool call was appropriate for the user's role. It cannot inspect the full multi-turn conversation and determine whether the final action was caused by adversarial context introduced earlier.

That is why AI agent security needs validation at the complete implementation level: application, API, prompt/model behavior, RAG, memory, tools, MCP, and permissions.

A simple example

Imagine a customer support agent connected to a help desk and an account system. The web request looks normal: a logged-in user sends a message. The WAF sees text. The API gateway sees an authenticated request.

Inside the AI system, the agent retrieves context, reads prior tickets, and decides whether to call a lookup tool. An attacker writes a message that creates false urgency and asks the agent to compare their account with another named customer. The final tool call may be valid JSON, sent to an allowed endpoint, with a token the backend accepts.

The security failure is not necessarily a malformed request. It may be that the agent was allowed to influence an account identifier that should have been bound server-side. Or that retrieved data from one tenant entered the model context for another tenant. Or that the agent carried untrusted instructions across turns until it used a tool outside the intended workflow.

A WAF may see nothing unusual. A complete AI security test should see the boundary failure.

Where prompt testing also falls short

It is tempting to answer this by testing prompts only. Prompt testing is necessary, but it is not enough either.

A model can refuse an obvious jailbreak while the surrounding implementation still leaks data. A prompt can look safe while retrieval pulls in unauthorized context. A model can give a polished answer while an MCP tool was called with unsafe arguments. The finding is not always "the model said something bad." Often, the finding is "the system did something it should not have been able to do."

That is why prompt injection testing is not enough. The model is one layer. The implementation around it determines impact.

What complete AI security validation should test

A complete assessment should still include the web and API surface. Authentication, authorization, tenant isolation, session handling, exposed endpoints, and input handling remain part of the risk. For many AI products, the application layer is still the first place an attacker arrives.

It should also test prompt and model behavior across multi-turn conversations. Single-turn payloads are useful, but agentic systems often fail only after context builds over several turns.

It should test RAG applications for data leakage: retrieval boundaries, source disclosure, private-context exposure, and indirect instructions inside retrieved content.

It should test MCP servers and tools: exposed tool inventory, unsafe arguments, authorization scope, tool-selection abuse, excessive agency, and cross-tool leakage.

It should test memory and session behavior where the system exposes it. Sensitive context should not persist across users, tenants, or unrelated workflows simply because it appeared in a previous conversation.

And it should produce evidence that engineers can use: transcripts, tool-call details, affected layers, expected boundaries, observed impact, and retest guidance. Without evidence, AI security findings become arguments about what the model "probably" meant.

How WAFs and AI validation should work together

This is not a replacement story. It is a coverage story.

WAFs, API gateways, secure coding, access control, logging, and traditional pentesting protect important parts of the system. AI security validation tests the parts those controls were not designed to understand: natural-language manipulation, retrieval context, tool choice, agent memory, and multi-step behavior.

The healthiest security architecture combines both. Keep the WAF. Keep the API gateway. Keep server-side authorization. Then validate whether the AI system built on top of those controls still behaves safely when prompts, data, tools, and permissions interact.

That distinction matters for CISOs. Buying an AI product or shipping an internal agent should not come down to whether a vendor says "we have a WAF." The more useful question is whether the full agentic workflow has been tested against the ways AI systems actually fail.

Where Oxyne fits

Oxyne is built for agentic AI security validation across the complete implementation, not just model prompts and not just web traffic. It helps teams test AI systems through the interfaces and permissions that shape real impact: applications, APIs, prompt/model behavior, RAG, memory/session behavior, tools, MCP, and authorization boundaries.

That includes recurring AI Security Testing for connected AI systems and deeper AI Red Teaming when teams need adversarial campaigns, multi-turn evidence, and focused review of high-risk workflows.

WAFs help protect the web layer. Oxyne helps validate the agentic AI implementation built behind and around that layer. For modern AI systems, serious security programs need both views.