Of all the OWASP API risks, this is the closest to our own focus: you cannot secure an AI endpoint you do not know exists. Sargha inventories AI assets, and beside them the API endpoints behind your systems: you upload an OpenAPI description per service and Sargha lists what is documented, what is called but never described, and what is deprecated but still in use. Improper Inventory Management is the risk of the forgotten — the deprecated v1 still serving traffic, the staging host exposed to the internet, the acquired company's API nobody documented, the endpoint a departed developer stood up and never mentioned.
APIs proliferate faster than any inventory kept by hand. Every version, environment, and integration is another host and another set of endpoints, and organizations routinely lose track of what they are running. The danger is specific: an old version rarely gets the patches and hardening the current one does, so /v1/ keeps the very bug /v3/ fixed — and it is often still reachable.
Two blind spots: shadow and zombie
Shadow APIs are endpoints security never knew about — stood up by a team in a hurry, inherited in an acquisition, or exposed by a misconfigured deployment. They sit outside every gateway, WAF, and monitoring rule because those controls were never told they existed. Zombie APIs are the opposite: once known, now deprecated, but never actually decommissioned. Both are dangerous for the same reason — they are live attack surface that no one is watching.
POST /v1/users → still live, still vulnerable, watched by no one
Documentation is the other half of the problem. An API without an accurate, current specification cannot be tested, gated, or reasoned about. Undocumented endpoints don't appear in security reviews or automated scans, so they accumulate exactly the flaws the rest of this list describes — broken authorization, misconfiguration, excessive data exposure — with no one positioned to notice.
Building a real inventory
- Discover continuously, don't catalog once. Maintain a live inventory of every API, host, version, and environment through ongoing discovery — traffic analysis, DNS and cloud enumeration — not a spreadsheet that is stale the day it's written.
- Document every endpoint and keep it current. Require an accurate, machine-readable specification per API, and treat drift between spec and reality as a defect.
- Retire deprecated versions on a clock. Give old versions a firm decommission date and enforce it; a version kept alive "just in case" is a zombie in waiting.
- Separate and lock down non-production. Keep staging, test, and development APIs off the public internet, with their own access controls and no real data.
- Route everything through known choke points. Ensure all API traffic passes a gateway you monitor, so an endpoint outside it stands out as the anomaly it is.
Improper Inventory Management is the risk that makes the other nine harder to close, because it hides the very endpoints those controls are meant to protect. Discovery is not a preliminary step you finish and set aside; it is the continuous foundation the entire program rests on. Put plainly — you can't defend what you haven't discovered, and an API you've forgotten is one an attacker is happy to remember for you.
- Try older versions of a live path —
/v1/when you ship/v3/. Forgotten versions often skip the fixes and auth the current one enforces. - Ask whether every deployed endpoint appears in your documentation or gateway. Anything running but undocumented is shadow API surface nobody is watching.
The full, at-scale version — discovering the full inventory — deprecated, staging and undocumented endpoints — that hand-kept lists always miss — is what our assessment runs for you.