$cat llm-security-infrastructure-problem.md

LLM Security Is an Infrastructure Problem, Not a Model One

July 25, 202614 min readby MDflowview as .md

An emerald wireframe cage around a server rack and glowing database cylinders on a dark terminal grid, with one hinged panel swung wide open

Most of the money and attention in AI security goes to the exotic end of the problem: adversarial inputs, model extraction, jailbreaks, alignment failures. Most of the actual incidents go somewhere far more boring.

That gap is the argument Lovina Dmello, a senior software developer on NVIDIA's deep learning infrastructure team, made in a talk at AI Engineer with a deliberately provocative title: your LLM stack is a 2008 database with better marketing. The point is not that nothing has changed. It is that almost everything breaking in production ML today is an infrastructure mistake the industry supposedly solved years ago — and that the fixes are equally well known.

TL;DR — LLM security is mostly an infrastructure problem wearing new vocabulary. The stack changed — probabilistic behaviour, prompts as control flow, shared GPUs, agents taking actions — but the security assumptions did not, and the breaches keep landing on missing authentication, over-privileged accounts, flat networks and exposed secrets. The fastest-growing example is the agent tool surface itself: a 2026 study of 7,973 remote MCP servers found 40.55% expose their tools with no authentication at all. Secure the AI stack like infrastructure — lock down access, segment, protect data at rest — and keep the knowledge layer somewhere with those defaults on. That is how MDflow is built. Start free.

What "LLM security is an infrastructure problem" means

It means the layer where AI systems actually get compromised is the same layer that compromises ordinary software: identity, network reachability, and storage. A classic 2008 application was deterministic, had fixed parameters and served one tenant, and the security tooling built around it assumed all three. Put a model in production and all three quietly break:

Behaviour becomes probabilistic. "Correct" is a distribution, not a branch, so the test that proves a system safe no longer exists in the form security teams are used to.
The asset becomes copyable. You are protecting weights and data that leak straight through the API you are deliberately serving.
Tenancy becomes shared. To make GPU economics work, workloads from different customers get packed onto the same hardware.

Then the LLM stack widens it further: prompts become control flow, answers come from a retrieval corpus somebody can write to, and agents take actions with credentials attached. Every one of those is a change to the system. Almost none of them were accompanied by a change to the assumptions.

The result is a mismatch that Dmello framed as running an old playbook on a new system — and, read the other way round, as the reason the old playbook still works. If the stack fails like a badly deployed database, secure it like one.

The evidence: misconfiguration, not missing features

The number one failure mode is a control that existed and was switched off, not a control nobody had invented. The canonical case is Ray, one of the most widely used frameworks for distributed ML. In its default configuration, Ray did not enforce authentication on its dashboard and job-submission API — tracked as CVE-2023-48022 and disputed by Anyscale, whose documentation says clusters should only run inside controlled network environments. Thousands of clusters ran outside them anyway.

Oligo Security named the resulting campaign ShadowRay: hundreds of compromised clusters, cryptominers and reverse shells, many running with root privileges and reachable credentials for the cloud accounts behind them. It did not need a zero-day. It needed a default nobody turned off. And it did not stay historical — ShadowRay 2.0, disclosed in late 2025, turned the same unpatched flaw into a self-propagating GPU-mining botnet.

The same pattern is now reproducing, faster, one layer up — on the tool surface agents use. A May 2026 measurement study discovered 7,973 live remote MCP servers and found that 40.55% expose their tools with no authentication whatsoever. Of the 119 OAuth-enabled servers the authors could test properly, every one had at least one authentication flaw, 325 in total. Trend Micro's internet scans tell the same story from the other direction: hundreds of network-exposed MCP servers with no client authentication and no transport encryption, most of them offering direct read access to whatever data source sat behind them — queryable by anyone who connects, in natural language.

That is worth sitting with. An MCP server is, in security terms, an API in front of your data with a friendly description of exactly what it can do attached. Ship it without auth and you have not built an AI feature; you have published a database.

Map this against the OWASP Top 10 for LLM Applications 2025 and the split becomes obvious. LLM01 Prompt Injection gets the conference talks and the research budget. But LLM02 Sensitive Information Disclosure, LLM03 Supply Chain, LLM06 Excessive Agency and LLM10 Unbounded Consumption are all, in practice, configuration and access-control problems — and they are where the cheap, accidental, headline-producing failures cluster.

Why the defenses you read about don't survive production

Because every control costs latency and throughput, and those two things are what an SLA is made of. This is the part most security writing skips: the reason a well-known defense is absent from a production system is usually not ignorance, it is that someone measured it.

The rough tiers Dmello put on screen are a useful budget model:

Tier	Examples	Overhead	Guidance
Basics	authentication, input validation, logging	under ~8%	Always on. No debate.
Isolation	walling workloads off from each other	~10–20%	Apply selectively — sensitive or untrusted workloads
Real-time detection	catching malicious input inline	~15–30%	Rarely viable on every request

Two conclusions follow. First, run the cheap controls everywhere — they are the ones that would have prevented the incidents above, and they are affordable by a wide margin. Second, the question a team actually needs answered is not "should I do this?" but "how do I do this without slowing everything down?" The same check, implemented badly, can double a response time; implemented well, it is a rounding error. That is an engineering problem, which is good news, because engineering problems get solved.

It is worth being honest about the ecosystem too. Security tooling for ML lags ordinary software by years, and expertise sits in silos — security teams do not speak ML, ML teams do not speak security, and operations teams do not know how the model behaves. The failures live in the gaps between them, where nobody has the whole picture. If you want a structure to close those gaps against, the NIST AI Risk Management Framework (GOVERN, MAP, MEASURE, MANAGE) and its Generative AI Profile are the obvious references.

Which parts of an AI stack are most exposed

In rough order of how often they turn into an incident:

The tool and API surface. MCP servers, internal agent endpoints, model gateways. Missing authentication, static keys that never expire, no rate limits, no per-user scoping. Cheapest to get wrong, cheapest to fix.
The knowledge layer. RAG corpora, note stores, wikis, document indexes. Whoever can write here can steer every answer downstream — and whoever can read here has your business context, not just your files. This is also where secrets accidentally live.
Credentials and secrets. Hardcoded keys, tokens with no expiry, service accounts with full admin rights by default. The mundane classic, unchanged since 2008.
Shared compute. Multi-tenant GPUs, shared clusters, sandbox escapes, side channels. Real, harder, and much rarer as a root cause than the three above.
The supply chain. Models, adapters and MCP servers pulled from public sources without provenance checks or signing. Fast-growing, and structurally identical to the npm and PyPI problems the industry already knows.

Notice that the first two are where an AI-specific product decision actually helps — not by inventing a new defense, but by choosing storage whose defaults are already right.

How MDflow fits

MDflow is a markdown workspace that AI agents can read and write, which puts it squarely in category 2 above — the knowledge layer. The relevant question is not whether it has an AI security story. It is whether it is configured the way you would want an ordinary API in front of your documents to be configured.

What already lines up today

You do not operate an exposed MCP server. MDflow's remote MCP server is hosted at https://mdflow.cz/api/mcp behind the same authentication as the rest of the app. There is no cluster of yours on a public IP inheriting a framework's default. That removes, by construction, the single failure mode that the 40.55% figure above measures.

Unauthenticated calls get a challenge, not data. Both the MCP endpoint and the HTTP API answer a credential-less request with 401 and a WWW-Authenticate: Bearer header carrying an RFC 9728 resource_metadata pointer, plus a JSON body pointing at the docs — a machine-readable "authenticate here", never a partial read.

Two credentials, both revocable, neither a shared secret. A named Personal Access Token (mdf_…, created in settings, stored only as a hash, individually revocable, with a last-used timestamp) or an OAuth 2.1 access token issued after a browser sign-in and an explicit consent screen, with PKCE and refresh tokens. Claude and ChatGPT connect by signing in rather than by pasting a long-lived string into a config file — which matters, because that study found static keys are the dominant credential in the wild. The deeper argument for scoped agent credentials is its own post.

Tenant scoping is server-side, not client-shaped. Every API and MCP call is bound to the token owner on the server. There is no query shape a caller can construct that reaches another account's documents.

Blast radius is bounded in blunt, cheap ways. Requests are rate-limited to 60 per minute per token and per authenticated user. A write cannot silently empty a document — clearing a body requires an explicit confirmation flag, so a truncated generation fails loudly instead of wiping a note. Version history captures the previous version on every write path with a line-by-line diff and a non-destructive restore, and the Document Log names the actor on every row: you for browser actions, automated · <token name> for anything arriving over the API or MCP. A bad agent write becomes a recoverable, attributable event.

Some things should never reach a model at all. Any individual document can be encrypted in the browser with AES-256-GCM under a PBKDF2-HMAC-SHA-256 key; the server stores only opaque mdflow-enc:v1 ciphertext. Encrypted documents are excluded from search and returned as ciphertext over the API and MCP, so a compromised token cannot read them, while the rest of the workspace stays fully agent-readable. The open-source mdflow-crypt CLI runs the identical scheme locally, so the format is not a lock-in. Per-document encryption is the practical version of "keep secrets out of the corpus" — you get to draw the line yourself instead of encrypting everything and locking your agents out.

What MDflow does not do yet, stated plainly: a token is account-scoped. There are no read-only, workspace-scoped or folder-scoped credentials today, and no expiry — which is precisely the "static key with no scope" pattern the research criticises, and why one named token per integration is the right habit. Encryption covers document bodies; titles and folder names stay readable. And browser-side crypto defends against breach-at-rest, not against a fully malicious provider.

Where we are headed

Direction, not a dated commitment: scoped and expiring tokens are the obvious next step — read-only credentials, and tokens bound to a single workspace or folder, so a clipper, a CI job and a coding agent each hold exactly the reach their job needs. Alongside that, richer per-connector attribution in the log, and treating MDflow's role as a well-behaved OAuth resource server as something to keep current with the MCP authorization spec rather than a box ticked once.

The bottom line

The uncomfortable version of the argument is that AI security is, today, mostly a hygiene discipline wearing a lab coat. Over-privileged accounts, flat networks, exposed secrets and endpoints with authentication off by default are what breaches are made of — in 2008, and in the MCP scans of 2026. The field does not need a new attack-defense pair nearly as badly as it needs the controls it already has, deployed at production overhead, with the defaults set correctly.

For the knowledge layer specifically, that means picking storage that authenticates by default, scopes by owner, names its actors, keeps history, and lets you encrypt the parts no model should see. Start free, connect an AI agent, or read the API docs.

Frequently asked questions

Why is LLM security an infrastructure problem rather than a model problem?

Because that is where the incidents land. The breaches that make the news are almost never novel attacks on a neural network — they are missing authentication, over-privileged accounts, flat networks and secrets left in reachable storage. The ShadowRay campaign compromised Ray clusters through CVE-2023-48022, a framework that simply shipped without authentication enforced by default. Nothing about that failure is specific to machine learning, which is exactly the point: the stack is new, the failure modes are old, and so are the fixes.

Are MCP servers a real security risk?

The protocol is not the risk; how servers are deployed is. A May 2026 measurement study of 7,973 live remote MCP servers found that 40.55% expose their tools with no authentication at all, and of 119 OAuth-enabled servers tested, every single one had at least one authentication flaw. Trend Micro's internet scans found hundreds of exposed servers whose tools offered direct read access to the underlying data source. An MCP tool surface is an API — treat it like one, with authentication, rate limits and per-user scoping.

Is prompt injection overrated as a threat?

No, but it is over-prioritised relative to how teams actually get breached. Prompt injection is LLM01 in the OWASP Top 10 for LLM Applications 2025 and remains genuinely unsolved. The point is one of sequencing: an agent that can be talked into misusing its permissions is a serious problem, and an agent whose endpoint accepts unauthenticated requests from anyone on the internet is a bigger and much cheaper one to fix. Do the boring controls first, then spend on the hard ones.

What security controls actually survive contact with production?

The cheap ones. Every control costs latency and throughput, which is the budget an SLA is made of. In the AI Engineer talk this post draws on, basic controls — authentication, input validation, logging — cost under roughly 8% and should run everywhere with no debate; heavier workload isolation runs 10–20% and is worth applying selectively; real-time malicious-input detection can cost 15–30%, which is why it rarely ships on every request. The useful question is not whether to deploy a control but how to deploy it without breaking the latency budget.

How does MDflow secure the knowledge that AI agents read?

By behaving like a normal, boring, well-configured API. The MCP server is hosted rather than something you expose yourself, unauthenticated calls get a 401 challenge rather than data, every API and MCP call is scoped to the token owner server-side, and requests are rate-limited per token and per user. Credentials are named Personal Access Tokens stored only as hashes, or OAuth 2.1 access tokens issued after a browser sign-in and consent screen. For material that should never reach a model at all, individual documents can be encrypted in the browser with AES-256-GCM, and the server only ever stores ciphertext.