on this page
There is a version of “AI security” that lives entirely inside the model: jailbreaks, prompt injection, the model saying something it should not. Interesting problems, all of them. But if you have ever stood up an ML system for real, you know the model is the small part.
The model is one process. Around it sits a sprawl of infrastructure that trains it, serves it, tracks it, stores its data, and wires it into everything else. Much of that infrastructure was assembled quickly, by people whose job was to ship a feature rather than run a hardened service.
That sprawl is the subject of this series. Before we break anything, it is worth walking the estate and naming what actually runs there, because the interesting attacks are rarely against one box. They are against the seams between boxes, and you cannot see a seam you cannot name.
Everything below maps to a service in the aipostex lab, a small ML shop we built specifically so these seams are real rather than hypothetical. Ports and hostnames are the lab’s; the shapes are the ones you meet in the wild.
Read it top to bottom and it is a request flowing down toward a model. Read it bottom to top and it is a credential flowing up toward an attacker. Both directions are true, and the second one is why we are here.
This field guide is about self-hosted and lab-shaped deployments. Managed offerings often add identity, TLS, and control planes by default. Product defaults change, too. The question that matters is what the reachable instance actually enforces.
The model runtimes
At the bottom are the things that actually hold weights and answer prompts.
Ollama is the one you find on developer laptops and, more often than anyone admits, on a workstation someone left running. It serves a catalog of local models and asks nobody for a password. By default it binds to 127.0.0.1, which keeps that trust decision on the machine. The risk begins when someone changes OLLAMA_HOST, publishes the port through a container, or puts a permissive proxy in front of it.
vLLM and other OpenAI-compatible servers are the production-shaped cousins. They speak the same API OpenAI does, which is convenient for developers and equally convenient for anyone probing them: a single client talks to all of them. vLLM can require an API key on its OpenAI-compatible routes, but that key does not protect every server endpoint. What you get is a model behind a familiar door; the question is which doors the deployment actually locked.
The thing to hold onto: a reachable model runtime with no effective authorization is not just an information leak. It is somebody else’s compute, running what you send it, on their bill.
The gateways
Applications rarely stay wired to one raw model endpoint. They put a gateway in front, and the gateway is where the interesting configuration collects.
LiteLLM is a common one. It presents a single OpenAI-shaped endpoint and fans requests out to whatever real providers sit behind it: OpenAI, Anthropic, a self-hosted vLLM, a Bedrock account. To do that, it has to know how to reach those providers. It holds their base URLs and, frequently, the credentials used to call them.
A gateway is a map of the backends and a keyring for them, sitting in one place. That is exactly why it is worth looking at, and exactly why it should not answer strangers.
The serving stack
Trained models get deployed through dedicated serving software, and this is a whole layer most people outside ML have never touched: Triton, TorchServe, TensorFlow Serving, BentoML, Hugging Face TGI, and TEI. Each has its own API, its own idea of what a “model” is, and its own management surface.
The management surface is the part that matters. TorchServe, for instance, splits inference from management. Its management API can register a model, scale workers, or delete a model outright. Current releases bind locally and enforce token authorization by default, but operators can disable token auth, widen the bind address, and allow remote model registration. An inference endpoint lets you ask the model questions. A management endpoint lets you change what the model is. Those are different powers, even when one product happens to serve them with the same security defaults today.
The tracking and orchestration layer
This is where ML stops looking like a web app and starts looking like a data-science department, because it is one.
MLflow tracks experiments: every training run, its parameters, its metrics, and the location of its output artifacts. Historically, many teams ran it as a trusted-network service. Current MLflow defaults to localhost and includes security middleware, with optional authentication for team deployments. The risky condition is a server deliberately rebound for shared access without authentication or an enforcing proxy.
What makes that server valuable is what ends up logged. Run parameters are where people paste a connection string or a token “just to get it working,” fully intending to remove it later. Artifact URIs point at the S3 or GCS bucket where the real models and datasets live. MLflow can become a directory of an organization’s ML supply chain, narrated by the engineers, with the addresses written down.
Weights & Biases plays a similar role with a different flavor, tracking runs and artifacts and, again, whatever sensitive values found their way into a config.
Ray is distributed compute: a dashboard and a control plane that accept job submissions across a cluster. The dashboard binds locally by default, but remote and container deployments often rebind it. Once that control plane is reachable, jobs matter because they can carry a runtime_env: dependencies, working files, and environment variables distributed to workers. Environment variables are where credentials travel. A job’s runtime environment is a small briefcase of secrets the cluster hands around by design.
Kubeflow orchestrates ML pipelines, the codified version of how the organization trains and ships models. Read the pipelines and you read the supply chain: data sources, image registries, storage. Kubeflow Profiles create useful namespace boundaries, but even its multi-user documentation is explicit that not every pipeline artifact and metadata surface receives hard isolation.
Under all of it, frequently, is Kubernetes, and an ML cluster’s Kubernetes is a target in its own right: mis-scoped anonymous permissions, permissive RBAC, service-account tokens mounted in pods, and Secrets that are encoded rather than encrypted by default. The ML custom resources are the prize here because an InferenceService object can name the model, registry, and storage in one place.
The data
A model is only as private as the data behind it, and increasingly that data lives in a vector database: Chroma, Qdrant, Weaviate, pgvector. These hold the embedded documents a retrieval-augmented application answers from, which is to say they hold the private corpus the whole application exists to serve.
Defaults vary. Qdrant’s self-hosted open-source service, for example, accepts connections without authentication or encryption unless the operator enables them. Cloud offerings generally put more controls around the same data. Either way, enumerating a reachable vector store tells you which collection is worth reading. Reading it hands you the documents themselves. The documents are the point. Not metadata about the data. The data.
The agent layer
This is the newest floor of the building and the one changing fastest.
MCP, the Model Context Protocol, is how models are given tools. An MCP server exposes capabilities; a client wires them into a model; now the model can read files, call APIs, or run code. MCP defines OAuth-based authorization for HTTP transports, but authorization is optional and deployments vary. Local stdio servers typically inherit whatever files and credentials their host process can reach.
That surface cuts both ways, which is a subject large enough for its own post later in this series. For now: an MCP server is a set of powers offered to a model, and powers offered casually can become powers offered to whoever reaches the server or steers the model.
A2A, agent-to-agent, is a protocol for agents talking to one another. Its Agent Cards advertise skills and security schemes. That metadata tells a client how an agent says it should be reached; it is not, by itself, proof that the agent is trustworthy. Identity and authorization still have to hold at the request boundary.
RAG applications are the black-box chat apps built on all of the above. From the outside they look like a text box. Inside sit a vector store, a model, and a prompt. The citations they return are a window into the corpus they were told to keep quiet about.
And then there are the bespoke agents: custom /chat endpoints a company writes itself, with no fixed API and no standard anywhere. These are where prompt injection stops being a parlor trick and starts being a way to read the system prompt, extract a CI token, or make the agent fetch a URL it should not.
The through-line
Read that list back and notice what it is not. It is not a list of models. It is a list of services, most of which hold a credential, a location, or a corpus, and many of which were configured for a trusted network that stopped being trusted the moment they became reachable.
That is the shape of the thing. A model estate is a set of services that each know a little too much about the next one. The Ray job knows the MLflow address and a password for it. The MLflow run knows a token for the inference gateway. The gateway knows how to reach the real model. None of these is a dramatic vulnerability on its own. Strung together, they are a path from an open dashboard to somebody’s private model, and the path is the story.
The rest of this series walks that path. Next we look at why these services leak in the first place, which turns out to be the same three reasons over and over. After that, we follow one thread end to end, from an anonymous port to a stolen model. Then we bring in the defender’s side and watch the whole thing light up a SIEM.
For now, it is enough to have the map. You cannot follow a thread you have not seen laid out.
Operator references
- Ollama authentication and network exposure, including the default bind behavior in its FAQ.
- vLLM’s OpenAI-compatible server and its security guidance.
- TorchServe security and token authorization.
- MLflow tracking-server architecture and HTTP authentication.
- Ray dashboard exposure and
runtime_envdependencies. - Kubeflow’s multi-user isolation model and Kubernetes authentication.
- Qdrant security defaults.
- MCP authorization and the A2A protocol specification.