Every API that gets built goes through roughly the same lifecycle. Someone writes it, ships it, documents it if the team has the discipline to, and it lands in whatever catalog or inventory exists, assuming one does. Then, months or years later, a second version replaces it, and the first version is supposed to get decommissioned. In practice, decommissioning is the step that quietly gets skipped, because nothing forces it to happen and nobody's performance review is tied to cleaning it up. The old version stays live, often with weaker authentication than whatever replaced it, still accepting requests from anyone who happens to know the URL.
That's one path to a shadow API. There are several others, and understanding how they actually form is most of what makes discovery effective, because a process built to catch one kind will reliably miss the rest.
How shadow APIs actually accumulate
The most common source is the abandoned or superseded endpoint: old versions, deprecated integrations, and staging or test infrastructure that was supposed to be temporary and never got torn down. A large share of the shadow APIs uncovered in any real audit turn out to be sitting in dev, test, or staging environments, frequently with authentication that was never hardened because "it's just for testing" was true right up until it wasn't.
A second source is the integration nobody remembers approving. A partner needed an endpoint for a one-time data pull two years ago, someone stood it up fast to unblock the deal, and it's still accepting requests long after anyone on the current team remembers why it exists. These are especially common at companies that have gone through any kind of partnership, acquisition, or platform migration, since institutional memory about why an endpoint exists erodes quickly once the person who built it moves on.
A third, newer source is AI itself. Agentic tools and LLM integrations that use function calling, or connect through MCP (the Model Context Protocol used to link AI agents to external tools and data sources), routinely generate their own API calls as part of completing a task, sometimes dynamically, in ways that were never written down as a deliberate feature. These calls frequently bypass the review process a traditional API endpoint would go through before shipping, because nobody sat down and designed them as a documented capability. They emerged as a side effect of wiring an agent up to do something useful. An agent given access to a CRM to look up customer records, for instance, might construct calls against endpoints nobody explicitly built for that purpose, calls that exist and function correctly but were never designed, reviewed, or logged the way a normal API would be.
Why this specific blind spot matters more than it sounds like it should
Broken Object Level Authorization (BOLA) is the vulnerability class where an API fails to properly verify that the person making a request is actually authorized to access the specific object they're asking for (a particular customer record, a particular invoice, a particular account) rather than just confirming they're authenticated at all. It has held the number one spot on the OWASP API Security Top 10 in every edition published since 2019, an unusually long run for any single category given how much the underlying technology landscape has shifted in that time. It was the mechanism behind the Optus breach, which exposed 2.1 million records, and the T-Mobile breach, which exposed 37 million customer accounts.
Shadow APIs don't make BOLA more likely because unreviewed code is inherently worse written, though it often is, since nobody's applying consistent authorization patterns to endpoints nobody's actively reviewing. The bigger issue is coverage. A security review (whether it's a manual audit, an automated scanner, or a penetration test) can only assess what it knows to look at. An endpoint absent from the documentation, missing from the API gateway's official route list, and unmentioned in any architecture diagram simply doesn't get reviewed, because reviewing it would first require knowing it exists. A meticulously executed authorization review of your documented API surface tells you nothing about the dozen endpoints nobody put on the list in the first place.
What discovery actually looks like in practice
There isn't one technique that finds everything, which is part of why shadow API discovery is a genuinely harder problem than it sounds from the outside. A few approaches, used together, cover most of the ground.
Traffic-based discovery watches real network and API activity as it happens and builds an inventory from what's actually being called, rather than from what documentation claims should exist. This catches endpoints that are live and receiving requests right now, regardless of whether anyone remembered to write them down, which makes it one of the more reliable methods precisely because it doesn't depend on human recordkeeping being accurate or current.
Code and configuration scanning goes the other direction, examining source repositories, API gateway configurations, and infrastructure-as-code definitions for routes defined in code that may not be receiving heavy traffic right now, or that never made it into a central catalog even though they're technically live and reachable. This catches what traffic monitoring alone might miss during a short observation window, since not every endpoint gets hit constantly.
Dedicated sweeps of dev, test, and staging environments deserve their own mention, since these environments are disproportionately where shadow APIs accumulate and disproportionately under-defended when they do. A quick, honest look at what's actually running in a staging environment spun up eighteen months ago and never fully decommissioned often turns up more real exposure than a far more thorough review of production.
And increasingly, discovery has to specifically account for what AI agents and LLM integrations are calling on an organization's behalf, since these calls form and change dynamically in a way traditional APIs generally don't, and they're the newest, fastest-growing category of endpoint that existing documentation and review processes simply weren't designed to catch.
What separates a useful inventory from a long list
Finding forty shadow APIs isn't itself useful information. Finding forty shadow APIs and knowing which three are actually reachable from the internet and actually expose sensitive data is useful information, and the difference between those two outputs is most of what separates a discovery process worth running from one that just generates a report nobody opens twice. Good shadow API discovery runs continuously rather than as a one-time project, since new endpoints get created constantly and an inventory from six months ago is already going stale by the time anyone reads it. It should also run agentlessly, without requiring code changes or production interruptions to deploy, since a discovery process that itself needs an engineering sprint to set up tends to get deprioritized indefinitely by teams that are already stretched thin.
Chronoloq's API discovery engine was built around exactly that distinction. It runs continuously across an organization's environment, surfaces undocumented, misconfigured, and legacy endpoints (including the dynamic calls AI agents generate) and scores each finding for real-world severity, so a small team with limited hours can work down a short, ranked list instead of triaging a spreadsheet full of forty equally unlabeled findings.
An API you don't know exists is not an API you can secure, and that isn't a rhetorical flourish: it's the literal, practical bottleneck sitting behind most of the API security incidents that end up in the news. Every other control (authorization checks, rate limiting, monitoring) depends on the endpoint being on someone's radar to begin with. For most organizations that have added any AI capability in the last year or two, the unglamorous starting point is simply finding out how many of these endpoints are already live and quietly accepting requests.