API security beyond WAF needs runtime identity and context

At a glance

What this is: This is an AccuKnox analysis of why API security has to move beyond WAF-only thinking, with the key finding that runtime context, identity, and inventory visibility determine whether modern API threats are detected.

Why it matters: It matters because IAM, PAM, and cloud security teams increasingly need API controls that understand workload identity, token use, and service-to-service trust, not just inbound traffic at the edge.

By the numbers:

• More than 50% of recorded cybersecurity exploits in 2024 were API-related, roughly double the 2023 volume.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.

👉 Read AccuKnox's analysis of why API security must go beyond WAF

Context

API security fails when teams assume the perimeter is the control plane. In practice, the highest-risk API abuse often happens after authentication succeeds, inside service meshes, or through undocumented endpoints that a WAF cannot see or interpret.

That gap matters for identity and access governance because API abuse is rarely only a network problem. It is also a workload identity problem, a secrets exposure problem, and in some environments an agentic AI problem when internal tools and MCP-style integrations widen the callable surface.

Key questions

Q: What breaks when API security depends only on gateways and WAFs?

A: Teams lose visibility into business logic abuse, object-level authorisation failures, and low-and-slow reconnaissance that looks legitimate at the transaction layer. Gateways and WAFs still have value, but they cannot reliably judge intent, object ownership, or whether a valid session is being used outside its intended scope. That leaves a major gap in runtime control.

Q: Why do APIs need stronger identity controls than standard OAuth deployments provide?

A: Standard OAuth deployments often prove that a token was issued, not that the original client is still presenting it. That leaves room for replay, theft, and impersonation. Stronger controls such as mTLS, certificate-bound tokens, and narrow scopes make API access harder to transfer and easier to govern.

Q: How can security teams tell whether API discovery is actually working?

A: API discovery is working when newly created or changed endpoints appear quickly in the inventory, each has an accountable owner, and sensitive-data handling is visible in the same record. A healthy programme also shows that posture checks, encryption reviews, and access controls are triggered from the inventory rather than applied after incidents or audits.

Q: Who is accountable when a public API leaks data through valid access?

A: Accountability usually spans application owners, IAM or platform teams, and security leadership, because the failure is shared between access design, endpoint logic, and monitoring. In regulated environments, the organisation must also be able to show that access controls and logging were proportionate to the sensitivity of the data involved.

Technical breakdown

Why WAFs miss authorization failures like BOLA

A WAF evaluates requests at the boundary, where it can see syntax, patterns, and sometimes rate. Broken Object Level Authorization, or BOLA, happens deeper in the application when a valid user changes an object identifier and receives another user's data. The request is not malicious by signature, so the perimeter control has no context to determine ownership or entitlement. That makes BOLA an authorization failure, not a filtering failure. Runtime policy must compare identity claims, object ownership, and application state at the point of access, otherwise the response can leak data while the request still appears normal.

Practical implication: Enforce object-level checks at the policy layer, not only at the gateway.

How shadow APIs and east-west traffic bypass perimeter security

A WAF only protects what it knows exists and only when traffic crosses its line of sight. Shadow APIs, zombie APIs, and east-west service-to-service calls often live outside that boundary, especially in Kubernetes environments where internal trust assumptions outlast the original architecture. Those APIs may expose older authentication methods, stale routes, or direct data-store access that never appears in a WAF rule set. Continuous discovery is therefore foundational. Teams need runtime telemetry from Kubernetes, service meshes, or eBPF so the inventory reflects actual execution paths rather than documentation that may already be stale.

Practical implication: Build continuous API inventory from runtime telemetry, not from static documentation.

Why identity-aware runtime policy changes API defence

Runtime API security becomes materially stronger when the control layer can bind requests to identity context. JWT claims, workload identity, and service attributes let the system distinguish a trusted internal service from public traffic hitting the same endpoint. That matters for throttling, object access, and privilege decisions because the same API can require very different enforcement depending on who or what is calling it. CNAPP correlation adds another layer by linking API activity to the calling workload and the data store touched, which is where over-privilege and lateral abuse usually emerge.

Practical implication: Tie API enforcement to workload identity and downstream data access before trusting any request.

Threat narrative

Attacker objective: The objective is to reach sensitive data or internal service privileges through legitimate-looking API activity that the perimeter does not recognise as hostile.

1. Entry occurs through a valid-looking API request or internal service call that bypasses signature-based perimeter filtering.
2. Escalation happens when the attacker abuses authorization gaps, shadow endpoints, or service-to-service trust to reach data or internal resources.
3. Impact follows when the attacker extracts records, reads sensitive stores, or moves laterally through over-privileged workloads without triggering the WAF.

NHI Mgmt Group analysis

API security has become an identity governance problem as much as a traffic-filtering problem. The article is right to separate WAF value from modern API defence. Once requests are authenticated, the key question becomes whether the calling identity is entitled to the object, service, or data store it can reach. That is a governance issue, not just a detection issue, and it applies equally to human users, service accounts, and machine-authenticated workloads.

Continuous inventory is the named control gap hiding behind most API compromise stories. Shadow APIs, zombie APIs, and east-west paths create a runtime visibility gap in which defenders are enforcing policy against an incomplete map. This is especially dangerous in containerised environments where workload identity is fluid and call paths change faster than review cycles. The practitioner conclusion is straightforward: if the inventory is not runtime-derived, the policy is already stale.

CNAPP correlation is only useful when it is treated as identity evidence, not as another dashboard. The value is in linking the API call, the workload identity, and the downstream data exposure into a single control narrative. That is what turns a technical telemetry feed into evidence for access review, incident triage, and privileged pathway reduction. Teams that cannot connect those three layers will continue to miss who actually accessed what.

API abuse is now part of the broader non-human identity attack surface. Service accounts, tokens, and machine-authenticated requests are increasingly the real actors behind high-volume API traffic. That means NHI governance and API security can no longer be separated cleanly, because the same over-privilege and secret sprawl problems that drive NHI breaches also shape API abuse. Practitioners should treat API enforcement as an extension of machine identity governance.

What this signals

Shadow API visibility will become a governance benchmark, not a niche engineering metric. As API estates grow across Kubernetes, gateway, and service-mesh layers, teams will be judged on whether they can prove they know what is actually live. That makes runtime discovery and entitlement mapping part of security assurance, not just observability.

Machine identity will sit at the centre of API security decisions. When internal services, tokens, and workload identities all drive API access, the question is no longer whether a request is allowed, but whether the calling identity should exist with that level of reach. The programme implication is tighter alignment between IAM, cloud security, and application security.

Runtime context is becoming the evidence layer for compliance and incident response. If your programme cannot show which APIs were active, who or what called them, and what data they touched, you will struggle to answer audit and breach questions with confidence. API security control evidence will increasingly depend on correlated runtime telemetry.

For practitioners

• Map API inventory from runtime telemetry Use Kubernetes telemetry, service mesh data, or eBPF traces to identify active, shadow, zombie, and orphan APIs before you tune enforcement rules. A static spec is not enough for production inventory.
• Move authorization checks to the policy layer Enforce object ownership and entitlement checks at the point of access so BOLA cannot pass as a valid request. Gateway filtering alone cannot validate whether the caller should see the returned object.
• Bind API decisions to workload identity Use JWT claims, service identity, and CNAPP context to apply different policy to internal services, public clients, and machine-to-machine calls hitting the same endpoint.
• Correlate API calls with downstream data access Track which services read which databases and secrets so over-privileged paths are visible during review and incident response. This is where hidden east-west abuse usually surfaces.

Key takeaways

• WAFs still have a role, but they cannot govern API authorisation, shadow endpoints, or east-west abuse on their own.
• The core evidence gap is runtime visibility, because the attack surface often lives outside documented specs and perimeter logs.
• API security programs need identity-aware policy, workload context, and continuous inventory to keep pace with modern abuse patterns.

Key terms

• Shadow API: An API endpoint that exists in production but is not fully known, reviewed, or governed by the security programme. Shadow APIs often emerge through fast delivery, copy-paste development, or overlooked internal routes, and they create untracked exposure because they sit outside inventory, policy, and ownership processes.
• Broken Object-Level Authorization: A failure to check whether an authenticated identity may access a specific object, record, or device. The request succeeds because the credential is valid, but the application does not enforce per-object entitlement. In NHI environments, this turns a legitimate token into cross-resource exposure.
• Workload Identity: The identity assigned to a software workload — such as a containerised application, serverless function, or microservice — enabling it to authenticate to other services without storing static credentials.
• CNAPP Correlation: The process of linking cloud, workload, identity, and data signals into one security view. For API security, it helps show which service made a call, what privilege it used, and which datastore or sensitive asset the call touched, turning fragmented telemetry into actionable governance evidence.

What's in the full article

AccuKnox's full article covers the operational detail this post intentionally leaves for the source:

• Runtime deployment examples for WAF, gateway, and service-mesh integration in production API stacks
• Detailed mapping of OWASP API Top 10 categories to specific runtime and identity controls
• Practical correlation patterns for CNAPP, workload identity, and sensitive data-store access
• Compliance-focused evidence examples for audit-ready runtime API monitoring

👉 AccuKnox's full post covers the runtime control stack, OWASP API risk mapping, and compliance evidence details.

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 already run.