The research corpus.

Where MCP standardises one agent calling tools, agent frameworks orchestrate many agents talking to each other. LangGraph (LangChain) models agent flows as state machines on a graph. AutoGen (Microsoft) and its fork AG2 model multi-agent conversations with explicit role assignments. CrewAI is the high-level "Researcher / Planner / Critic / Writer" team abstraction. MetaGPT ships the same idea as a software-team simulation. Together they are how teams ship the kind of system Anthropic's CEO calls "a virtual coworker."

The orchestrator process is a long-running stateful Python service that holds the entire conversation graph between every agent it has ever coordinated. The state typically lives on disk or in a Redis-backed checkpoint store. When the orchestrator's HTTP control plane is exposed without auth, an attacker reads every agent's history (which often contains intermediate tool outputs and customer data) and can frequently inject new messages into a running conversation. The attack surface is every tool every agent has ever been given multiplied by the orchestrator's lifetime.

We probe LangGraph's /threads and /runs endpoints, AutoGen's WebSocket control surface, and CrewAI's REST API for the conversation inventory. Conversation IDs and timestamps tell us how long the orchestrator has been running and how active the operator's deployment is. We do not read message bodies. The agent role catalogue (extractable from configuration without reading conversations) is sufficient operator-attribution evidence.

Browser agents pair an LLM with a headless browser (Chromium, Playwright, Puppeteer) so the model can see a webpage, reason about it, and click. It's the natural answer to a real problem: most of the world's data lives behind JavaScript, and most of the world's tools live behind UIs that have no API. Frameworks like browser-use, Stagehand, and the Anthropic Computer-Use harness all share this shape: a screenshot, a model decision, an action.

The agent process is an entire web browser running with the operator's full session context: cookies, saved logins, residential IP, sometimes payment methods. When the agent's control plane (the API that accepts "go do X") is exposed to the public internet without auth, anyone can drive that browser through the operator's identity. We've also found stale instances where the browser left a session pinned for hours after the agent's last task; an attacker who finds the open port inherits whatever the human last logged into.

We probe for known framework footprints (the WebSocket port browser-use opens, the screenshot endpoint of the Computer-Use sample server, the Stagehand remote-control API) and confirm reachability with a benign read of agent state: current URL, session cookies count, last action history. From there we map the agent's identity by inspecting what site it last interacted with, which is sufficient to identify the operator without ever issuing an action.

The Model Context Protocol is Anthropic's open standard for letting an LLM call tools: read files, query a database, send mail, push to GitHub. An MCP server is a small process that lists "tools" (functions with JSON schemas) over a server-sent-events connection; any compatible client (Claude Desktop, Cursor, Cline) can connect, enumerate the catalogue, and invoke tools on the model's behalf. It's an elegant design: a single protocol for all of agentic tool-calling. And it has spread fast.

The protocol assumes the network boundary handles authentication. A tremendous amount of operator effort goes into the tool definitions and almost none into the transport: most deployments expose /sse directly to the public internet with no auth at all. The first message a client sends is tools/list, and the server answers with the entire tool catalogue in plaintext: names, descriptions, parameter schemas. From there an attacker calls anything they want, with the operator's credentials baked into the server-side handlers.

Our deep MCP enumerator opens an SSE channel, walks the JSON-RPC handshake, captures the tool list, and probes each tool's schema with synthetic arguments to confirm reachability. We classify the catalogue by sensitivity (file-system access, mail/IM connectors, IAM/cluster operations) and follow up with single high-signal invocations to validate exploitability. We then map the tool implementations back to the operator (often via leaked tokens, repository references, or Claude Desktop config patterns) so the disclosure reaches the actual maintainer rather than the abuse desk of an unrelated cloud.

Voice agents pair an LLM with real-time speech-to-text, text-to-speech, and phone-call infrastructure. Vapi and Retell are the managed-platform leaders, both used to build customer-support and outbound-sales bots that sound like humans on a phone call. LiveKit Agents is the open-source real-time framework. Pipecat (Daily.co) is the Python-native voice agent framework. Behind every "AI agent answered my call" experience is one of these orchestrating Whisper, GPT/Claude, and a TTS engine on a sub-200ms budget.

Voice agent control planes hold the most invasive credentials in the AI stack: a phone number, an outbound-calling ability, and a recording of every call the operator has placed or received. When exposed without auth, an attacker gets a free phone number with the operator's billing relationship and a verbatim audio archive of every customer conversation, including account verification phrases, credit card readbacks, and the medical or legal context the customer thought was private.

We probe the dashboard and admin APIs (Vapi's /v1/calls, LiveKit's WebSocket control endpoint, Pipecat's status server). Call counts and duration distributions characterise the operator's traffic. We never trigger outbound calls. Recording filenames or call IDs are sufficient attribution evidence; most operators name calls by their internal campaign ID which identifies the team without our needing to listen to anything.

n8n and Flowise are the Zapier of the AI era: visual builders where every node can be an HTTP call, a database query, an LLM call, or a downstream automation. They are how non-engineers ship real agentic systems: drag a Gmail node, an OpenAI node, a Postgres node onto a canvas, click run. The expressive power is genuinely impressive, and that's why they have caught on in startups, marketing teams, and internal-tools shops.

Every workflow is a JSON document containing the credentials of every service it touches. The default n8n install exposes the editor at / with no auth on first boot; the operator is supposed to enable basic auth themselves. Many don't. Flowise has the same shape: visit the IP, see the canvas, see the API keys baked into the OpenAI node, see which CRM is wired to which Gmail account. A single exposed instance can leak the API keys for the operator's entire SaaS stack, plus a list of every workflow they run.

We fingerprint the editor by its asset bundle, then read the workflow list through the public REST API (no auth in the default config). Each workflow's JSON exposes credentials by reference. We resolve the reference through the credentials endpoint and confirm the secret is present without ever exfiltrating it. We catalogue the workflow names because they tell the operator's story better than any banner: "Daily-report-to-CEO", "Sync-Stripe-to-Notion", etc.

Open WebUI (formerly Ollama WebUI) is the most popular self-hosted chat interface for local LLMs. It looks like ChatGPT, talks to Ollama or any OpenAI-compatible backend, supports multi-user accounts, RAG document upload, and has become the de-facto control panel for self-hosted AI. LibreChat, Chatbot UI, and a handful of others share the niche.

Open WebUI ships with open registration enabled by default: visit the URL, click "Sign up", you're inside. The first user is silently promoted to administrator, and admin accounts can read every other user's chat history, upload arbitrary RAG documents into the shared knowledge base, and route prompts through any configured backend at the operator's expense. When the operator never bothers to disable signups (and very few do), anyone who finds the IP becomes a peer user with full access to the whole multi-tenant shared corpus.

We confirm Open WebUI by its /manifest.json and the very specific bundle hash of its frontend, then test the registration endpoint with a benign account creation. We do not enumerate other users' chats; the proof of exposure is the successful account itself, which we screenshot and report. Where the deployment connects to a backend gateway (LiteLLM, OneAPI), we note which provider's API key the operator is paying for. That's the quota-drain story that makes the disclosure land.

Code agents pair an LLM with a development environment. The model reads the codebase, edits files, runs tests, and submits PRs. Aider (Paul Gauthier) is the terminal-native pair-programming agent. OpenHands (formerly OpenDevin) is the all-in-one autonomous-developer platform. Continue.dev is the IDE plugin the model drives from inside VS Code or JetBrains. SWE-agent (Princeton) is the research-grade benchmark agent. Cline and Roo Code sit in the same niche. Together they are how the "AI writes the code" workflow actually ships.

A code agent runs as the operator inside a development environment with the operator's git credentials, SSH keys, cloud SDK config, and shell history. When the agent's web UI or REST control plane is exposed without auth, an attacker drives the same shell. They can read the codebase (including secrets in .env files the agent has visibility into), commit and push to the operator's repos, deploy via the operator's CI hooks, and pivot via any SSH credential the agent's environment carries. Most installs assume "this is on my laptop" and never reconsider when the operator deploys to a remote workstation.

We probe the agent's web UI for the framework signature (OpenHands, Continue server, Aider's --browser mode all have distinct asset bundles) and read the workspace path from the status endpoint. The workspace path is enough to characterise the operator (corporate hostname, repo name, often the user's home directory). We never invoke the agent. Workspace metadata is sufficient attribution evidence.

ComfyUI is a node-graph editor for diffusion models: Stable Diffusion, FLUX, Stable Video, AnimateDiff. You wire model loaders, samplers, conditioning nodes, and post-processing into a graph and run it. Automatic1111 is the older single-page-app cousin. Both are how artists, hobbyists, and a growing number of commercial studios actually generate images and short video at scale on self-hosted hardware.

ComfyUI ships with no authentication and an HTTP API that accepts arbitrary Python custom-node code execution as a feature. Workflow JSON files include the full graph (model paths, LoRA weights, sometimes seeds and prompts), which is enough to reconstruct an operator's creative process or extract proprietary fine-tuned weights. The /object_info endpoint enumerates every loaded model and custom node; the queue endpoint accepts arbitrary workflows from anyone who can reach the port.

We probe /object_info for the model inventory, /queue for currently-running jobs (often labelled with the operator's project name), and /history for the last N generations. The history endpoint is particularly attribution-rich: it contains thumbnails of past outputs, which on commercial deployments is the operator's actual product pipeline. We never enqueue jobs. The read surface alone is sufficient evidence.

Gradio and Streamlit are the two ways researchers turn a script into a web app in one afternoon. Gradio (originally Hugging Face) gives you a chat interface or an image-uploader for any function in three lines of Python. Streamlit (now Snowflake) gives you a full dashboard. Both are aimed at the same need: "I built a model, my collaborator wants to play with it, can I have a UI by tomorrow?"

Both frameworks make sharing easy and authentication invisible. A Gradio app with share=True becomes a tunnelled public URL with no password. A Streamlit app started with streamlit run listens on 0.0.0.0 by default. The model behind the UI typically processes uploaded files. The exposure is "an attacker uploads a file my code unpickles, my code reads from S3, my code calls a paid API." The UI is the rendered version of an entire backend pipeline, and that pipeline runs as the operator.

We fingerprint Gradio by the /info endpoint (it advertises the function signatures of every Python callable wired into the UI) and Streamlit by the WebSocket handshake on /_stcore/stream. From there the API surface tells the story: a Gradio app exposing an image-classification function is a model demo; a Gradio app exposing database-query is the operator using Gradio as an internal admin panel they didn't realise was public.

Jupyter is where most of modern machine-learning research happens. A notebook is a live Python (or R, or Julia) shell with rich output (plots, tables, images) that runs inside a kernel an operator can leave running for days. JupyterLab is the polished IDE on top, JupyterHub the multi-user variant. Every ML grad student, every model fine-tuner, every quantitative analyst lives in this stack.

A Jupyter server with no token (or a token shared in a public Slack, or a token from a screencast, or a token in a Docker Compose file pushed to GitHub) is a remote Python shell with the operator's full filesystem, GPU, and cloud credentials available via the imported boto3/google-cloud SDKs. The exposure isn't the notebook. It's the kernel behind it. Anyone reaching the port can spawn a new kernel and run arbitrary code under the operator's identity.

We probe for the token-prompt page, then the API at /api/sessions to enumerate live kernels (this works without auth in surprisingly many configs, and the response is a perfect operator-attribution payload: kernel paths contain user homedirs, repo names, and dataset filenames). We never spawn a new kernel on the target. The session list alone is sufficient to attribute, draft the disclosure, and demonstrate impact in evidence form.

An LLM gateway is a reverse proxy for model APIs. The operator wires up keys for OpenAI, Anthropic, Google, Mistral, their own Ollama box, and a handful of fine-tunes; the gateway exposes a single OpenAI-compatible endpoint and handles routing, rate-limiting, fallback, observability, and cost accounting. LiteLLM is the Python-native one (most common in research); OneAPI is the Go/Chinese-ecosystem one (most common in commercial deployments). Portkey, Helicone-Proxy, and APISIX-AI sit in the same niche.

The gateway holds the operator's entire AI billing relationship. If it's exposed without auth, an attacker can route arbitrary prompts through any of the configured providers: burning the operator's quota, exfiltrating embedded prompts that may contain customer data, and racking up usage charges on premium models. Worse: the admin panel typically lists every model alias, the keys behind them, and the per-user/per-team budget. The attacker learns the operator's whole AI org chart before issuing a single request.

We confirm the gateway by its /v1/models response shape (LiteLLM's is distinct from a vanilla OpenAI proxy), then check /health/readiness and /key/info for admin-key reachability. The key endpoint, when unauthenticated, returns the operator's full virtual-key inventory including budget caps and team assignments. We do not issue paid completions. The catalogue is enough to demonstrate the quota-drain risk and identify the operator.

Retrieval-Augmented Generation is how an LLM gets access to documents it wasn't trained on: your company wiki, last week's invoices, a PDF of your medical history. A RAG pipeline chains a document loader, an embedder, a vector store, a retriever, and the LLM call. Frameworks that package this into one runtime: Dify (the most polished, Chinese-origin), Flowise (visual builder on top of LangChain), Haystack (Deepset's enterprise stack), Quivr, Verba. The pipeline is what turns a model into a product.

Most RAG deployments are research artefacts that grew into prototypes that grew into production. Dify ships with admin@admin.com / password as the seed account; a fresh Flowise install exposes the canvas and every workflow's embedded API keys; Haystack's REST API is unauthenticated by default and its /query endpoint will dutifully retrieve and return any document the embedder has indexed. The corpus exposed this way ranges from public PDFs all the way to attorney-client communications, internal sales decks, and patient records.

We probe each framework's signature endpoints: Dify's /console/api/setup for the seed-account state, Flowise's /api/v1/chatflows for the workflow catalogue, Haystack's /search for the indexed corpus reach. When the retriever is reachable, we issue a single low-volume query (e.g. "summary") to confirm the corpus contains real content, capture the document titles and sources from the response, and stop. Title metadata is enough to attribute the operator and characterise the data class without reading the documents themselves.

A reranker is the quality filter that sits between vector retrieval and the LLM. The vector DB returns the top-50 candidate documents fast but loosely; the reranker re-scores them with a smaller cross-encoder model that actually reads each document against the query and orders them by real relevance. Cohere Rerank (managed) and Jina Reranker (open source) are the two most common; BGE-Reranker (BAAI) is the strong open default; Infinity serves rerankers alongside its embeddings. Most production RAG stacks have one in the middle and most teaching examples skip it entirely.

Reranker servers ship the same way embedding servers do: OpenAI-compatible HTTP, no auth, on the assumption that only the upstream RAG pipeline calls them. When exposed they leak two things: (1) the model identifier, which indicates how seriously the operator is doing RAG, and (2) the queries the operator is processing, since some servers log recent inputs to a status endpoint for debugging. The query log is the more damaging signal because queries often contain the original user prompt verbatim.

We probe /v1/rerank for the version banner and /v1/models for the model inventory. We do not submit reranking workloads. Where a debug or status endpoint exposes recent traffic we capture only the count and timing, not the query content. The model identifier and traffic profile together characterise the operator's RAG seriousness without our ever reading queries.

Embedding servers turn text (or images, or audio) into high-dimensional vectors that vector databases can search. Every RAG pipeline has one of these in the middle. Text Embeddings Inference (TEI) is Hugging Face's production-grade Rust runtime; Infinity (Michael Feil) is the fast Python alternative; the original sentence-transformers library ships its own HTTP server; Ollama also serves embeddings via /api/embeddings for the small-deployment crowd. They look like miniature inference servers because that's exactly what they are.

Embedding servers expose an OpenAI-compatible /v1/embeddings endpoint by default and are typically deployed without auth, on the assumption that "only my RAG pipeline talks to it." When the host ends up reachable on a public IP an attacker gets a free embedding service, useful for their own RAG pipelines. More damaging: the model loaded by the server is often a fine-tuned variant trained on the operator's private corpus, and those custom weights are often what makes the operator's product different from the generic alternative.

We hit /v1/models (or the /info endpoint TEI exposes) for the model inventory and tokenizer metadata, then capture the model identifier. If the model name maps to a known Hugging Face artefact we attribute via the publishing org. If it's a private fine-tune we capture the architecture and tokenizer fingerprint, which is sufficient evidence of operator intellectual property without our needing to issue any embedding requests.

llama.cpp is the C++ reference implementation of LLaMA inference, the project that pioneered GGUF quantization and runs LLMs on commodity CPU + small GPU hardware. Its built-in HTTP server (llama-server) exposes an OpenAI-compatible API at /v1/models, /v1/chat/completions, plus the platform-native /props and /completion endpoints. Operators frequently co-deploy llama.cpp on the same port as Ollama (:11434) so existing Ollama clients can swap backends transparently.

llama.cpp has no built-in authentication. The framework's design assumption (same as Ollama, vLLM, Triton) is that auth comes from a reverse proxy. Population-scale surveys find ~70% of :11434 ports running llama.cpp instead of (or alongside) Ollama, all unauthenticated. The /props endpoint discloses the loaded chat template (sometimes a custom-trained one), the model's n_ctx, the total slots, and the operator's quantization config. /completion accepts arbitrary prompts and burns operator compute. When the operator has loaded a custom-finetuned model (Xiyan_FT_14B, Baichuan_32B_medical, etc.), the model itself is operator IP.

We probe three alternative endpoints to distinguish llama.cpp from co-deployed Ollama: /v1/models should return JSON with "owned_by":"llamacpp", /props returns the server-info JSON with default_generation_settings + chat_template, and the HTTP Server: header reads llama.cpp on most builds. We never POST /completion or /v1/chat/completions; the model identity + config disclosure is the finding. The llama.cpp fingerprint was added to aimap in v1.9.4 (2026-05-15) after a field instance was caught running custom BitNet-b1.58-2B-4T on a Contabo SG host.

Ollama is the easiest way to run a large language model on your own hardware. One binary, one command: ollama pull llama3 and you have a local OpenAI-style API on port 11434. It pulls quantised model weights from its own registry, manages the GPU layout, and serves an OpenAI-compatible chat endpoint. It is genuinely beautifully engineered, and it is the reason most of the world's self-hosted AI exists.

The framework has no authentication concept by design. The maintainers' position is that auth is an upstream concern (run it behind a reverse proxy, behind Tailscale, behind your firewall). Most operators don't. Any host running Ollama on a public IP is a free, unauthenticated, unlimited model endpoint: an attacker can list the model inventory at /api/tags, chat through /api/chat, and even pull arbitrary new models via /api/pull, which silently downloads gigabytes onto the operator's disk and bills any attached cloud egress.

We hit /api/tags to enumerate the loaded models (this is the population-scale fingerprint behind our cross-cloud surveys), capture the response, and attribute via the kind of models loaded: a host serving gemma3:e4b and nothing else is a hobbyist; a host serving fifteen fine-tuned variants of llama3:70b with custom Modelfiles is a commercial operator. We do not issue chat completions. We do not call /api/pull. The model inventory tells the whole story.

Speech models translate between text and audio in both directions. Whisper (OpenAI) is the universal speech-to-text engine; Piper is Rhasspy's tiny fast TTS; Coqui XTTS is the high-quality multi-speaker TTS that survived the company's death; RVC (Retrieval-based Voice Conversion) is the model that turns one person's voice into another's. Servers like wyoming-piper, openedai-speech, and the Whisper-server reference deployments wrap these models in HTTP APIs.

The model itself isn't the exposure. The audio it processes is. Whisper servers exposed without auth become free transcription endpoints; we've found deployments where the operator was clearly using their server to transcribe internal meetings, with the audio paths in the request log telling the story. RVC servers carry an additional risk: the operator's trained voice models are stored on disk and served via the API. An attacker can pull a celebrity or executive voice model, then synthesise arbitrary speech in that voice.

We probe /v1/audio/transcriptions and /api/voices for the model and voice inventory, then characterise what kind of audio the operator processes by the file-extension distribution in the recent-jobs endpoint. We never submit audio. The voice-model catalogue is sufficient to identify problematic deployments (any voice model whose name matches a real person warrants disclosure to that person's representation, not just the cloud abuse desk).

Triton is NVIDIA's enterprise inference server: the heavyweight runtime designed for production model serving across every hardware target NVIDIA makes. It supports TensorRT, ONNX, PyTorch, TensorFlow, vLLM, and Python backends; it runs ensemble pipelines across models; it has a binary protocol (gRPC) and an HTTP/REST one. When you see a tritonserver container in a Kubernetes deployment, you're looking at someone serious about ML throughput.

Triton's HTTP endpoints (/v2/models, /v2/repository/index, /v2/health/ready) are unauthenticated by design (NVIDIA's position: enforce auth at the ingress). The model repository index is a verbatim list of model names, their versions, their backends, and their state. For commercial operators these names are their intellectual property: fraud-detection-v3, recommender-cold-start-v7, biometric-match-v2. We've found Triton instances exposing classifier models that are clearly pulled from the operator's product, alongside the safety classifiers the operator hopes nobody bypasses.

We hit /v2 for the version banner, /v2/repository/index for the catalogue, and /v2/models/{name} for the model config (which exposes input/output tensor shapes, sufficient to reverse-engineer the model's purpose without ever invoking it). When the model is a published architecture (a known LLM, a known vision backbone) we do not issue inference. When it's a custom fine-tune we capture only the metadata.

vLLM is the inference engine of choice when you actually have GPUs and want to serve a model at scale. It implements PagedAttention (a memory-management technique that lets a single GPU host serve dozens of concurrent requests without OOMing) plus continuous batching, speculative decoding, prefix caching. It's what most commercial fine-tune deployments and university research clusters reach for once "Ollama on a laptop" stops being enough.

vLLM exposes an OpenAI-compatible API on port 8000 by default. There is an --api-key flag. Most operators don't set it. An exposed vLLM instance is a free GPU compute pool serving whichever model the operator loaded (often a 70B parameter fine-tune that costs $5k/month to host on commercial infra), with token throughput high enough to be useful for an attacker running their own quota-heavy workloads. The /v1/models endpoint reveals the model name and architecture, which is often enough to identify the operator's research lab.

We probe /v1/models for the model inventory and /metrics for the Prometheus exposition (vLLM publishes detailed per-model token statistics here, including average request size, which is useful for inferring deployment age and traffic). For research instances we map the model name back to the publishing institution via Hugging Face. Disclosure goes to the lab's security contact directly, not the cloud abuse desk.

A bare LLM has no memory between conversations. Agent-memory frameworks fix that. Mem0 is the runaway leader. It watches an agent's conversation, extracts the facts worth remembering ("user prefers vegetarian", "user lives in Denver", "user's company uses Postgres"), stores them in a vector DB, and re-injects the relevant ones into future prompts. Letta (formerly MemGPT), Zep, and Mem-Agent sit in the same shape. Together they are how an agent goes from goldfish to colleague.

The memory store is a verbatim record of the operator's most-used agents' private context: user preferences, business facts, sometimes credentials and PII the user mentioned in passing. Mem0's REST API exposes /v1/memories/ with no authentication in the default Docker compose. Each memory record is attributed to a user_id, so the data is also indexed by the operator's identity scheme. That makes it both more useful for the user and more useful for an attacker who can now query "all memories about user 47".

We list memories via the unauthenticated API, capture the first few records' metadata (timestamps, user IDs, memory categories), and stop. We do not page through the corpus. The memory categories alone (preferences, work-history, medical) characterise the data class for the disclosure without our needing to read individual entries.

Backups are easy to forget about. That's why they're dangerous. The popular ML and Kubernetes backup stack: Velero snapshots Kubernetes cluster state plus the persistent volumes underneath; Restic is the encrypted-by-default file backup tool whose REST server mode listens on a public port for incoming snapshots; Barman does Postgres-specific backup-and-restore; Longhorn (Rancher) is the Kubernetes block-storage layer that snapshots volumes on a schedule; BorgBackup sits in the same niche as Restic. In an ML deployment these tools are how the operator's model weights, training datasets, and vector-DB volumes are persisted between restarts.

A backup is a verbatim copy of the system at rest. And at rest, every secret is unencrypted and every model file is intact. Restic's REST server, when exposed without HTTP auth, lets an attacker download every snapshot the operator has ever taken (which is usually the entire model registry plus the training data). Velero exposes its API through the Kubernetes API server, so a misconfigured cluster RBAC turns into a one-step model-exfiltration primitive. Longhorn's UI ships without auth on port 80 and lists every volume by name (model-weights-pvc, training-data-pvc), pointing attackers exactly where to chain next.

We probe Restic REST /snapshots for the snapshot inventory (this works without auth in the default config), Longhorn /v1/volumes for the volume list, Velero's BackupStorageLocation objects via the Kubernetes API. We do not download snapshots. The metadata (snapshot IDs, volume names, timestamps, sizes) is sufficient evidence and avoids us ever touching the model files themselves. A snapshot called mlflow-pvc measuring 240GB on a research host tells the disclosure story without any further reach.

You can't fine-tune a 70B model on a laptop. ML compute orchestrators are how teams rent and schedule expensive GPUs. RunPod (managed) lets a researcher spin up an 8xA100 pod from a Jupyter button; Ray (Anyscale) is the Python-native distributed-compute framework; Volcano is the Kubernetes GPU scheduler; Kubeflow wraps both for an MLOps workflow; SkyPilot abstracts cloud GPU provisioning across providers. Each is the layer between "I need 80GB of VRAM" and "the GPU is now running my code."

These systems hold very expensive credentials. RunPod API keys map to billable GPU pods; Ray clusters mount the operator's full SSH agent and kubeconfig; Kubeflow Pipelines runs as a service account with cluster-wide read on most installs. An exposed Ray dashboard is a one-click ray submit endpoint that runs arbitrary Python on the operator's GPU fleet. An exposed RunPod control plane lets an attacker spin up new pods for arbitrary workloads on the operator's bill. The cost vector here is real: we have seen disclosures involving five-figure unauthorised GPU rentals.

We probe Ray's dashboard /api/version, Kubeflow's /pipeline endpoint, and SkyPilot's API server for fingerprints. Where reachable, we list jobs (no submit, no cancel) to characterise what the operator runs and how much GPU they have available. Job names typically include the model architecture and training step, which is enough to attribute the operator and characterise the loss vector for the disclosure.

Every modern LLM deployment runs on container infrastructure. The substrate layer is technically not LLM-specific: the Docker daemon, etcd (k8s/standalone), HashiCorp Vault (secrets), HashiCorp Consul (service mesh), Portainer (UI), Argo CD (continuous deployment), and the kubelet itself. Unauthenticated exposure here is sometimes more impactful than exposure of the LLM service it carries. Docker socket exposure = container escape = root on host. etcd unauth = full k8s state dump. Vault uninitialized = anyone calls /v1/sys/init and becomes the operator.

The framework defaults vary across the layer:

- Docker daemon on TCP 2375 ships without auth in the official documentation's "remote API" examples; operators copy-paste the config and forget the TLS step. Population-scale unauth rate: high. - etcd v2 API (/v2/keys) ships without auth in older deployments; v3 default is gRPC-auth-on but operators frequently turn it off. - Vault is auth-on-default at the framework layer; the only unauth surface is the /v1/sys/init bootstrap endpoint, which is intentionally open until the first init call. Uninitialized Vaults are a one-shot full-takeover surface. - Consul ships with ACLs disabled by default in framework config (Tier-A); 100% of reachable Consul instances at population scale have ACL off. - Argo CD** is auth-on-default (Tier-C). 99.93% of the population is properly gated; ~0.07% set the anonymous-read template-config and leak app inventories.

Each substrate platform has its own identity-and-state probe. Docker: GET /version. etcd: GET /version + GET /v2/keys?recursive=false (top-level keys only). Vault: GET /v1/sys/seal-status + GET /v1/sys/init (sealed / unsealed / uninitialized). Consul: GET /v1/agent/self + GET /v1/catalog/services. We never read secret values, never PUT/DELETE/POST /v1/sys/init. The presence of the substrate at the public boundary is the finding; the operator's k8s topology, secret-engine mounts, and service catalog leak as metadata even when the data layer is gated.

Models learn from labels. A data-labeling platform is the editing environment where humans annotate the raw data: boxes around objects, classifications on text, transcriptions of audio, span-level reasoning traces for RLHF. Label Studio (HumanSignal) is the universal multi-modal one; Argilla (Hugging Face) is the LLM-centric one; CVAT (Intel/Roboflow) owns computer-vision; Doccano is the lightweight NLP option; Prodigy (Explosion) is the paid serious one. The dataset that comes out of these tools is what the next model gets trained on. The labelling stack is upstream of model behaviour itself.

The platform exposes two things. First, the raw data being labelled: often unredacted medical images, customer support transcripts, legal documents. Second, the labels themselves, which encode the operator's labelling rubric and frequently the model bias they are trying to amplify or correct. Default deployments have weak credentials (admin/admin is alarmingly common in the Label Studio Docker Compose examples) or token-based auth that operators share in Slack and forget to rotate.

We confirm the platform via its /version endpoint, then list projects via the unauthenticated API surface (Label Studio's /api/projects works without auth on the default install). Project names plus task counts tell the story: a project called "medical-imaging-batch-7" with 12,000 tasks is a healthcare operator; a project called "red-team-prompts" with a few hundred tasks is an AI lab's safety team. We never download tasks. The metadata characterises both the data class and the operator function.

Before a document gets embedded, it has to be turned into clean text. PDFs have layout. Word documents have tables. Slide decks have hierarchy. The document-parsing layer extracts all of that into the markdown-or-JSON the embedder expects. Unstructured.io is the multi-format incumbent. LlamaParse (LlamaIndex) is the cloud-API competitor optimised for RAG. marker is the open PDF-to-markdown specialist; MinerU (OpenDataLab) is the high-quality alternative. Docling (IBM) is the newer research-grade option. Every serious RAG pipeline runs documents through one of these before they ever reach the vector DB.

The parser server processes a stream of operator-uploaded documents and caches them on disk. When the parser is exposed without auth, the document queue and the parsed-output cache are both reachable. That cache often contains documents the operator has marked private. Internal contracts, HR files, partner agreements, all sitting in plaintext markdown form on the parser's disk. The parser is also a high-CPU service: an attacker can submit large or malicious PDFs to either burn the operator's compute or trigger known parsing-library RCEs.

We probe the parser's REST endpoint for the version banner and check the status endpoint for queue depth and recent-job filenames. The filenames characterise the operator's document inventory and frequently identify the legal or business unit the parser is serving. We do not submit documents.

Fine-tuning is the bridge between a generic foundation model and the operator's actual product. Axolotl (Wing Lian) is the YAML-driven post-training framework most labs reach for. LLaMA-Factory is the all-in-one Chinese-ecosystem fine-tuner with a polished WebUI. Unsloth makes LoRA fine-tuning faster and cheaper on consumer GPUs. torchtune (PyTorch) is Meta's official lightweight option. TRL (Hugging Face) provides the underlying RLHF/DPO trainers. Together they are where the operator's training data, base model choice, and tuning recipe live.

A fine-tuning host is a workstation with the operator's training corpus on local disk, their Hugging Face token in the environment, their base model weights downloaded to a local cache, and their output adapter weights in a results directory. LLaMA-Factory's WebUI ships without auth on first boot; Axolotl jobs running under tmux/screen leave the dataset filename visible in the process list of any reachable monitoring endpoint. The exposure is the operator's entire training strategy: what data, what base model, what hyperparameters, what they're trying to teach the model to do.

We probe LLaMA-Factory's WebUI for the version banner and the recent-jobs endpoint, Axolotl's prometheus metrics for active runs, and any job scheduler integration that surfaces the dataset path. Job names and dataset filenames tell the story without our needing to read training data.

The GPU-compute tier is the metrics and scheduling plane beneath every LLM training and inference deployment. NVIDIA's DCGM-exporter publishes Prometheus metrics from each GPU (utilization, memory, temperature, power), with a Hostname tag the operator sets to identify the box. Run:AI (now NVIDIA Run:AI) and NVIDIA Bright Cluster Manager orchestrate fleets of GPUs across clusters. Slurm REST is the HPC-tier scheduler.

DCGM-exporter is a Prometheus exporter. The framework assumes the metrics endpoint sits inside a private network. There is no application-level authentication; auth is meant to come from the operator's network ACL. Operators who expose :9400 to the public internet inherit "no auth" by deployment-config mistake, not framework-default mistake. The leak is rich: GPU model, operator-set hostname, utilization timeline. The combination fingerprints what's being trained (LLM training has a different utilization signature than CV training has a different signature than inference). Operators running H100, H200, A100, RTX PRO 6000 Blackwell-class hardware are exposing six-figure compute fleets at the metrics layer.

We probe :9400/metrics and parse the Prometheus text for DCGM_FI_DEV_GPU_UTIL, modelName="...", and Hostname="..." labels. Operator hostnames are operator-attribution-rich (video-gpu007-mojo-mia.vs3.com discloses a video-AI rental operator with a Miami location). We do not scrape the time-series; instantaneous metrics suffice for severity. Run:AI dashboards, Bright Cluster Manager, and Slurm REST get their own fingerprint pathways; for each, we read identity-only and never invoke a job-submission endpoint.

The medical-AI tier covers everything from a DICOM image archive (the canonical storage format for medical imaging) to specialty inference servers tuned for clinical workloads. Orthanc is the most-deployed open-source DICOM PACS. dcm4che / dcm4chee-arc is the Java-based enterprise option. DICOMweb (QIDO-RS, WADO-RS, STOW-RS) is the HTTP-API standard. MONAI Label is the NVIDIA-sponsored medical-imaging annotation server. NVIDIA NIM is NVIDIA's containerized model-serving platform increasingly used for clinical inference.

DICOM servers ship without auth by default on the DICOM protocol port (104 / 11112) and frequently on the HTTP plugin (DICOMweb on :8042 for Orthanc, varied for dcm4che). Operators frequently use the protocol port as the public boundary, with no auth, because that's what every DICOM tutorial in 2010-2018 told them to do. Once reachable, the QIDO-RS endpoint discloses studies (patient identifiers, accession numbers, modality, study date). Orthanc's REST API exposes the same plus image data. MONAI Label's /info/ discloses loaded trainers and datasets, operator-attribution-rich for any deployment doing custom finetuning.

For each platform we probe the documented identity endpoint: Orthanc's /system, dcm4che's /dcm4chee-arc/aets, DICOMweb's /studies (with ?limit=1), MONAI's /info/, NIM's /v1/metadata. We confirm protocol shape (DICOM tag 0020000D is the StudyInstanceUID; its presence in a JSON ?limit=1 response is the high-confidence DICOM marker). We never fetch image data; the study and series counts plus the operator-attribution metadata are sufficient for severity. Disclosure pathways are clinical-data adjacent (HIPAA / GDPR / equivalent) and follow the hold-cluster-detail rule until acknowledged.

When you train models for a living you need to track every experiment: hyperparameters, metrics, artefacts, the model file itself. MLflow (Databricks) is the open default; Weights & Biases is the polished SaaS incumbent; Kubeflow Pipelines, Metaflow (Netflix), and Comet sit in the same niche. The tracking server is the operator's training history, their model registry, and increasingly the artefact store from which production deployments pull.

MLflow has no native authentication. The maintainers' guidance is to deploy behind a reverse proxy. Most operators don't, and the consequences are richer than they look. CVE-2023-1177 turns the artefact-fetch endpoint into a path-traversal RCE: an attacker creates an experiment with a crafted artefact URI and reads any file the MLflow process can read. We have found instances where this CVE was actively being exploited by other parties: the attacker's experiment runs were sitting alongside the operator's, with names like "recon", "shell", "check". The operator's model files, training data paths, and cloud-credential filenames all leak in the same way.

We probe /api/2.0/mlflow/experiments/search for the experiment inventory and /api/2.0/mlflow/runs/search for run-level metadata. We do not invoke the artefact-fetch endpoint. Operator attribution comes from the experiment names, the model architecture (visible in the params), and frequently the dataset URIs which point at named S3 buckets. Where we see signs of third-party exploitation we escalate the disclosure with the threat-actor evidence included.

Models live somewhere. The Hugging Face Hub is the public default; ModelScope (Alibaba) is the Chinese equivalent; Replicate hosts serverless fine-tunes; BentoML's BentoCloud is the Python-native deployment registry. Most large operators run a private mirror of one of these so internal teams can pull models without going to the public internet, and so the operator's own fine-tunes can be versioned and served through the same interface every framework already speaks.

A private hub mirror is a webhook target, a model-weights store, and an API token issuer all in one. When the mirror is exposed without auth, an attacker pulls every model the operator has uploaded, including private fine-tunes that contain the operator's training-data leakage. Worse, most mirrors implement the same /api/models/upload endpoint as the upstream, so an attacker can push a malicious model into the operator's namespace and wait for an internal team to pull it. The supply-chain risk is real: PyTorch models execute arbitrary Python on load.

We probe /api/models (HF-compatible) or /api/v1/models (ModelScope) for the inventory and read the model card metadata. Model names plus sizes characterise the operator and identify private fine-tunes. We do not download weights. Where the upload endpoint is reachable we confirm reachability with an OPTIONS request and stop.

Models and datasets are big (gigabytes to terabytes per artefact), and the universal storage substrate for them is S3-compatible object storage. MinIO is the self-hosted on-prem option (also bundled with most RAG distributions like Dify); AWS S3, Google Cloud Storage, and Cloudflare R2 are the cloud variants; Garage and SeaweedFS are the smaller open alternatives. Every model registry, every fine-tuning job, every RAG document loader writes through one of these.

MinIO ships with the credentials minioadmin / minioadmin and a public console on port 9001. Most operators change the password but leave the console reachable; many leave the API on port 9000 with a public bucket policy that reveals the bucket inventory. The buckets are typically named after the project (model-weights, training-data-2026, customer-uploads), and the keys inside them describe the artefact lifecycle. S3 buckets exhibit the same pattern at a different scale: misconfigured bucket policies, public ACLs from old aws s3 sync --acl public-read mistakes, and the now-classic "bucket name is the company name plus production" enumeration vulnerability.

We list buckets through the unauthenticated MinIO admin API where reachable, and check S3 buckets via probabilistic name enumeration (no brute-force, just the patterns that fall out of the operator's known naming conventions). We confirm exposure with a single HEAD against a bucket-listing URL; we do not download objects. Bucket names plus their key-prefix structure are the disclosure evidence.

Every modern LLM observability stack writes its traces, metrics, and call-history into a columnar OLAP backend. ClickHouse is dominant: it's the storage tier under SigNoz, Phoenix-on-OTLP, PostHog product analytics, Plausible, and many custom in-house observability platforms. Cassandra, ScyllaDB, and Apache Pinot fill adjacent niches. When the upstream observability tool is itself unauthenticated, the OLAP backend is also typically reachable on the same host, often on its own default port.

ClickHouse's official Docker image creates a default user with no password. The operator must set CLICKHOUSE_USER and CLICKHOUSE_PASSWORD at container start, or modify users.xml. At population scale, ~18% of reachable ClickHouse instances skip this step. The exposure surface is the operator's entire app schema: database names disclose what the operator stores (signoz_traces, posthog, plausible_events_db, custom vllm_service, ai_hedge_fund, scentedai_fragid_new). LLM call traces, with full prompt and response bodies, often land here.

We send GET /ping to confirm a ClickHouse server, then GET /?query=SELECT+version() (read-only sanity check) and GET /?query=SHOW+DATABASES+FORMAT+JSON for the database list. Database and table names are the finding; we never SELECT * FROM any user table. For Cassandra/Scylla, the TCP banner on port 9042 confirms identity. The classification is intel-disclosure-tier, not RCE-tier. For observability backends, the disclosed information is exactly the LLM call history the operator is trying to keep private.

Search engines power both the classic full-text retrieval tier (Elasticsearch, Apache Solr, Vespa) and the modern vector-similarity tier that LLM apps lean on for retrieval-augmented generation. The line between them has blurred since 2022: every mainstream engine (Elastic, OpenSearch, Solr 9, Vespa, Meilisearch, Typesense) now ships dense-vector indices alongside their inverted-index core. Many production RAG pipelines store their LangChain or LlamaIndex document chunks here rather than in a dedicated vector DB.

The official Docker images ship with auth off by default. The operator must opt into security: set xpack.security.enabled=true for Elasticsearch, configure Solr's security.json to enable the basic-auth plugin, or set the Meilisearch master key via environment variable. Across population-scale surveys, ~54% of reachable Elasticsearch instances skip the step entirely. Solr's older Docker tags (solr:7.x) compound the problem with multiple unauthenticated remote-code-execution CVEs: CVE-2019-17558 (Velocity Template SSTI), CVE-2019-0193 (DataImportHandler), CVE-2019-12409 (JMX-RMI). The data layer itself discloses operator app schema via index and core names long before any document is read.

We probe each engine's identity endpoint (/ for Elasticsearch's version JSON, /solr/admin/info/system for Solr, /health for Meili and Typesense, /state/v1 for Vespa), confirm version, and then call the documented listing endpoint (/_cat/indices, /solr/admin/cores, /indexes, /collections). Index and core names are the finding: operators name things like rag-document-chunks, spring-ai-document-index, entity_vectors, kb_documents_v1. Disclosure of the operator's app architecture happens before any document fetch. We never run free-text queries against the index; the names alone justify the severity claim.

A vector database stores high-dimensional embeddings, numerical fingerprints of text, images, audio, and answers nearest-neighbour queries against them. It is the memory of every RAG system. The popular ones each carve out a slightly different niche: ChromaDB (the developer-friendly default), Qdrant (Rust-fast, popular in production), Milvus (the heavyweight enterprise option), Weaviate (schema-rich), Pinecone (managed-only), pgvector (Postgres extension), Elasticsearch with its dense_vector type (the one that already lives in your stack).

Every popular vector DB ships with authentication off by default and a public listen socket. The exposure isn't theoretical, it's the contents. Every collection is named (often after the project: customer-support-knowledge, legal-discovery-q4, patient-notes-v2); every collection contains the embedded text in its metadata; many collections also contain the original source URL or document ID. Reading a single collection lets an attacker reconstruct most of the operator's internal corpus, plus the prompts the operator has been embedding (which often are customer queries).

We hit the heartbeat endpoint to confirm the engine, list collections via the unauthenticated metadata API, and read the first record's metadata only (never the raw vectors, never the bulk content). The collection names plus the metadata-schema fields are sufficient evidence of exposure. For operators we already know, universities, medical centres, financial institutions, we draft the disclosure on collection names alone, which cleanly avoids touching the contents in any reportable way.

Eval harnesses measure model behaviour against benchmarks: capabilities, biases, refusal patterns, jailbreak resistance. lm-eval-harness (EleutherAI) is the universal capability-eval; EleutherAI's safety eval forks track refusal/harm rates; NVIDIA Nemo Guardrails and Guardrails AI sit in front of production models and constrain output in real time; Inspect (UK AI Safety Institute) and Anthropic's evals are the research-grade options. Together they are how a serious AI deployment knows whether the model is doing what it's supposed to.

Eval and guardrail systems hold the operator's threat model: the prompts they consider harmful, the responses they consider unacceptable, the policy they want enforced. When an eval-harness server is exposed unauthenticated, an attacker reads the full set of red-team prompts the operator uses, learns which of those prompts the model currently fails, and gets a precise roadmap to bypass the operator's guardrails. The exposure of a guardrail configuration is also a disclosure of the policy boundary itself.

We probe for harness control endpoints (lm-eval's WebSocket UI, Nemo Guardrails' REST API on port 8000) and read the policy/eval inventory via the unauthenticated metadata endpoints. We never run new evals. The eval names alone are the disclosure evidence. Names like "jailbreak-bench", "medical-refusals", "copyright-output" characterise the operator's concerns and identify their team without our needing to read prompt bodies.

Once an operator runs an LLM in production they need to see what it's doing. LLM observability platforms record every prompt, every completion, every tool call, every retrieved document, with token-cost and latency overlays. Langfuse is the open self-hostable leader; Helicone is the proxy-based one; LangSmith (LangChain) is the SaaS option; Arize AI's Phoenix is the open-source agent development & evaluation platform; Lunary sits in the same space. Together they are the AI equivalent of Datadog, the system of record for everything the model has done.

The trace store is the operator's most sensitive AI artefact. It contains every customer prompt verbatim (which is often customer PII), every retrieved document (which is often the operator's private corpus), and every tool call with full arguments (which is often credentials in plain text). Langfuse ships with a project-key model that operators sometimes bypass by enabling the public-projects feature for "share a trace with my colleague" workflows and forgetting to disable it. The traces become indexed and crawlable by default after that.

We probe /api/public/projects and /api/public/traces for the trace inventory; the response shape confirms Langfuse and reveals project names along with first-seen and last-seen timestamps. We never read trace bodies. Project names attribute the operator (most are "customer-support-prod", "sales-enrichment", etc.) and the date range characterises the corpus volume. Trace counts in the millions on a single project warrant priority disclosure.

Prompts are code, and code that lives inside f-strings is hard to manage at scale. Prompt management platforms version, A/B-test, and govern prompts the same way GitHub manages source. PromptLayer is the SaaS leader. Pezzo, Promptly, and Agenta are the open-source alternatives. LangSmith (LangChain) and Langfuse also overlap into this space from the observability side. Together they are how a prompt becomes a versioned, deployable artifact instead of a magic string copy-pasted into twelve services.

The prompt store is a verbatim record of every system-prompt and template the operator has written, including the ones they tried and rejected. When the platform is exposed without auth, an attacker reads the operator's entire prompt history including the jailbreak-resistance prompts, the tone-of-voice instructions, the proprietary chain-of-thought patterns, and any embedded keys or URLs the operator pasted into prompt bodies. We have also seen credential-bearing webhooks defined in PromptLayer-style platforms, leaking the operator's downstream integrations.

We probe /api/prompts, /v1/prompts, or the platform-specific equivalent for the prompt inventory and read prompt names plus version counts. We do not read prompt bodies. The names alone ("customer-support-system-v3", "jailbreak-defense", "tone-formal") characterise the operator's product strategy without our needing to see the actual text.