AI in WAFs still misses runtime API abuse and data exposure

At a glance

What this is: This is an analysis of how AI is used in WAF and WAAP tools, and its key finding is that edge-based models can detect traffic anomalies but cannot reliably see runtime API abuse or data exposure.

Why it matters: It matters because IAM, API security, and NHI teams increasingly face authenticated abuse from human and non-human consumers, including AI agents, where request-level controls alone cannot prove whether access was authorised or harmful.

By the numbers:

• 82% of organisations have adopted an API first approach, yet a majority of developers still cite unauthorized API activity and sensitive data exposure as top concerns.
• 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.

👉 Read LEVO's analysis of why AI in WAFs misses runtime API abuse

Context

The core governance gap is simple: edge security controls can evaluate requests, but they cannot reliably determine what an API does once it accepts the request. That matters because modern API abuse often looks legitimate at the request layer, especially when it is authenticated, low volume, and driven by non-human consumers such as bots or AI agents.

In practice, that means AI in WAF and WAAP platforms is useful for profiling traffic and suppressing noise, but it is not a substitute for runtime understanding of object access, data handling, or business logic. For IAM and NHI programmes, the issue is the same one that appears in workload identity and API token governance: access is only safe if the downstream action is visible and controlled.

This article is not a product critique. It is a reminder that AI-driven security controls must be judged by the visibility boundary they actually operate within, and that boundary is often narrower than teams assume.

Key questions

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. Do not rely on it to decide whether a request is authorised or whether it exposed data. Those judgments require runtime evidence, because request metadata alone cannot show what the API actually did after the request was accepted.

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. AI models in WAFs see traffic patterns, not execution outcomes, so they can miss business logic abuse, object-level authorisation failures, and sensitive data exposure that only become visible after the application processes the request.

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. If the agent keeps changing one field at a time without progress, the API is usually under-documented or inconsistent. Those signals point to a usability problem, not just a stubborn model.

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.

Technical breakdown

How AI models in WAFs profile API traffic

AI in WAF and WAAP tools usually works as statistical classification at the edge. The model observes request frequency, header patterns, payload size, geo-distribution, and authentication state, then builds a baseline of normal behaviour. It can score anomalies, suppress duplicates, and adapt rate limits to traffic variation. What it cannot do is infer intent with confidence. A request that looks normal may still trigger harmful downstream execution, because the model sees metadata rather than application state. This makes the control useful for scale and noise reduction, but weak for semantic abuse.

Practical implication: use AI for traffic shaping and anomaly triage, not as the final decision-maker for authorisation or data exposure.

Why runtime API abuse looks normal at the request layer

Many damaging API attacks are structurally valid. Business logic abuse, broken object-level authorisation, and sensitive data exposure can all occur through authenticated requests that conform to schemas and sit within normal traffic ranges. The abuse only becomes visible when you inspect what object was accessed, what code path executed, and what data moved as a result. That is why request-level machine learning often misses the real issue. It can recognise unusual shape, but not misuse of legitimate workflow. Runtime visibility adds the missing context by connecting requests to execution outcomes.

Practical implication: pair WAF telemetry with runtime API monitoring so that suspicious traffic can be tested against actual object access and data handling.

Where AI-driven controls create overconfidence and drift

AI-based enforcement introduces its own risk when teams assume the model understands the application. As APIs change, models trained on historical traffic can drift, producing false positives or blind spots. Attackers can also probe opaque systems to learn which behaviours trigger enforcement and which pass through. In a governance sense, this is a visibility problem and a validation problem at the same time. The right question is not whether the model is advanced, but whether its decisions can be explained and checked against observed runtime behaviour.

Practical implication: establish feedback loops that compare AI decisions with runtime evidence and retune models when the application changes.

NHI Mgmt Group analysis

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.

Runtime visibility is the named control gap that changes the security outcome. This article exposes what we would call a request-layer blind spot: security tooling can see the request, but not the consequence. That gap matters in IAM and NHI programmes because authenticated machine consumers often look legitimate until the application executes their request. Organisations that cannot observe execution outcomes cannot reliably prove least privilege, policy conformance, or data minimisation.

AI-driven API defence will increasingly be judged by explainability and auditability. In operational terms, that pushes this problem into NIST-CSF detection and monitoring, and for identity-heavy environments into OWASP-NHI thinking about tokenised access and workload behaviour. The market is moving toward tools that correlate request context with downstream action, because that is what lets security teams separate harmless variability from real abuse. Practitioners should evaluate controls by what they can verify, not by how confidently they classify traffic.

API security is becoming identity governance for non-human consumers. As API consumers include bots, service accounts, and AI agents, the difference between a benign request and a risky one increasingly depends on who or what is calling the API and what they are allowed to do next. That makes the intersection between IAM, NHI, and API security much tighter than many teams have assumed. Practitioners should govern consumers, tokens, and runtime actions as one control problem.

What this signals

Request-layer controls will remain necessary, but they are no longer sufficient. As more API consumers are non-human, the governance question shifts from whether traffic looks legitimate to whether the downstream action is actually acceptable. Teams that cannot connect request telemetry to execution evidence will struggle to defend their access decisions in audits, investigations, or incident reviews.

The practical direction of travel is toward control stacks that combine WAF telemetry, API inventory, and data discovery. That combination gives security teams enough context to identify when AI-based detections are meaningful and when they are simply flagging harmless variation. For identity-led programmes, the same pattern applies to workload identity and token governance: the action matters as much as the authentication event.

For practitioners

• 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.
• Test model drift after application changes Re-run validation whenever endpoints, workflows, or authentication patterns change so the model does not inherit stale baselines.
• Correlate API alerts with data classification Join API monitoring with sensitive data discovery so enforcement can distinguish harmless request variation from access to regulated or personal data.

Key takeaways

• AI in WAFs helps with traffic analysis, but it does not see the runtime consequences of an API request.
• Authenticated API abuse, including business logic attacks and data exposure, can still look normal to edge-based models.
• Security teams need runtime visibility and data context before they can trust AI-driven API enforcement.

Key terms

• Runtime Visibility: The ability to observe what an AI client actually accessed, which tools it used, and how it behaved during a session. It is more useful than entitlement snapshots for agent governance because it captures executed reality, not just approved access.
• Edge-Based Detection: Edge-based detection evaluates traffic before it reaches the application, using request metadata such as headers, payloads, frequency, and client attributes. It is useful for broad anomaly spotting, but it cannot verify downstream business logic, object-level access, or the security impact of the request.
• Business Logic Abuse: Business logic abuse occurs when an attacker uses a valid API in a way the application designer did not intend, such as exceeding limits, chaining actions, or misusing workflow assumptions. The API is functioning technically, but governance and policy are failing at the intent layer.
• Non-Human Consumer: A non-human consumer is any service, bot, workload, or AI agent that calls an API on behalf of a process rather than a person. These actors create identity and authorisation challenges because they can be authenticated, widely distributed, and difficult to govern with human-centric controls.

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

👉 LEVO's full article breaks down the edge-versus-runtime control boundary for API security teams

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the broader security programme they operate.