You Can't Secure AI Without Securing APIs

Every LLM-powered application your organization builds, buys, or quietly experiments with shares one structural property: it is an API-first system. The model lives behind an API. The retrieval layer queries a vector database through an API. The agent invokes tools through APIs. The application returns results to users (and to the next service in the chain) through an API. Pull on any thread of an AI deployment and you arrive at an API endpoint.
 
That makes the AI attack surface, almost by definition, an API attack surface. The harder you look at the published threat models for LLM applications, the harder this is to unsee.
 
We ran the analysis against the OWASP Top 10 for LLM Applications 2025. Every single item, all ten risks on the list, has an API dimension. Five are directly exploitable through API interactions. The remaining five are delivered, triggered, or amplified through API mechanisms. None of them are abstract model-theory problems that you can solve by tuning a system prompt. They are application-layer problems that show up at the API boundary.
 
If your AI security program isn't sitting on a strong API security foundation, it is not actually a security program. It is a hope.

100% of the OWASP Top 10 for LLM Applications has an API dimension. Half are directly API-exploitable. The other half are delivered, triggered, or amplified through APIs.

The OWASP LLM Top 10 has an API problem

The OWASP Top 10 for LLM Applications 2025 is the closest thing the industry has to a consensus list of LLM-specific risks. The 2025 revision sharpens the focus, adds two new categories, and rearranges the rest based on what defenders are actually seeing in production.
 
Read it as a security architect and a pattern emerges: the model itself is rarely the attack target. The model is the vector. The endpoint is the target. Every risk on the list either reaches the model through an API call or reaches the user through an API response. In both directions, the API is the control point.
 
That has practical implications for how you scope an AI security program. You do not get to treat "API security" and "AI security" as adjacent disciplines that occasionally share findings. They are the same discipline, viewed from two angles.

Five LLM risks that are directly API-exploitable

Of the ten risks in the 2025 list, five are exploited through direct API interactions. There is no model-internals path. The attacker calls an endpoint.

• LLM02: Sensitive Information Disclosure. PII, credentials, and proprietary data leak through API responses. The attacker doesn't need access to the training corpus. They need access to the inference endpoint.
• LLM05: Improper Output Handling. When an API returns LLM-generated code, HTML, or SQL to a downstream system without validation, the API is the unsanitized pipe. This is classic injection through a new generator.
• LLM06: Excessive Agency. Function calling and tool-use give LLMs the ability to make API calls on a user's behalf. When permissions are over-scoped across banking APIs, email APIs, or database APIs, the LLM becomes a confused deputy with production credentials. Every modern agent framework is built on this pattern.
• LLM08: Vector and Embedding Weaknesses. Vector databases such as Pinecone, Weaviate, Milvus, and the embedded stores inside many agent frameworks are accessed through APIs. Embedding poisoning, similarity attacks, and unauthorized retrieval all happen through API operations on those stores.
• LLM10: Unbounded Consumption. The "denial of wallet" risk is a pure API abuse pattern. Rate-limit bypasses, large-prompt floods, and runaway token consumption hit the LLM API the same way a credential-stuffing botnet hits a login endpoint, just with a different objective on the back end.

These five are the cleanest case for treating API security as foundational. Each one is, structurally, an API attack with an AI payload.

Five more that are delivered, triggered, or amplified through APIs

The other five risks aren't only API problems, but they are delivered or amplified through API channels, and that matters for how you defend them.

• LLM01: Prompt Injection. Prompts arrive through API endpoints. A POST /v1/chat/completions with adversarial content is the modern equivalent of a SQL injection payload, and the API gateway is where you have the cleanest shot at inspecting it before it reaches the model.
• LLM03: Supply Chain. AI model weights, fine-tuned variants, and dependency packages reach your environment through APIs: model hubs, package registries, third-party model providers. The supply chain risk is an API risk, just one step removed from runtime.
• LLM04: Data and Model Poisoning. Fine-tuning APIs and training data ingestion APIs are the surfaces attackers target to corrupt model behavior at the source.
• LLM07: System Prompt Leakage. Adversaries extract system prompts through crafted API requests: probing error messages, observing behavioral side channels, fuzzing response patterns. It is reconnaissance, performed entirely through the API.
• LLM09: Misinformation. Hallucinated outputs are not themselves an API vulnerability, but APIs are the distribution mechanism. At scale, an API that confidently returns wrong financial advice to 10,000 users is a different kind of incident than an LLM that does the same thing in a sandbox.

Add the two groups together and the conclusion is unavoidable: 100% of the OWASP Top 10 for LLM Applications has an API dimension.

What this looks like in the wild 

This is not theoretical.

CVE-2026-26030 · CVSS 9.9
Microsoft Semantic Kernel: prompt injection to host RCE
A vulnerability in the InMemoryVectorStore filter let an attacker reach os.system() on the host through a single crafted API request to an AI agent. One prompt, one API call, one shell.

In May 2026, Microsoft disclosed CVE-2026-26030 in the Semantic Kernel Python SDK. The vulnerability, a prompt injection bug in the InMemoryVectorStore filter functionality, allowed an attacker to achieve host-level remote code execution through a single crafted API request to an AI agent. The default filter was built as a Python lambda evaluated with eval(). Inject the right string through the agent's input API, and the payload walked Python's method resolution order to execute arbitrary commands on the host. CVSS 9.9. No browser exploit, no malicious attachment, no memory corruption. One prompt, one API call, one shell. (Source: Microsoft Security Blog)
 
Two days earlier, the AI evaluation startup Braintrust disclosed unauthorized access to an AWS account holding customer API keys for cloud AI models. The vendor-on-vendor breach forced every customer to revoke and replace credentials for the LLM providers they were evaluating. The AI supply chain looked exactly like the API supply chain, because that's what it is. (Source: TechCrunch)
 
The week prior, a published scan of more than one million exposed AI services found AI infrastructure to be "more vulnerable, exposed, and misconfigured than any prior software category studied." (Source: The Hacker News) That is not a model alignment problem. That is an inventory and posture problem at the API layer.
 
Three different incidents. Three different attack patterns. One control point in common.

What an API-first AI security program looks like 

If the OWASP LLM Top 10 is, structurally, an API security problem, then the security program needs to be built on API security primitives, applied to the new shape of the application.
 
Four capabilities matter most.

• Inventory. You cannot protect endpoints you do not know exist. AI-enabled applications create endpoints fast: agent tools, internal RAG APIs, model proxies, fine-tuning endpoints, evaluation harnesses, and the ever-growing population of MCP servers. Shadow APIs are no longer the exception; in AI environments they are arguably the default. Continuous, runtime API discovery is non-negotiable.
• Authentication and authorization at the call. Excessive Agency is, in operational terms, an authorization failure. The LLM should never hold credentials more privileged than the action it has been authorized to take. Per-call, per-tool, per-tenant auth is the only durable defense.
• Input validation and output handling at the boundary. Prompt injection filters and output sanitization belong at the API gateway, not buried inside application code. Treat LLM inputs and outputs the same way you treat user input and database output in a traditional web application: adversarial until proven otherwise.
• Supply chain integrity for AI-adjacent code. AI applications import an unusually large number of third-party packages: agent frameworks, vector store SDKs, evaluation libraries, model client libraries. CVE-2026-26030 lived in a Microsoft-published Python SDK that thousands of teams pulled into production without a second look. SCA and SBOM coverage for the AI dependency surface is now table stakes.

None of those four capabilities are new. They are the disciplines AppSec teams already practice: discovery, authorization, input validation, supply chain integrity. The novelty isn't the defense. It's the surface.

Where to start 

If you are mapping your AI security strategy this quarter, the first move is not to buy a model firewall. It is to take an honest inventory of the API endpoints your AI applications expose and consume.
 
Three questions worth answering this week:

• How many of your production LLM endpoints, agent tool APIs, and RAG retrieval APIs appear in your current API inventory?
• What percentage of your AI-adjacent third-party dependencies (agent frameworks, vector SDKs, model clients) are covered by your existing SCA and SBOM tooling?
• If a prompt injection arrived at one of your agents tomorrow and walked the function-calling chain, what is the blast radius?

The answers are usually uncomfortable. They are also the starting point for an AI security program that is built on something more durable than hope.
 
The OWASP Top 10 for LLM Applications has already told us where the attack surface lives. It lives at the API.
 
See what's actually exposed in your AI stack.
Data Theorem's API Secure continuously discovers and tests every API in your environment, including the ones your AI teams stood up last week.

Request a Demo