01.5
Self-Hosted AI Security Testing
Self-Hosted AI Security Assessment
Find and secure the AI you run yourself
Local models keep data in-house, but the servers that run them often ship with no login. We discover, fingerprint, and test every model server, MCP server, and model file you host, then show what an attacker could reach.
The Problem
Local Isn’t Always Private
Most self-hosted AI tools are built for convenience. Many model servers ship with no login, some let anyone who reaches them run code, and one setting or a published container port puts them on the network. Researchers counted about 175,000 Ollama servers reachable from the internet in early 2026.
The software carries its own weaknesses. Since 2024, critical flaws have been disclosed in the most widely used inference software and in model files themselves, from files that run code when they load to caching features that can reveal one user’s prompts to another. We find which ones apply to your setup and show what an attacker could reach.
Common starting points:
- Ollama or LM Studio running on a workstation or shared server
- A GPU server stood up for a pilot and never locked down
- An MCP server connecting a local model to internal tools
- A LiteLLM or other proxy sitting in front of several models
- Compressed community models downloaded from public model hubs
- Open WebUI, Gradio, or another front end placed in front of a local model
What We Test
From Model File to Endpoint
Discovery and Exposure
Every model server, proxy, MCP server, chat front end, and admin dashboard in scope, internal and internet-facing, and who can reach each one. Many ship with no login.
Model Servers and Proxies
Ollama, vLLM, llama.cpp, SGLang, Triton, LiteLLM, and other OpenAI-compatible endpoints, checked for known vulnerabilities, unsafe defaults, and endpoints that load models or run code.
MCP Servers and AI Apps
MCP servers, LangServe chains, Gradio and ComfyUI apps, and other tools wired to your models, tested for open access and code execution.
Model Files and Supply Chain
Where each model came from, whether it’s pinned to a verified version, and whether its files or chat templates can run code when they load.
GPU, Host, and Cache Isolation
Shared GPUs, containers, hosts, and prompt caches, tested for whether one workload or user can reach another’s models, prompts, or memory.
Model Theft and Data Leakage
Whether weights, prompts, outputs, logs, or stored keys can be copied out, whether your compute can be run up, and whether you’d notice.
How We Test
Find It. Test It. Confirm It.
Human-led testing, backed by automation, from the first model file to the last endpoint.
Scope and Threat Model
Define the models, servers, workstations, networks, and GPU infrastructure in scope, and the attackers most likely to go after them.
Discover and Fingerprint
Find every model server, proxy, MCP server, and AI endpoint in scope, including installs nobody mentioned, identify what each one runs, and trace where each model came from.
Test and Validate
Test exposure, model files, server software, caching, and isolation for known and system-specific weaknesses, then confirm what an attacker could reach, steal, or change.
Walk Through and Fix
Walk your team through root causes and ranked fixes, then retest once fixes are in, when retesting is in scope.
Key Outcomes
Keep Local AI In-House
Find Every Local Model
See every model, model server, and AI endpoint on your network, including the ones set up without IT.
Close the Open Doors
Shut exposed servers, admin interfaces, and dashboards before someone else finds them.
Trust the Files You Run
Know where each model came from, and whether its files are safe to load.
Keep Prompts and Data Private
Confirm that prompts, outputs, and client data stay with the people meant to see them.
Deliverables
Findings From Model File to Endpoint
Inventory and Exposure Map
Every self-hosted model, server, and endpoint we found, what it runs, and who can reach it, because you can’t protect what you don’t know is running.
Validated Technical Findings
Unsafe model files, unverified sources, and server flaws, each with reproduction steps, severity, and what an attacker could do with it, tagged to OWASP and MITRE ATLAS.
Root Causes and Prioritized Remediation
Fixes ranked by the risk they remove, because not every finding carries the same weight.
Findings Walkthrough and Retesting
A walkthrough with the team that runs your models, plus retesting once fixes are in when it’s in scope, because a finding only matters once it’s closed.
Common Questions
Self-Hosted AI Security Explained
What does a self-hosted AI security assessment cover?
Everything between the model file you downloaded and the people using it: model servers and proxies, MCP servers and AI apps, where each model came from and whether its files are safe to load, caching and GPU isolation, network exposure, and how prompts, logs, and keys are protected.
Isn’t local AI private by default?
It keeps data off a provider’s servers, but that’s only half the job. Many local AI tools have no login of their own, and one setting can put them on the network. Once that happens, anyone who finds the server may be able to use it, copy its models, or read what passes through it.
Will you find AI servers we don’t know about?
Within the networks and address ranges you put in scope, yes. Installs nobody mentioned are one of the most common things we find.
We only run a model on one workstation. Is that worth testing?
Often, yes. A single workstation running Ollama or LM Studio can still be reachable from the rest of the network, and the models on it came from somewhere. A small setup simply means a smaller scope.
Everything we use runs through a hosted provider. Do we need this?
Usually not. If no models run on hardware you control, AI Penetration Testing is the better fit. Running a mix of hosted and self-hosted models? We can pair the two engagements.
Can you combine this with AI penetration testing?
Yes. Pairing it with AI Penetration Testing puts the application, its agents, and the models and servers underneath it in scope together.
Will you assess model safety, bias, or performance?
No. The assessment targets security: how your models and the systems around them can be attacked. Model capabilities, fairness, bias, and speed or cost tuning fall outside it.
Your Move
Lock Down What You Host
List the models you run and where they’re deployed. We’ll shape an assessment that runs from model file to endpoint.