Security of Self-Hosted LLMs: On-Premise Doesn't Mean Safe by Default

Companies are moving AI workloads on-premise for good reasons: data residency, GDPR and SOC 2 compliance, and cost control at scale. Running an open-weight model inside your own perimeter means prompts and fine-tuned weights never leave your infrastructure.

But there is a dangerous assumption hiding in that decision: "it runs on our servers, therefore it's secure."

It isn't. Self-hosting removes one risk — a third party seeing your data — and hands you full responsibility for everything a managed API provider was silently absorbing: endpoint security, artifact verification, isolation, and patching. Here is the real attack surface.

175,000 Exposed Inference Servers

In September 2025, Cisco Talos found over 1,100 Ollama instances on the public internet with no authentication. By early 2026, SentinelLABS and Censys scans counted roughly 175,000 publicly reachable Ollama hosts across 130 countries, plus unprotected vLLM and LiteLLM endpoints.

The root cause: popular self-hosting tools were designed for developer convenience. Ollama's REST API ships with no built-in authentication at all. One 0.0.0.0 bind or a permissive cloud security group, and the entire API is open. Attackers actively scan for these — documented "LLMjacking" operations find open instances and resell access on underground marketplaces.

An open endpoint gives an attacker free GPU compute, the ability to pull your fine-tuned models (which are your data), visibility into system prompts and RAG configs, and a network foothold inside your perimeter.

CVEs in the Inference Stack

The serving layer is young software, built for performance first. The track record:

• Probllama (2024) — remote code execution in Ollama
• CVE-2025-47277 — vLLM's distributed inference layer called pickle.loads() on data from a network socket: textbook RCE
• Bleeding Llama, CVE-2026-7482 — three unauthenticated API calls leaked system prompts, sessions, API keys, and DB credentials from Ollama. The patch existed for months before the CVE was assigned — scanners and compliance tooling were blind the whole time

The lesson: an inference server is a production network service and needs the same patch discipline as your database. Track upstream releases directly — CVE feeds alone will fail you.

There's also a uniquely AI-shaped risk: serving engines batch requests into shared GPU memory pools and KV caches. A compromised process can leak fragments of other users' conversations, and privileged GPU drivers put a compromised container one step from the host.

Model Weights Are Executable Artifacts

Teams apply supply-chain security to code but pull model weights from public hubs without verification. Two failure modes:

Malicious serialization. Pickle-based model formats can execute arbitrary code at load time. In 2026 there is no reason to load anything but safetensors in production.

Model poisoning. Weights that benchmark normally but are fine-tuned to leak data or follow hidden instructions under specific conditions. No crash, no log entry.

The fix is classic supply-chain hygiene: trusted sources only, artifacts pinned to verified hashes, model signatures where available, and fine-tuned internal models treated as crown-jewel IP.

Prompt Injection Doesn't Care Where the Model Runs

Malicious instructions embedded in documents, emails, or web pages work identically against self-hosted and cloud models. And self-hosting often makes it worse: open-weight models have weaker safety training, teams disable guardrails "because it's internal," and the on-premise model typically has more privileged access — databases, internal APIs, filesystem tools — than a cloud model ever would.

The OWASP Top 10 for LLM Applications is the right framework. The essentials: least-privilege tool access, treating model output as untrusted input, sandboxed code execution, and egress filtering on inference workers.

Hardening Baseline

The minimum bar for production:

• Network: bind to localhost or private subnets; all access through an authenticated reverse proxy or LLM gateway; egress filtering by default
• Platform: non-root containers, minimal capabilities, patching that tracks upstream releases
• Artifacts: safetensors only, hash-pinned, access-controlled storage for fine-tuned weights
• Application: OWASP LLM Top 10 review, output validation, full inference logging into your SIEM

None of this is exotic — it's the discipline you already apply to databases, extended to a new workload most teams currently deploy with the security posture of a weekend side project.

Conclusion

"On-premise" is a data-residency property, not a security property. The 175,000 exposed inference servers aren't a tooling failure — they're a mindset failure: AI infrastructure deployed like a desktop app when it needed to be treated like a production database.

At NextVector, we build backend and blockchain infrastructure where security is a design constraint, not an afterthought — and the same discipline applies directly to AI. Planning an on-premise AI deployment? Get in touch.