APIs Are the Attack Surface That Matters in AI-Powered Apps

Recently, I had the opportunity to speak on the main stage at the combined API:World, AI TechWorld and CloudX event in Santa Clara. I wanted to share my thoughts on what I presented, as well as the slides

APIs Are the Attack Surface That Matters in AI-Powered Apps

Recently, I had the opportunity to speak on the main stage at the combined API:World, AI TechWorld and CloudX event in Santa Clara. I wanted to share my thoughts on what I presented, as well as the slides (linked below). As always, if you have any questions for me or the FireTail team, just reach out!

APIs Are the Attack Surface That Matters in AI-Powered Apps

Five breaches. Five different vendors, most of them with security teams bigger than my entire company. Zero of them involved a jailbroken model, a bad prompt, or some exotic new AI vulnerability class. Every single one came down to an API that wasn't secured properly.

That's not a coincidence. That's the pattern.

We keep doing this to ourselves

Every wave of new technology looks the same from a security standpoint. On-prem, then cloud, then APIs, then AI. Each one unlocks something genuinely new, and each one quietly reintroduces the same four problems:

1. The tools built for the last wave don't cover the new attack surface.

2. Budget and procurement move slower than adoption.

3. The previous wave never got fully secured in the first place.

4. The list of people who need to be involved keeps growing, until eventually it's everyone, everywhere, all at once.

AI is not an exception to this pattern. It is the pattern, running one more time, faster.

The models were never the problem

Walk through the actual incidents from the last year and a theme jumps out immediately: not one of them was a story about the model doing something clever or malicious on its own. Every one was a story about an API that had no authentication, too much authentication scope, or too little inspection of what was flowing through it.

OpenClaw. Over 1,000 local developer machines, exposed to the public internet with root shell access, because of a default "localhost" misconfiguration. The result: 1.5 million leaked API keys across OpenAI, AWS, and Anthropic, plus sensitive user records spilled via a connected AI social app called MoltBook. Not a model failure. A misconfiguration, at scale.

EchoLeak.Copilot calls the Microsoft Graph API to fetch email. The auth check passes, but nothing inspects the content layer. The email itself contains the injection. Copilot's own markdown-rendering pipeline turns that injection into an image tag pointing at an attacker-controlled URL, with stolen data appended as a parameter. The theft happens through Copilot's normal, authorized behavior.

Lilli. Public API docs, 200+ endpoints documented, 22 of them with no auth control at all. One of those took unauthenticated writes. From there: SQL injection chained with IDOR, full read/write database access, and 46.5 million messages exposed. Total time: about two hours, fully autonomous, twenty dollars of compute. An LLM is exhaustive, and chaining vulnerabilities happens to be a particular skill of theirs.

Vercel. An employee connects an AI tool with a corporate account, gets an allow-all OAuth grant instead of a scoped one, and the AI vendor gets compromised. The stolen token wasn't locked to anything narrow, so it walked straight into Vercel's internals and out the other side into customer environments. One OAuth scope. Not a hijacked package, not a code exploit.

LiteLLM. A compromised release of a gateway that runs in roughly a third of cloud environments. Malicious code ships, a company installs the update, credentials get harvested silently, and source code and contractor records walk out the door. Every AI app needs an API. Every API needs a gateway. Speed beat security. Ouch.

The real lesson

In every one of these, the attacker never had to be clever about the model. They only had to be thorough about the API. And here's the uncomfortable part: any attacker can afford to be thorough now. Any missing auth check that shows up in code, in documentation, or in the API spec itself will be found, because an LLM will happily read all 200 pages of your docs and try every endpoint without getting bored.

There's no excuse left for skipping basic SCA and SAST on your API code. There's no excuse for not running a real API gateway or WAF in front of it. In every one of these cases, secure configuration would have beaten buying a new tool. Don't sacrifice security for speed if you can help it. FOMO is real, and organizational inertia is real, but the breach math doesn't care about either one.

The numbers make the case

FireTail's State of AI Security 2026 dataset (302 incidents) breaks down almost exactly the way you'd expect if APIs are the real surface: data exfiltration accounts for 35%, API and endpoint exposure another 11%, OAuth and access abuse 8%. Prompt injection is real at 16%, but it's consistently the delivery mechanism, not the destination. The destination is always an API call that shouldn't have gone through.

The average breach still runs an estimated $4.37 million. Putting a real API gateway in front of your AI stack (auth, rate limits, anomaly detection) cuts that risk by an estimated 91%, and it's usually a one-to-three-week project, not a quarter-long initiative. Securing your APIs is, right now, one of the single cheapest and most effective things you can do to secure your AI.

The takeaways

- The models were never compromised. Every incident above started and ended at the API layer.

- Thoroughness is now free for attackers. Any auth gap visible in your code, docs, or API spec will get found. An LLM won't get bored checking 200 endpoints.

- Secure configuration beats new tooling. None of these five breaches needed a novel defense; they needed the basics done.

- Don't trade security for speed if you can avoid it.FOMO and org inertia are real, but they're not a security strategy.

This is the same argument I made on stage at AI TechWorld 2026, and it's the same reason FireTail exists: you can't secure what you can't see. Every one of these incidents was findable, and stoppable, if someone had real visibility and observability into what their AI systems were actually doing, backed by policy that could act on it in the moment. That has to happen at the level of the AI itself, not just the APIs sitting underneath it. Click here to get the full slides from the talk.

Discover your AI exposure now

See how FireTail provides a single platfrom to discover, assess, and protect all AI usage across your organization.