What it is
LLM Broker Exposure Scan reads your repositories, environment files and CI configuration and checks every LLM endpoint it finds against the documented official provider endpoints. Anything that isn't one gets reported, whether or not Kcalbin can identify who runs it. A registry adds attribution and severity for the hosts that are already documented; unnamed hosts are still flagged, just labeled unknown.
The reason for checking against a known-good list rather than a known-bad one is simple: new relay endpoints show up all the time, often on throwaway domains, so a blocklist is always behind. In testing, a planted endpoint on a domain the registry had never seen was still flagged, because the check isn't "is this domain bad" — it's "is this domain the provider."
The scan covers source files in Python, JavaScript/TypeScript, Go, Ruby, Java, Rust, PHP, C# and shell, along with `.env` and env-template files, YAML, JSON, TOML, INI, properties files, CI configuration including GitHub Actions, and Docker, Compose, Makefile and Terraform setups. What comes back is a findings report with file, line number and the offending line, a severity rating by channel type, attribution where it's known with a public source cited, and a JSON report you can feed into your own pipeline.
There are two ways to buy it. A one-time scan is $390 and covers your codebase and configuration, with the registry as of the scan date and sources cited. Continuous monitoring is $1,490 a year, runs as often as you like, updates the registry as new relay endpoints surface, exits non-zero on findings so it fits into CI, and includes re-scans on request. The registry is the part that goes stale — that's the stated reason monitoring is sold as a subscription and the scan isn't.
Severity isn't uniform across findings. Reverse-engineered access and mixed-channel relays rank critical. Named commercial aggregators rank medium, because routing through one is often a deliberate choice a team made on purpose, not something that snuck in.
What it does not do
This is a narrow detector, not a security suite, and it says so on its own page.
It reads configuration and source code — not live network traffic. If a relay is injected at runtime by a secret manager, or set through an environment variable that's never written to a file, the scan won't see it.
The registry can name the relays that public inventories have already documented. It can't tell you who runs an endpoint that nobody has cataloged yet — those show up as unknown, for your own team to chase down.
And a finding is not proof of wrongdoing. Plenty of teams route through a commercial aggregator or a self-hosted setup on purpose, as an architectural decision rather than an accident. The scan tells you where traffic is pointed. It doesn't tell you why someone pointed it there, and it doesn't make that judgment for you.
What to do with the answer
The scan's output is a list: file, line, endpoint, severity, and attribution where it exists. Turning that into a decision is still a human job. A critical-severity finding pointing at a reverse-engineered access channel and a medium-severity finding pointing at a named commercial aggregator are rated differently for a reason — but the scan itself does not tell you which one, if either, needs action. A medium-severity finding might be exactly what the team intended, in which case the finding is just documentation of an existing decision.
Either way, the report gives you something to start a conversation with: a specific file, a specific line, and a specific endpoint, rather than a vague sense that something might be off. What you do next — ask the engineer who wrote that line, change the endpoint, or leave it alone because it was chosen deliberately — depends on context the scan doesn't have and isn't built to have. It's a detector, not a verdict.