The APIs You Can’t See: Closing the Internal Blind Spot

Most API security programs are built around one assumption: if an API matters, it eventually shows up in traffic that crosses the perimeter. Gateways, load balancers, and edge proxies see that traffic, so the security team sees it too. The model works well for the front door.

The problem is that the front door was never where most of the APIs lived.

The internal blind spot

Inside a typical enterprise network, there are far more APIs than anyone has cataloged. Microservices call each other internally. Internal dashboards expose admin functions. Data pipelines, batch jobs, and legacy services all speak HTTP to something. None of this traffic reaches the public internet, so none of it is visible to tools that only inspect edge traffic.

This matters because internal APIs are frequently the least hardened surface an organization has. Teams assume the network boundary is protecting them, so authentication gets treated as optional, TLS gets skipped, and API specifications get published to whoever can reach the host. The moment an attacker gains any foothold inside the network, through a phished credential, a compromised dependency, or a misconfigured service, that soft interior becomes the whole game. You cannot defend an inventory you have never seen.

This summer at Cequence, I built the Cequence Internal Crawler to address that gap directly.

How the crawler works

The Cequence Internal Crawler is designed to run inside a private network and discover what is actually running there, decide what is and is not an API, and report structured results back to a central platform.

The workflow is straightforward. It scans the address space of the network it's deployed in to find live hosts. It probes each discovered host to understand what it is, then classifies it as an API host, an MCP server, or neither, so the output isn't drowning in noise from print servers and file shares. For hosts that are APIs, it looks deeper: it identifies whether an API gateway sits in front of them, and it evaluates each endpoint for a set of security findings, each tagged with a severity level.

None of this requires touching the target hosts. There are no agents to install on the services being scanned, no code changes, no network reconfiguration. The crawler observes from the network the way an attacker on that same network would, which is the perspective that actually matters when assessing exposure.

The findings that matter

Discovery is only useful if it tells you what to fix. The findings the crawler surfaces are the ones that turn an unknown internal service into a real risk:

• Unauthenticated APIs: endpoints that respond to requests with no credentials at all, often because someone assumed the network itself was the security control.
• Exposed API specifications: Swagger or OpenAPI documentation served openly, handing an attacker a complete map of the API.
• GraphQL endpoints, which carry their own introspection and query-depth concerns.
• Weak or misconfigured TLS, where internal services fall back to outdated or absent encryption because "it's just internal traffic."

Each finding gets a severity so a team can triage instead of guessing.

Why a unified view matters

The value isn't a separate internal report living in its own dashboard. Results from internal scanning are most useful sitting alongside external API inventory in one place, using the same findings model and dashboards. That's what turns the security conversation from "here's our public attack surface" plus a shrug about everything behind the firewall into a single, honest map of every API and every issue attached to it.

What this taught me

Building this made a general principle concrete: coverage isn't a function of how much traffic you can see; it's a function of where you're willing to look. Most of the interesting risk in a typical network isn't at the edge; it's in the internal surface nobody's watching because nothing forced anyone to look. Designing a crawler to observe that surface the way an attacker would, rather than the way a compliance checklist would, changed how I think about what "asset inventory" actually needs to mean.

This was built as part of my work at Cequence, where it feeds into the broader API security platform the team maintains.