You probably think the security mantra “you can’t protect what you don’t know about” is an inarguable truth. But you would be wrong. It doesn’t hold water in today’s threat landscape.
Of course, it sounds reasonable. Before you secure APIs, you must first discover, inventory, and document them exhaustively. The problem is that this way of thinking has hardened into dogma and ignores how attackers actually attack modern systems.
Modern attackers abuse typical, legitimate behaviors of APIs that are known to defenders.
Put simply, knowing an API exists doesn’t mean you control how it’s used. And in modern environments, misuse at runtime is where risk actually materializes. That’s what we need to focus on.
Where the “Known APIs” Doctrine Came From
The industry’s reliance on API inventories makes sense. So, it makes sense to look into where this idea originated. The cybersecurity community built most security disciplines on the assumption that completeness enables control. For example:
- In network security, you enumerate hosts and segments
- In asset management, you list every device and application.
- In configuration management, you know and govern every setting.
Understandably, API security inherited this mindset. Security teams asked:
- What endpoints exist?
- What operations do they support?
- Who owns them?
- How do we document them?
From there, it was simply a matter of securing what was listed.
In the early days of APIs, this made sense. There weren’t many APIs; they moved slowly, they were mostly internal, and changes were governed centrally. That meant an inventory could genuinely capture most of what was in use. Changes were deliberate, releases were infrequent, and visibility into usage was relatively stable.
So, why doesn’t this approach work anymore? Because API ecosystems have changed.
The Reality: Most “Known APIs” Still Get Breached
As noted, the core problem with the “known APIs” dogma is that many API breaches today involve APIs defenders already know about.
According to the 2026 API ThreatStats™ Report, attackers now favor abuse over bugs, targeting business logic, trust, and usage patterns. It is the runtime behavior that defines API risk, not pre-production testing alone. These are issues that occur in deployed, documented, and actively used APIs, not just in undiscovered ones.
We’ve seen that pattern play out in real-world breaches. Take Salesloft, for example. In August 2025, a threat actor abused compromised OAuth tokens from a legitimate Salesloft Drift integration to exfiltrate large volumes of data from hundreds of Salesforce tenants. Authentication controls, including MFA, were technically intact. The APIs were documented and functioning as designed. What failed was not discovery or awareness, but the ability to detect and stop abnormal use of trusted API access at runtime.
The point here is that merely knowing about your APIs isn’t enough to secure them. Inventories tell security teams what exists. They do little to stop abuse when attackers misuse legitimate APIs.
Why Chasing Complete Inventory Is a Losing Game
Amy Winehouse once said, “Love is a losing game.” The same is true for inventorying APIs.
Modern API ecosystems are inherently dynamic, defined by continuous deployment, ephemeral services, and feature flags and experiences that alter behavior without creating new endpoints. What’s more, partner and API integrations add layers of exposure that shift faster than governance processes can track.
Ultimately, that means that inventories, by their nature, can’t be up to date. By the time an inventory is complete, new endpoints already exist, and the old ones are behaving differently. As a result, security teams end up protecting a historical snapshot rather than a live system.
Inventory is a map – but attackers don’t follow maps. They follow traffic. They go with the flow.
What Attackers Actually Do (and Why Inventory Barely Matters)
To better understand why inventory-first security no longer cuts it, it helps to examine how modern API attacks unfold in practice.
Most API incidents emerge from runtime behavior that inventories cannot model or predict. Abuse unfolds through actions that are valid in isolation but dangerous in combination.
For example, attackers:
- Observe behavior to understand how APIs respond under normal conditions
- Replay legitimate requests at unexpected scale or frequency
- Chain logic across endpoints to bypass business rules and workflow assumptions
They surface this behavior organically through normal interaction with applications:
- Mobile apps expose request structures and workflows
- Browser traffic reveals sequences, dependencies, and parameters
- Error responses leak clues about internal state and logic
- Automation and fuzzing accelerate testing and iteration
None of this requires hidden endpoints or undocumented APIs. Abuse can happen in known, documented, and authenticated surfaces. Even worse, these failures don’t appear in endpoint lists, schemas, or specifications. They only become visible when defenders observe behavior over time and in context.
The Real Control Point: Runtime Behavior, Not Catalogs
So, if inventories don’t surface abuse, what does? Runtime behavior.
Effective API security focuses on how APIs behave, not just how they are described on paper. That means visibility grounded in actual traffic, not static specifications. In practice, this means continuously observing:
- How APIs are used, based on real requests rather than assumed workflows
- Who is using them, across users, services, partners, and automated clients
- At what volume and velocity, including spikes, bursts, and slow-drip abuse
- In what sequence, across requests that form business-critical flows
This is the type of visibility Wallarm provides. We offer runtime insight derived directly from live API traffic, rather than inferred solely from documentation. By analyzing real requests and responses, defenders can see what inventory gaps exist.
That runtime analysis reveals risks invisible to static catalogs:
- Abuse patterns that only emerge over time and repeated interaction
- Anomalous access that looks legitimate when viewed request by request
- Business logic exploitation that spans multiple endpoints and workflows
Because this approach is traffic-driven, it continues to work as APIs change, doesn’t require perfect documentation, and scales with automation and AI-driven traffic.
Wallarm’s API discovery and abuse prevention capabilities both rely on real traffic analysis – using runtime observations to understand exposure, identify sensitive data flows, detect misuse, and respond to abuse as it happens, rather than after documentation catches up.
So… Do Inventories Matter at All?
But let’s not get carried away. We’re not trying to say that inventories are useless. They still matter – they’re useful for governance and prioritization, and a non-negotiable for compliance.
What they don’t do, however, is stop abuse. They don’t detect abnormal behavior or logic exploitation, and they don’t prevent large-scale data exfiltration once it’s underway. We’re not saying you should ditch your inventories – we’re saying that you need to manage your expectations. Keep this distinction in mind:
- Inventory helps you understand your environment
- Runtime protection helps you defend it
Treating inventories as defenses blurs that line – and leaves real risk unaddressed.
A Better Security Question for Leaders to Ask
Ultimately, security leaders need to ask themselves a different question. “Do we know all our APIs?” doesn’t scratch the surface of effective API security. They need to be asking themselves: “Can we detect and stop API abuse – whether we’ve seen the endpoint before or not?”
Inventories will always lag behind change. Even known APIs pose a risk. Only by focusing on runtime behavior, real traffic, and abuse prevention can you lock down all your APIs.
Learn more about how Wallarm’s API abuse prevention capability prioritizes runtime protection to help you stay safe against changing API attacks.
The post The Myth of “Known APIs”: Why Inventory-First Security Models Are Already Obsolete appeared first on Wallarm.
