Notifications
Clear all
Topic starter
06/09/2026 3:45 pm
TL;DR: AI and machine learning in WAF and WAAP tools are good at pattern detection, anomaly scoring, and alert reduction, but LEVO says they operate only on edge-level request metadata and cannot see execution outcomes. That leaves business logic abuse, object-level authorisation failures, and sensitive data exposure outside their decision boundary, so runtime visibility remains essential.
NHIMG editorial — based on content published by LEVO: AI in WAFs still misses runtime API abuse and data exposure
By the numbers:
- 51% worry about unauthorized agent calls and 49% about sensitive data access via API consumers such as AI agents.
- 84% of security professionals experienced at least one API security incident in the past year.
Questions worth separating out
Q: How should security teams use AI in WAFs without overtrusting it?
A: Treat AI in WAFs as a scaling aid for anomaly detection, alert reduction, and traffic profiling.
Q: Why do authenticated API attacks often bypass AI-based detection?
A: Because many attacks are low volume, schema-valid, and behaviourally normal at the request layer.
Q: What are the signs that an AI agent is failing against an API?
A: Common signs include endless retry loops, repeated 400 or 422 responses, incorrect parameter guesses, and confusion over required fields or naming patterns.
Practitioner guidance
- Map AI decisions to runtime outcomes Require every high-risk WAF or WAAP alert to be validated against object access, state change, or data read/write evidence from runtime telemetry.
- Separate traffic noise from enforcement decisions Use machine learning to reduce alert volume and detect volumetric anomalies, but keep authorisation, data exposure, and business logic decisions tied to runtime controls.
- Review API consumers as identity subjects Inventory service accounts, bots, and AI agents that call APIs, then define what each consumer can access and which downstream actions are acceptable.
What's in the full article
LEVO's full article covers the operational detail this post intentionally leaves for the source:
- The specific AI and machine learning functions used in WAF and WAAP environments, including anomaly scoring and adaptive rate limiting
- The operational distinction between edge-level inspection and runtime visibility for API security
- Examples of how business logic abuse and object-level authorisation failures evade request-layer controls
👉 Read LEVO's analysis of why AI in WAFs misses runtime API abuse →
AI in WAFs and runtime API abuse: are your controls keeping up?
Explore further
06/09/2026 3:45 pm
AI in WAFs is a pattern-detection layer, not an authorisation control. The vendor’s core argument is correct: edge models can identify statistical irregularities, but they cannot verify whether an API request was allowed to access a specific object or dataset. That means teams should stop treating anomaly scoring as proof of policy enforcement. For API-heavy programmes, the control question is runtime visibility plus access validation, not simply better model training.
A question worth separating out:
Q: Should organisations prioritise runtime visibility or better AI models for API security?
A: Runtime visibility should come first when the risk involves authorisation correctness, business logic, or sensitive data exposure. Better models can improve triage, but they do not close the visibility gap. Once runtime evidence exists, AI can support prioritisation and reduce noise without being asked to make blind trust decisions.
👉 Read our full editorial: AI in WAFs still misses runtime API abuse and data exposure
