TL;DR: WAFs and WAAP platforms reduce perimeter risk in modern application environments, but LEVO argues they still stop at request inspection and cannot validate authorization correctness, data exposure, or internal API behaviour after traffic is accepted. Runtime API security becomes the missing layer for proving that APIs behave safely in production, not just that they filter attacks at the edge.
At a glance
What this is: LEVO argues that WAFs and WAAP platforms address different edge threats, but neither can validate whether APIs behave safely after traffic is accepted.
Why it matters: IAM, API security, and NHI teams need runtime assurance because authorization failures and data exposure often occur after authentication, when edge controls have already done their job.
Context
Web application security controls were designed for a different traffic model than the one most enterprises now run. As APIs, mobile clients, microservices, and third-party integrations dominate application traffic, perimeter tools can still filter attacks but cannot confirm whether the application makes the right access decision once a request is accepted. That gap matters whenever identity, privilege, and data exposure are decided inside the service, not at the edge.
This article is really about the security governance gap between request inspection and behavioural assurance. WAFs and WAAPs can reduce noise and block known abuse, but they do not prove that object-level authorization, service-to-service access, or response shaping is correct in production. For IAM and NHI practitioners, the identity bridge is clear: authenticated access is not the same as authorized access, especially when machines, integrations, and internal APIs are involved.
Key questions
Q: What breaks when edge controls are used as proof of API security?
A: Edge controls can show that a request was filtered or shaped correctly, but they do not prove that the service enforced the right authorization decision after acceptance. That is where broken object level authorization, excessive data exposure, and workflow abuse occur. Practitioners should treat edge inspection as a gate, not as evidence of safe execution.
Q: Why do authenticated API users still create security risk?
A: Because valid credentials can still be abused. Attackers often steal keys, tokens, or user credentials and then use the API exactly as designed, which makes the activity look legitimate at the protocol level. The risk sits in what the caller can access and how much data they can retrieve, not just in whether they passed authentication.
Q: What are the signs that a WAAP-only approach is failing to protect APIs?
A: The main warning signs are missed low and slow reconnaissance, weak detection of behavioral anomalies, and poor visibility into whether requests match expected user intent. If security teams cannot connect related API activity over time, they are likely to miss abuse, misuse, and zero day style manipulation. A WAAP that only checks patterns in isolated requests will leave gaps.
Q: When should organisations rely on WAF, WAAP, and runtime API security together?
A: Use all three when applications are API-heavy, distributed, or identity-driven. WAF filters classic web attacks, WAAP adds API-aware edge inspection, and runtime API security validates what happens after acceptance. If you only have perimeter controls, you can reduce noise without proving that access, data return, and internal workflows are safe.
Technical breakdown
Why edge inspection stops short for API authorisation
WAFs and WAAP platforms evaluate incoming requests before application logic executes. They can inspect signatures, schemas, payload patterns, and abuse indicators, but they do not see the runtime decision that determines whether a caller may access a specific object, workflow, or response. That is why valid-looking requests can still produce broken object level authorization, excessive data exposure, or workflow abuse. The control is good at filtering traffic; it is not designed to prove behavioural correctness. In API-heavy architectures, that distinction is critical because the security failure often lives in the service’s decision logic, not in the request shape.
Practical implication: Treat edge inspection as ingress control, not as proof that authorization or data handling is correct.
How WAAP extends WAF coverage without closing the runtime gap
WAAP expands classic WAF coverage to structured payloads such as JSON and XML, adds schema validation, and introduces behavioural analysis for bot and automated abuse. That makes it more suitable for API-first and cloud-native environments where traffic is less like HTML forms and more like machine-to-machine exchange. But WAAP still operates at the edge. If a request is authenticated, well formed, and behaviourally plausible, it will often pass even when the downstream service exposes too much data or authorizes the wrong object. The limitation is architectural, not operational: edge context cannot fully represent execution context.
Practical implication: Use WAAP to reduce attack noise, then validate that internal services enforce the intended access rules.
Why runtime API security changes the assurance model
Runtime API security observes how APIs behave in production, including what data is returned, which objects are accessed, and how internal or undocumented endpoints behave across services. That shifts the question from whether traffic looked safe to whether the system actually behaved safely. This is especially important for service-to-service calls, partner callbacks, and shadow endpoints that never traverse the edge. For identity governance, runtime visibility matters because machine identities, delegated access, and service credentials often operate with high trust and low scrutiny. Without runtime evidence, enterprises confuse filtered traffic with controlled access.
Practical implication: Add runtime validation wherever APIs enforce authorization, handle sensitive data, or rely on internal trust relationships.
Threat narrative
Attacker objective: The attacker or abusive caller aims to use valid API access to obtain data or perform actions that the service never intended to allow.
- Entry occurs through authenticated, schema-compliant API traffic that appears normal to edge controls.
- Escalation happens inside the application when the service accepts the request but fails to verify object-level authorization or limits on data exposure.
- Impact follows as legitimate-looking requests return unauthorized records, over-broad responses, or unsafe internal flows that perimeter tools never inspect.
Breaches seen in the wild
- Palo Alto Networks Salesforce data theft 2025: Stolen Drift OAuth tokens exposed Palo Alto Networks CRM data, including support notes where some customers had shared credentials.
- Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Edge security is necessary but no longer sufficient for modern API governance. WAFs and WAAP platforms still matter because they reduce classic abuse and enforce structure at the boundary. But the core governance problem has moved inward: modern application risk now depends on whether services make the right decision after authentication. Practitioners should treat edge controls as a first line, not the evidence that an API is behaving safely.
Authorization correctness is now a runtime property, not a perimeter property. If a control cannot observe object access, response content, or internal service flows, it cannot prove that least privilege is actually being enforced. That is why edge success metrics can coexist with serious exposure. For identity teams, this reinforces a hard truth: authenticated machine or human access does not guarantee entitled access, especially in distributed application chains.
Runtime API security exposes a verification trust gap that traditional web controls leave open. The article’s strongest contribution is the reminder that traffic inspection and behavioural assurance are different disciplines. The governance model must move from blocking bad requests to proving safe execution. Practitioners should align assurance controls to where the decision is made, not where the packet first appears.
Machine identity makes the runtime gap more consequential, not less. Service accounts, tokens, and delegated integrations often operate with broad trust and limited human oversight. When those identities call APIs internally, perimeter tooling has little or no visibility, yet the access decision still has real data and privilege consequences. Security teams should govern those flows as identity-dependent runtime behaviour, not as simple network traffic.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Read next: Ultimate Guide to NHIs — Standards
What this signals
Runtime API assurance: the practical governance shift is from blocking malformed traffic to proving that services enforce access correctly after authentication. That shift matters for IAM, PAM, and NHI programmes because machine identities often hold the trust that edge tools cannot interpret. Practitioners should assume that internal APIs and delegated workflows need their own evidence of control, not just perimeter coverage.
A layered model is now the more defensible architecture for API-heavy environments: WAF for classic web exposure, WAAP for payload and behavioural filtering, and runtime controls for execution truth. The signal for security teams is not to replace edge tooling, but to stop using it as a proxy for authorization assurance.
For practitioners
- Map API trust boundaries to execution points Document where authentication ends and authorization, object selection, and response construction begin so you know which decisions edge controls cannot validate.
- Validate runtime behaviour for sensitive APIs Prioritise production observation for APIs that handle regulated data, internal service calls, partner callbacks, or delegated machine access.
- Inventory shadow and undocumented endpoints Find internal routes, callbacks, and service-to-service interfaces that never pass through WAF or WAAP enforcement and bring them into governance.
- Check authorization on object access paths Test that callers can only retrieve or mutate the records, fields, and workflows they are actually entitled to access.
Key takeaways
- WAFs and WAAP platforms still do useful work at the edge, but they do not prove that APIs enforce the right access decision after acceptance.
- Runtime API security matters because the most damaging failures often arise inside the service, where authorization and data handling are actually decided.
- For IAM and NHI teams, the governing question is no longer only who authenticated, but whether that identity was entitled to the object, workflow, or data returned.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API8 — Security Misconfiguration | The article centres on edge controls missing runtime and internal API exposure, a core API security gap. |
| API5 — Broken Function Level Authorization | The article highlights authorization failures that edge inspection cannot validate. | |
| API6 — Unrestricted Access to Sensitive Business Flows | The runtime gap includes workflows and business flows that appear valid at the request layer. | |
| Recommendation — Apply API8 thinking to close inspection gaps where APIs drift beyond edge-enforced assumptions. Test function-level authorization at runtime wherever authenticated requests can still reach sensitive actions. Map sensitive business flows and verify they cannot be exercised by callers outside their intended scope. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The core governance issue is entitlement validation after authentication in distributed APIs. |
| Recommendation — Align API runtime checks with PR.AA-05 so access decisions are enforced where the service executes. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The article’s runtime assurance gap exposes over-broad service and object access. |
| Recommendation — Apply AC-6 to minimise service and user entitlements that edge tools cannot verify in production. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Abuse of valid API access often enables post-authentication movement across services and data. |
| Recommendation — Map authenticated API abuse to TA0006 and TA0008 to hunt for privilege misuse across service chains. | ||
Key terms
- Runtime API security: Runtime API security is the protection of application programming interfaces while they are actively handling live traffic. It focuses on authenticating callers, authorizing each request, validating inputs, limiting abuse, and detecting anomalous behavior in real time. It also includes securing tokens, enforcing transport encryption, and monitoring API interactions for misuse or data exposure.
- Web Application Firewall: A web application firewall inspects HTTP traffic and applies rules to detect or block malicious requests and responses. Unlike a network firewall, it understands application-layer content such as headers, parameters, and body fields, which lets it catch attacks like injection and path probing.
- Web Application and API Protection: Web Application and API Protection is the set of controls used to secure websites, web apps, and the APIs they expose. It combines traffic inspection, authentication, authorization, input validation, threat detection, and abuse prevention to reduce attacks such as injection, credential theft, scraping, and automated misuse across application interfaces.
- Object Level Authorization: Object level authorization controls access to individual records or resources, not just to an endpoint. It prevents users from reaching data that is technically available through a route but should remain hidden according to policy, role, or ownership. This is a key safeguard against broken access control.
Deepen your knowledge
The NHI Foundation Level course covers NHI governance, machine identity security, and secrets management through the industry's only accredited NHI security programme. It helps practitioners connect identity governance to access decisions that now happen across APIs, services, and automated workflows.
Published by the NHIMG editorial team on September 6, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org