Long before anyone connected an LLM to their CRM, companies were leaking data through a much simpler mistake: an API endpoint that hands back more than the caller is entitled to. That mistake never went away — and AI just gave it a bigger audience.
Two familiar failures
Optus, 2022. In what became one of Australia’s largest breaches, an API endpoint that should have required authentication was reachable without it — and it happily returned customer records, reportedly on the order of ten million people. No sophisticated exploit; a door that was supposed to be locked simply wasn’t.
Trello, 2024. A public API let a caller look up whether an email address was tied to an account — and map it to profile information. Fed a large list of addresses, that endpoint let an attacker assemble a dataset of around 15 million records. Every individual lookup was “working as intended.” The aggregate was a breach.
The pattern underneath
OWASP has ranked Broken Object-Level Authorization (BOLA) as the #1 API security risk for years. The essence: the endpoint checks that you’re a valid caller, but not whether you’re allowed to see this particular record. Change an ID in the URL, or replay the call across a list, and the data flows. The API was built to serve one honest client and then exposed to a world that doesn’t play along.
Authentication asks “who are you?” Authorization asks “are you allowed to see this?” Most leaks are a missing answer to the second question.
Why AI raises the stakes
Point an AI assistant — or an MCP connector — at a raw internal API and you hand automated, tireless enumeration to something that will follow instructions from untrusted text. If the endpoint over-returns, the assistant will over-return at machine speed. The old advice — “never expose the raw endpoint” — matters more now, not less.
The lesson
Don’t let anything — human, script or AI — talk to a raw endpoint that trusts the caller to behave. Put authorization and filtering in front of it, and enforce it per record, per caller.
How Sallyport approaches it
Sallyport’s governed gate is designed so callers never touch the raw vendor API. They hit one clean Sallyport endpoint, authenticated with a scoped token, and every response is filtered to that caller’s rights before it leaves — rows they may not see are withheld, sensitive fields are masked, and the whole call is written to an audit log. It’s a drop-in swap: point your integration at Sallyport instead of the vendor, keep the same request and response shape, and the over-returning endpoint stops being reachable at all.