Working in security taught me to ask one question about everything: what can go wrong? Here's what's going wrong with AI infrastructure, and why almost none of it is about the model.

When ChatGPT went mainstream, everyone's threat model was the model. Jailbreaks. Prompt injection. Hallucinations. Coax the thing into saying something it shouldn't and call it a day.

That's not what keeps me up at night anymore.

I've spent the last decade in this work: building AI products and endpoint security at Microsoft, securing cloud infrastructure at Atlassian, and now running Offgrid Security, where my team breaks AI systems for a living with our platform, Kira. From where I sit, the most consequential attacks of the past year didn't touch the model at all. They went after the machinery around it: the gateways, the routing layers, the tool protocols, the credential stores. A whole new tier of the stack assembled itself while nobody was writing a threat model for it.

Consider what shipped in just the last few months. A pre-auth SQL injection in the most popular open-source LLM gateway, exploited in the wild within 36 hours. A supply-chain compromise of that same gateway pushing credential-stealing malware to millions of downloads a day. A "by design" remote code execution flaw baked into an AI protocol's official SDK across four languages. A low-privilege user chaining three bugs into full server takeover, then using it to open a reverse shell on a developer's laptop the moment they typed the word "hello."

None of these were about AI models.

They were about architecture, which is the harder problem, because you can't fine-tune your way out of it.

We rebuilt the whole application stack and forgot to threat-model it

A classic SaaS app was simple, trust-wise. User authenticates. App checks authorization. Business logic runs. Database stores state. You could count the trust boundaries on one hand.

A modern AI app? A single request might pass through an API gateway, an LLM gateway like LiteLLM, a prompt orchestrator, a routing engine picking between models, a policy engine, a retrieval layer, a couple of vector databases, a memory service, a fleet of MCP servers, and then out into GitHub, Slack, Jira, Salesforce, Gmail, AWS.

Every one of those layers is doing something sensitive: identity translation, authorization, secret handling, policy enforcement, action execution.

Your application stopped returning data. It now orchestrates decisions across dozens of systems on your behalf, and from the outside it still looks like a chat box, which is exactly why the shift is so easy to underestimate.

Complexity doesn't just create bugs. It creates whole new kinds of bugs.

Here's the pattern worth internalizing: the failures are moving to the seams. Not inside any one component, but into the space between them.

Let me walk through one my team found, because it's almost too clean an example.

We were analyzing LiteLLM, the open-source gateway that brokers calls to 100-plus model providers behind a single OpenAI-compatible API, sitting at a genuine chokepoint in thousands of production stacks. We found a flaw (CWE-862/269, CVSS 9.0) that let an org_admin, a low-privilege, tenant-scoped role, promote any user on the entire platform to proxy_admin. Not just users in their own organization. Any user, in any tenant.

The instructive part is why it worked:

• The middleware read organization_id from the raw JSON body, confirmed the caller administered that org, and granted access. Correct so far.
• But organization_id wasn't a declared field on the request model. The parsing layer silently dropped it before the handler ever ran, so the handler never received the value it needed to scope which users could be modified.

The field that authorized the request vanished before it could constrain the request. One layer treated it as a permission check; the next layer never saw it at all. A second gap let user_role flow straight to the database with no elevation guard. The result was cross-tenant privilege escalation.

Each layer behaved correctly in isolation. The system became insecure the moment they were composed.

We disclosed it with a full root-cause writeup and a two-part fix: declare the field so it survives parsing and actually filters the target list, plus a role-elevation guard so no caller can write proxy_admin without already being one. Both landed upstream.

This is what I mean by composition failures. They aren't classic application-security bugs. They emerge because two systems each make a reasonable assumption that stops holding the moment they're wired together, and you can't find them by scanning one file at a time. That's precisely why we built Kira: to trace data flow across an entire codebase and prove which findings are actually exploitable, for teams shipping AI-generated code faster than any review queue can keep up.

Your "AI tooling" is actually privileged infrastructure. Treat it that way.

The industry still files LiteLLM, LangGraph, MCP servers, and memory systems under "AI tooling," as if they were a dev convenience. That framing badly undersells the risk.

These are control planes. A production AI gateway typically holds every model-provider API key, your cloud credentials, your routing policies, user identities, organizational boundaries, tool permissions, conversation history, agent memory, cost controls, and audit logs. In many organizations, the AI gateway has broader visibility than the application it serves.

The historical hierarchy of high-value targets ran databases, then cloud IAM, then CI/CD. AI orchestration layers belong on that list now, because compromising one component hands an attacker the entire execution environment.

A publicly disclosed three-CVE chain in LiteLLM (combining to CVSS 9.9) made the point concrete. The blast radius of a full takeover: the master key, the salt key that decrypts stored credentials, the database URL, and every configured provider key, including OpenAI, Anthropic, Gemini, Bedrock, and Azure. Every prompt and response passing through the gateway becomes readable, and in real deployments that's exactly where PII, source code, internal tickets, and pasted secrets live.

The sharper concern isn't what an attacker can read. It's what they can rewrite. The gateway sits on the wire between the agent and the model, so a compromise lets it tamper with responses in transit. Researchers demonstrated this against an AI coding agent routed through a poisoned proxy: not prompt injection, but a malicious callback that swaps the model's response for a forged tool call and rewrites the safety-check context so the action reads as pre-approved. The developer typed a single word, "hello," and received a reverse shell on their own machine.

The supply-chain hit was the warning shot

If the authorization bugs show how fragile this tier is, the March 2026 LiteLLM supply-chain compromise showed how concentrated the risk has become.

There was no exotic ML exploit. Attackers hijacked maintainer accounts, bypassed the normal release process, and pushed trojanized versions straight to PyPI, a package pulled millions of times a day. Downstream, production systems began failing: runaway processes, pegged CPU, OOM-killed containers. The malicious build harvested credentials from a wide range of sources (Git, Docker, npm, Vault, cloud configs) and, in Kubernetes environments, attempted cluster-wide lateral movement by spawning privileged pods. The community pulled the bad versions within hours and the maintainers brought in professional incident response, which likely limited the damage.

The organizations hit weren't running insecure AI. They trusted a foundational dependency. The blast radius was so large because one component sat at the center of dozens of trust relationships at once. One package, all the keys.

A month later, the disclosed pre-auth SQL injection (CVE-2026-42208, CVSS 9.3) proved the point again: injection in the API-key verification path, so any client that could reach the proxy could read the credential store. Exploitation in the wild began roughly 36 hours after disclosure, and CISA moved LiteLLM onto its Known Exploited Vulnerabilities catalog. Attackers no longer wait for a proof of concept; an advisory plus an open-source schema is enough.

MCP bolted on a brand-new trust layer, and the security model is playing catch-up

The Model Context Protocol gives models a standard way to reach tools, files, databases, repositories, and services. It's a powerful abstraction, and I use it, so I won't pretend otherwise. It also introduces a set of new trust relationships that didn't exist eighteen months ago.

In April 2026, researchers disclosed a systemic RCE that stemmed not from a coding mistake but from a deliberate design choice in the MCP STDIO interface, present across the official Python, TypeScript, Java, and Rust SDKs. Any command passed to that interface executes on the host, valid server or not. The reported footprint: an estimated 150 million downloads, 7,000-plus publicly reachable servers, and up to 200,000 vulnerable instances. It chained into unauthenticated takeover on platforms such as LangFlow and filter-bypass on Flowise, where MCP configuration endpoints were reachable with no authentication at all.

It isn't an isolated case. There's a running tally of MCP CVEs now: a chained RCE in Anthropic's own mcp-server-git, command injection across community servers, cross-client data leaks in the TypeScript SDK. The NSA published a cybersecurity information sheet noting that MCP shipped "flexible and underspecified," and that its adoption has "outpaced the development of its security model." It's the same story as the early web, replaying at AI speed.

The deeper issue: protocols built for autonomous systems require much stronger assumptions about identity, capability, and delegation than a conventional API. Leave those unstated and the boundaries turn out to be far more fragile than they look.

The real shift: we're protecting execution now, not just data

Old apps mostly answered questions. AI systems do work. They merge PRs. Deploy infra. Send email. Approve workflows. Modify production.

So the question I keep coming back to has changed. It used to be "can an attacker read this data?" Now it's "can an attacker influence what the system decides to do?"

That's a much harder problem, and the blast radius is much bigger. An attacker who can forge a tool call, reroute a request, or quietly promote themselves to admin can reach out and touch the systems that actually matter.

This isn't just LiteLLM. It's the whole ecosystem making the same mistake.

The LiteLLM finding wasn't a one-off. Kira has been surfacing this same class of failure across AI and developer tooling, and the through-line rarely changes:

• Cognithor, an AI agent platform whose bootstrap endpoint returned the master bearer token to any caller, no authentication required. A single request let an attacker exfiltrate every stored credential and trigger destructive operations like a factory reset; the server bound to 0.0.0.0 by default. CVSS 9.8.
• Hoppscotch, where unauthenticated mass assignment on the onboarding endpoint let an attacker inject JWT_SECRETand SESSION_SECRET into a fresh install, enabling complete token forgery. CVSS 10.0.
• Microsoft VibeVoice, a conversion script calling torch.load() on attacker-supplied files with no weights_only=True guard, so a crafted checkpoint ran arbitrary code the moment CI touched it. What flagged it was an inconsistency: some files already used the safe pattern; this one didn't. The layers disagreed.
• Redash, where three query runners passed user-supplied URLs straight to requests.get() with no private-range blocklist, turning a compromised BI admin into SSRF that reached internal services and cloud-metadata credentials, because a hardened HTTP client existed elsewhere in the codebase and these paths simply never called it.

This is precisely why traditional scanners miss it. A file-at-a-time linter can't see that two layers disagree about the same request. The vulnerability isn't in a line, it's in the relationship between them. That gap is the reason I built Kira to prove exploitability across the whole flow rather than adding to the pile of scanner noise. If it can't be exploited, it isn't a finding. If it can, we show you the path.

We're just repeating an old lesson at a new speed

Every platform shift opens a window where complexity sprints ahead of security. Cloud gave us IAM. Containers gave us Kubernetes security. Microservices gave us service identity. AI is giving us orchestration security, and we're in the messy early part where the systems are in production but the mature models for how they interact aren't written yet.

The problem was never that models are inherently insecure. It's that we stitched together distributed execution systems (gateways, policy engines, tool protocols, memory layers, autonomous agents) far faster than we built the discipline to reason about the boundaries between them.

If you're a founder building on this stack, here's the work

Your model probably isn't your most valuable asset. Your orchestration layer is. In practice, that means:

1. Treat AI gateways, agent runtimes, MCP servers, and routing infrastructure like identity providers or cloud IAM. That's the privilege tier they actually operate at. Get them out from behind the "it's just AI tooling" mental category.
2. Review authorization boundaries between components, not just within them. Nearly every critical bug this year lived in the disagreement between two layers.
3. Map how identities, permissions, and secrets move across your stack. If one credential store sits at the center of a dozen trust relationships, that concentration is the risk.
4. Find the AI proxies your teams stood up without telling security. They exist, they hold production-tier provider keys, and often no one is monitoring them.
5. Patch this tier on your internet-facing timeline, not your someday backlog. Exploitation windows are collapsing toward hours.

That's the real story. Not that AI introduced new attacks. It introduced an entirely new layer of software, sitting between your users and the systems that matter most, and attackers have already worked out that it's the most valuable thing in the building.

Ask the question before they do: what can go wrong?

If you want to know whether this class of bug is already sitting in your codebase, that's exactly what Kira does. Connect your repo and it traces data flow across your entire stack to surface verified, exploitable findings, with reproduction steps. Start at offgridsec.com, or find me on LinkedIn if you want to compare notes on AI-native attack surface.

- Aditi