AI Infrastructure & MLOps · entry 08/09 · 3 min read

Securing the stack

Weights you downloaded, dependencies you didn't read, secrets in prompts and logs, tenants sharing a cache — the ordinary security problems that AI systems acquire on top of the headline ones.

Everything below the model

Injection gets the attention, and earns it. What a model-centric review misses is everything underneath: a supply chain nobody checked, a secret in a log, a misconfigured bucket. AI systems don't replace those problems, they add surface — more third-party code, more data movement, more machines with credentials.

The model is a dependency you downloaded

Open weights arrive as files from a hub, and files execute things. The classic hazard is serialized-object formats that run code on load — which is precisely why the ecosystem moved to safetensors, and why loading a legacy checkpoint from an untrusted source is running an untrusted program. But the format only covers the weights: repository code loaded with trust_remote_code executes regardless, so "it's safetensors" is not "it's inert." Beyond the format: pin versions and verify hashes, because "latest" from a public repo is a mutable dependency in a sensitive position; watch for typosquatted repository names; and treat a fine-tuned model of unknown provenance as unreviewed code, since training can install behavior that no amount of prompt review would reveal. The same applies to the tool servers you mount: an MCP server is third-party code that also speaks directly into the context window.

Secrets go where the tokens go

Prompts are the new logs, and logs are where credentials leak. An API key pasted by a user, a customer record inside retrieved context, a system prompt containing an internal URL — all of it flows to your provider, into your observability tooling, and often into a trace someone will share in a ticket. Decide deliberately what may enter a prompt, redact before logging rather than after, and keep retention short. The same care applies to what comes back: a model's output that gets rendered as HTML, executed as SQL, or passed to a shell is untrusted input to the next system, no matter how trustworthy the model.

Isolation, when many customers share one brain

Multi-tenant AI adds paths ordinary apps don't have. Retrieval must filter by tenant before the model sees anything, since a model handed the wrong document will faithfully summarize it. Caches fail in two different directions: a semantic cache stores answers, so a key that ignores tenant can hand one customer's response — or a near-match's wrong response — to another, while a prefix cache never returns a stored answer but leaks timing, since a hit is measurably faster and an attacker probing candidate prefixes learns what someone else asked. Both want per-tenant namespaces. And a memory store written by one session and read by another is a cross-tenant channel unless scoped. None of this is exotic; all of it needs to be deliberate.

Failure mode

Security review that stops at the model. The threat model asks whether the model can be tricked into saying something bad, signs off, and never asks who can write to the vector index, what happens when the retrieval filter is empty, which service account the agent runs as, or where traces are stored and for how long. The headline risks are real and deserve the attention; these respond to entirely ordinary controls, and mostly go unexamined — because nobody thought of those parts of the system as security-relevant, on the grounds that they merely contained a model.