Most AI security conversations this year have been about models. Which one hallucinates less. Which one can be jailbroken. Which one you can trust with customer data. Those are reasonable questions, and they are aimed at the wrong layer.
The component with the largest blast radius in a typical agentic deployment is not the model. It is the proxy sitting in front of it — the LLM gateway, the MCP servers, the orchestration library that every agent call routes through. That layer is uniquely dangerous for one structural reason: it is the only place in your architecture that legitimately holds every credential at once. Model provider keys. Database passwords. SaaS tokens. Cloud roles. All of them, in one process, because that is what a gateway is for.
A compromised model gives an attacker bad output. A compromised gateway gives them your estate.
What happened, and why it matters more than the headline
On 21 October 2026, PointGuard AI's AI Security Incident Tracker logged a poisoned release of LiteLLM — version 1.107.0 — published to both PyPI and Docker using stolen maintainer tokens. According to that report, affected hosts stood to lose provider API keys, database passwords and cloud credentials, and received remote-code-execution tooling in the bargain.
If you run LiteLLM anywhere, stop reading and go check your pinned versions against the project's own GitHub security advisory and the PyPI advisory database. Aggregated trackers are a useful early signal, not a final word, and you should confirm specifics against upstream sources before you act on version numbers.
But the specific package matters less than the pattern. This is the first widely reported case of the AI glue layer itself being weaponised, and the delivery mechanism was the most boring one available: a routine dependency update. No prompt injection. No model exploit. No clever agent manipulation. Just pip install.
Here is the uncomfortable part for most organisations. That library was almost certainly chosen by one engineer in week one of a pilot, pinned to latest because it was moving fast, and never reviewed by anyone in security. It then quietly became production infrastructure when the pilot worked. Ask your team on Monday: what version of our LLM gateway are we running, and who approved it? Most companies cannot answer either half of that question.
The governance gap is measurable, and it is enormous
SailPoint's Horizons of Identity Security 2026–2027 report, published 6 October 2026, puts numbers on how far behind the controls are. Seventy-nine percent of enterprises now run AI agents in production. Only two percent have deployed identity security tooling built specifically to govern them. That is a 40x readiness gap between deployment and control.
The same report finds AI agents now represent 22% of all non-human accounts, and that 85% of organisations rely on legacy general-purpose identity tools or platform-native controls to manage them. Tools designed for service accounts that do one predictable thing, now supervising entities that improvise.
Diginomica reported on 22 October that two-thirds of organisations have agents in production, with trust remaining the principal implementation challenge. The deployment curve is steep and the governance curve is flat. The gap between them is where incidents live.
This is a different problem from over-permissioned agents. It is worth being precise about the distinction. The familiar concern — an agent granted more access than its task requires — is a scoping problem, and it is solvable with better role design. What the gateway represents is structurally worse: the infrastructure the agents run on holds the union of every agent's permissions in a single process. You can scope every individual agent perfectly and still lose everything if the layer underneath them is compromised.
The money angle your CFO will understand
LLMjacking — the theft and resale of LLM API credentials — featured as a headline category in industry security roundups this week. It deserves more attention from finance teams than it gets, because of how the economics work.
Stolen cloud credentials require effort to monetise. An attacker has to find something worth exfiltrating, or stand up infrastructure, or find a buyer. Stolen LLM provider keys skip all of that. They are money, immediately, the moment someone starts burning inference against your account. There is a liquid market for them and no conversion step.
Which gives you a detection signal most organisations are currently routing to the wrong inbox. Unexplained inference spend is a breach indicator, not a FinOps anomaly. If your model provider bill jumps 30% and the first person to notice is in accounts payable three weeks later, you have a monitoring problem dressed up as a budgeting problem. Spend anomalies on AI provider accounts should page security, same as an unusual egress pattern would.
The market has noticed. Opsin raised $21M on 19 October 2026 specifically to govern enterprise AI agents. Investors do not fund a category unless they believe the incidents are coming. OWASP, for its part, now maintains a separate Top 10 for Agentic AI alongside its GenAI LLM Top 10 in the 2026 edition — a tacit acknowledgement that agent infrastructure has its own threat model.
What to actually do about it
This is an engineering problem with engineering answers. None of the following is exotic; all of it is routinely skipped because the AI stack got deployed under pilot rules and nobody went back to apply production rules.
- Pin and hash-verify every AI-layer dependency. No
latesttags in the gateway image. Ever. Reproducible builds with checksum verification turn a poisoned release from a silent compromise into a failed deploy. - Maintain a separate SBOM for the AI stack. Your application SBOM probably does not cover the agent framework, the MCP servers, or the gateway container. Treat the AI layer as its own supply chain, because it updates on a completely different cadence.
- Never put long-lived provider keys in gateway environment variables. Issue short-lived, scoped credentials through a broker. If a gateway is compromised, the attacker should inherit minutes of access, not months.
- One identity per agent. Not one shared service account that every agent borrows. You cannot attribute, revoke, or rate-limit what you cannot distinguish.
- Egress allowlist on the gateway host. The gateway needs to talk to a known set of model endpoints and internal services. Everything else should be blocked by default — and block instance-metadata access from the container while you are there, because that is the standard pivot to cloud role theft.
- Wire spend-anomaly alerting into your security channel. Threshold alerts on inference cost, per key, per agent, routed to the people who respond to incidents.
- Treat the gateway as a governed internal component. Something you own, patch on a schedule, and review on change — not community software someone installed once.
There is a regulatory tailwind here too. The EU published the first harmonised standard supporting the AI Act on 19 October 2026, and while the Digital Omnibus pushed high-risk obligations out to December 2027 and August 2028, the new prohibitions and labeling requirements still land from December 2026. India has signalled a consultation on its own regulatory approach. Documentation of what your AI infrastructure does and who controls it is moving from good practice to evidence you will be asked to produce.
Where this leaves you
If your agents are in production and your gateway came from a pilot, you have a production dependency that nobody signed off on, holding credentials nobody has inventoried. That is not a hypothetical. It is the default state of most agentic deployments in the market right now, and the SailPoint numbers say so plainly.
Trebta builds agentic systems and does the security engineering around them — the combination matters here, because hardening an AI stack requires understanding why it was architected the way it was. Our Agentic AI and AI & Cyber Security practices work the same codebase, not across a handover.
Talk to us
We offer a fixed-scope AI Stack Dependency & Credential Review: we inventory your AI glue layer, map where every provider key actually lives, check your gateway against known supply-chain exposure, and hand back a prioritised hardening plan. Short engagement, concrete output, no obligation beyond it.
If you cannot currently answer what version of your LLM gateway is running in production, that is the review to book. Get in touch with Trebta and we will scope it this week.