The AI Stack Is Software Too
How attackers are skipping the chatbot and going straight for the gateways, frameworks, and plugins that quietly run your AI
Most conversations about AI security start and end with the model. Can someone trick the chatbot? Can a hidden instruction in a web page hijack the agent? Those are real risks, and we have covered them before.
But there is a second AI attack surface that gets almost no attention, and it is the one attackers are actually breaking into right now. It is not the model. It is the plumbing. The API gateways that route your prompts, the frameworks that give agents memory, and the editor plugins developers install to talk to those models are all just ordinary software. They have bugs. They hold secrets. And in mid-2026, a string of disclosures showed that this layer is soft, valuable, and largely unmonitored.
The uncomfortable truth is simple. Your company can do everything right at the model layer and still hand an attacker every API key it owns, because the tool sitting in front of the model was never treated as security-critical software.
Two Different AI Risks
It helps to separate two ideas that often get blurred together.
The first is the model being manipulated. This is prompt injection: feeding an AI hidden instructions through a document, a web page, or an email so it does something it should not. The agent is tricked into misbehaving, but the surrounding software works exactly as designed.
The second is the model's infrastructure being exploited. This is the classic stuff: a SQL injection bug, a privilege-escalation flaw, a malicious package. Here the attacker does not bother arguing with the AI at all. They go after the code running underneath it, the same way they would attack any web app or library.
This article is about the second kind. It matters because the second kind is more familiar to attackers, easier to weaponize, and lands them somewhere far more valuable than a single tricked response. The AI layer concentrates credentials and data in one place, which means one ordinary bug can unlock everything.
Why This Layer Is Such a Good Target
Three properties make AI infrastructure unusually attractive.
It holds the keys. An AI gateway sits between your employees and providers like OpenAI, Anthropic, and Google, which means it stores the API keys for all of them in one spot. Compromise the gateway and you do not steal one credential. You steal the master set.
It sees everything. Every prompt and every response flows through this layer. That includes whatever sensitive data employees paste in, which in practice means source code, customer records, internal documents, and the occasional password.
It is new and trusted. Much of this software is young, moving fast, and adopted enthusiastically by teams who treat it as a productivity tool rather than as critical infrastructure. Security review often has not caught up. The result is high-value software with the security maturity of a six-month-old startup, because that is frequently what it is.
Case 1: The Gateway That Becomes a Master Key
The clearest example is LiteLLM, a widely used open-source proxy that lets a company put one unified gateway in front of many AI providers. Employees and applications talk to LiteLLM, and LiteLLM talks to the model vendors. Convenient, and exactly the kind of chokepoint attackers love.
Researchers disclosed a chain of bugs that let a low-privilege internal user walk all the way to full server takeover. The sequence is worth understanding because it is so ordinary:
- A basic user mints API keys far broader than their permissions should allow.
- Using those keys, they escalate themselves to proxy administrator.
- As admin, they run arbitrary Python through the gateway's "guardrail" code feature, which is meant for custom safety logic but happily executes whatever it is given.
Once that chain completes, the attacker can dump every stored AI provider key, decrypt saved credentials, and read the prompts and responses of everyone in the organization. Worse, callback hooks are functions the gateway runs automatically on each request, and by abusing them attackers can silently rewrite the AI's answers and spawn a reverse shell, turning the gateway into a foothold inside the network.
Notice what is not happening here. Nobody jailbroke a model. This is a textbook privilege-escalation-to-remote-code-execution chain in a web application that happens to sit in front of AI. The fix is equally ordinary: upgrade to the patched release, audit who holds admin and which callbacks are registered, and rotate every secret the gateway ever touched on the assumption it may already be exposed.
Case 2: The Framework Bug Hiding in the Memory
The second example is more technical, so let us take it slowly.
Agentic frameworks like LangGraph let developers build AI agents that remember what they were doing across steps. To do that, they save the agent's state to a database between turns using a feature called a checkpointer. It is the agent's short-term memory written to disk.
Check Point Research disclosed three chained vulnerabilities in that persistence layer, affecting a library pulled tens of millions of times a month. The chain combines two old, well-understood bug classes.
SQL injection. When an application asks the checkpointer for past states using a filter the user controls, and that filter is dropped straight into a database query without being safely separated from the query's structure, an attacker can rewrite the query itself. This is one of the oldest web bugs there is. It showed up here in both the SQLite and Redis storage backends.
Unsafe deserialization. The saved agent state is stored in a packed binary format. When it is read back, a hook in the code can be steered into looking up and running arbitrary Python functions during the unpacking process. "Deserialization" just means turning stored bytes back into live objects, and when that process can be tricked into executing code instead of merely rebuilding data, you get remote code execution.
Stitched together, an attacker submits a crafted database query whose results contain a malicious packed payload. When the framework reads that payload back as the agent's memory, it runs the attacker's code on the server. Memory becomes a weapon.
The same shape appeared elsewhere the same week. A flaw in Google's Vertex AI SDK let attackers slip a malicious model into another project's upload path, where it executed code inside Google's serving containers using the exact same trick: a poisoned object that runs code the moment it is loaded. Different products, identical lesson. The AI ecosystem inherited every deserialization mistake the broader software world has spent twenty years learning to avoid.
The remediation is, once again, classic engineering hygiene: patch to the fixed versions, use parameterized queries so user input can never reshape a database query, and do not expose state-history APIs to untrusted users.
Case 3: The Poisoned Front Door
The third example targets developers directly, and it is the one most likely to hit a student or early-career professional first.
Security researchers found malicious plugins for AI coding assistants advertised on the JetBrains Marketplace, the official add-on store for popular developer tools. The plugins looked legitimate. On first setup, they asked the user to enter their AI provider API key, which is a completely normal-looking request. The key was then immediately shipped to a remote server controlled by the attacker.
Some of these plugins even offered a "paid tier" that handed users what was most likely a stolen API key, quietly making the victim an accomplice in someone else's bill and abuse. JetBrains later pulled more than a dozen malicious plugins from several banned publisher accounts, which tells you this was a campaign, not a one-off.
This is the AI version of a problem we have written about before in the broader supply chain. The marketplace is trusted, the install is one click, and the malicious behavior hides inside an action that feels routine. The only thing new is the prize: not your SSH key this time, but your AI credentials and everything they can buy.
The Bigger Picture
Step back and the pattern is clear. Across gateways, frameworks, and plugins, attackers are not inventing exotic AI-specific exploits. They are applying privilege escalation, SQL injection, unsafe deserialization, and malicious packages to a brand-new layer that happens to be packed with credentials and adopted faster than it is reviewed.
That is what makes this dangerous for the people reading this. You do not need novel skills to find these bugs, and defenders do not get to wait for some future "AI security" discipline to mature. The AI stack is software. It deserves the same threat modeling, dependency tracking, access control, and patch discipline as anything else in production. The fact that it has an AI sticker on it does not exempt it from any of that. If anything, the concentration of secrets raises the stakes.
Defensive Takeaways
Treat the AI gateway like a crown-jewel system
The proxy in front of your models holds every provider key and sees every prompt. Give it the same care you give a domain controller or a secrets vault: tight admin access, mandatory review of any code-execution feature like callbacks or guardrails, and key rotation on a schedule rather than only after an incident.
Patch the AI stack on the same clock as everything else
Gateways, agent frameworks, and their storage backends ship security fixes like any other software. Track them in your dependency inventory, watch for their CVEs, and apply patched versions promptly. An unpatched AI library is not a smaller risk because it is "just an internal tool."
Never let user input shape a database query
The SQL injection in the framework checkpointers exists for the same reason it has existed for decades: user-controlled values were placed directly into queries. Use parameterized queries everywhere, and do not expose state-history or checkpoint APIs to untrusted users at all.
Distrust deserialization by default
If your application reads back stored objects such as packed agent state, uploaded models, or pickled files, assume that data is hostile until proven otherwise. Validate its source, prefer formats that cannot execute code on load, and isolate the process that does the loading so a bad payload cannot reach the rest of the system.
Vet AI plugins before they touch a real key
A plugin asking for your API key on first launch is asking for the keys to your account. Install AI tooling only from publishers you can verify, read what permissions it requests, and use scoped, low-limit, easily revocable keys for anything experimental. If a plugin offers you a free API key, treat it as stolen and walk away.
Map the AI layer in your threat model
Most teams have a clear picture of their web apps and servers but a blank space where their AI tooling sits. Inventory it: which gateways, which frameworks, which plugins, holding which secrets, reachable by whom. You cannot defend a layer you have not drawn on the map.
Final Thoughts
The first wave of AI security attention went to the model, and rightly so. But while everyone watched the chatbot, attackers quietly walked around it and into the software running underneath, where the keys are kept and nobody was looking.
There is something almost reassuring in that, if you are willing to hear it. These are not unsolvable, futuristic problems. They are privilege escalation, injection, deserialization, and supply-chain abuse: the exact threats this field already knows how to handle. The work is not to invent a new playbook. It is to remember that the old one still applies the moment you accept the obvious truth: the AI stack is software too, and software is something we already know how to defend.