Your Kubernetes security playbook was written for stateless services. LLMs are different in every way that matters for security, and deploying them in the same cluster without updating your threat model is how production incidents happen.   
  
**What changes when you run LLMs on K8s:**   
❌ You can't run the full stack locally anymore; a 7B parameter model requires significant GPU resources   
❌ Standard container scanning doesn't cover model weights   
❌ Your existing RBAC policies weren't designed for workloads that execute arbitrary text at inference time   
❌ Output validation doesn't work the same way it does for deterministic APIs   
  
**The OWASP Top 10 for LLMs applied to Ollama on Kubernetes:**   
→ Prompt injection: user input reaches the model with cluster-level tool access   
→ Model denial of service: unbounded inference requests exhaust GPU resources   
→ Training data poisoning: models fine-tuned on compromised datasets in shared pipelines   
→ Insecure output handling: LLM outputs piped to shell commands, SQL, or downstream APIs without sanitization   
→ Supply chain vulnerabilities: models pulled from public Hugging Face mirrors with no integrity verification   
  
Reference implementation walkthrough, minimal, fully auditable, built specifically around these controls: [https://cloudsmith.com/blog/llms-on-kubernetes-same-cluster-different-threat-model](https://cloudsmith.com/blog/llms-on-kubernetes-same-cluster-different-threat-model)   
  
What LLM workloads are you running in production clusters? Happy to discuss the specific threat model.

Running LLMs on Kubernetes breaks most of your existing security assumptions. Here's the OWASP Top 10 for LLMs applied to a real Ollama deployment.