By submitting this form, you agree to our 

Let’s say you’ve got an LLM running on Kubernetes. Pods are healthy, logs are clean, users are chatting. Everything looks fine.

But here's the thing: Kubernetes is great at scheduling workloads and keeping them isolated. It has no idea what those workloads do. And an LLM isn't just compute, it's a system that takes untrusted input and decides what to do with it.

That's a different threat model. And it needs controls Kubernetes doesn't provide.

Understanding what you're actually running

Let's walk through a typical deployment. You deploy 

, a server for hosting and running LLM models locally, in a pod. You expose it via a Service, point 

 (a chat interface similar to ChatGPT's UI) at it. Users type prompts, answers appear. From Kubernetes' perspective, everything looks healthy: pods are running, logs are clean, resource usage is stable.

But consider what you've built. You've placed a programmable system in front of your internal services, tools, logs, and potentially credentials. Kubernetes did its job perfectly, scheduling and isolating the workload. What it can't do is understand whether a prompt should be allowed, whether a response contains sensitive data, or whether the model should have access to certain tools.

This is similar to how API security works. The infrastructure handles routing and isolation, but you still need authentication, authorization, and input validation. Those concerns live at the application layer.

OWASP LLM top 10: a framework for understanding risks

 maintains a list of the top 10 security risks for web applications. It's become the standard checklist for "things that will get you hacked if you ignore them." They've now done the same thing for LLMs: 

the OWASP Top 10 for Large Language Model Applications

This framework catalogs the most critical security risks when building LLM-powered systems, including:

LLM01: Prompt Injection (manipulating model behavior through crafted inputs)

LLM02: Sensitive Information Disclosure (models leaking training data or secrets)

LLM03: Supply Chain (using unverified models or data)

LLM04: Data and Model Poisoning (compromising model behavior through malicious training data)

LLM05: Improper Output Handling (treating generated content as trusted)

LLM06: Excessive Agency (models with too much autonomy)

LLM07: System Prompt Leakage (exposing system instructions)

LLM08: Vector and Embedding Weaknesses (vulnerabilities in RAG and embedding systems)

LLM09: Misinformation (models generating false or misleading content)

LLM10: Unbounded Consumption (resource exhaustion attacks)

Addressing all of these requires defense in depth across your entire stack. This post focuses on four risks that are particularly relevant when running LLMs on Kubernetes:

 can be addressed through policy controls at the application layer, patterns that map to things you already do for APIs.

 requires governance at deployment time, treating models with the same rigor you apply to container images.

Each one connects to infrastructure patterns you're probably already familiar with, just applied to a probabilistic system.

1. Input validation (Prompt Injection - LLM01)

In most setups, this works. LLMs have a "system prompt" that sets their behavior and constraints, but many models treat user input as higher priority than these system instructions. This is prompt injection, the LLM equivalent of SQL injection or command injection. User input crosses a trust boundary and influences behavior in unintended ways.

The operational question is the same one you answer everywhere else: does untrusted input get to control program flow? With APIs, you validate inputs against a schema. With LLMs, you need similar controls, but the validation logic is different because the input is natural language and the behavior is probabilistic.

Let's look at three more patterns, then we'll explore how to actually implement these controls in your cluster.

2. Output filtering (Sensitive Information Disclosure - LLM02)

Here's a subtler failure mode. A user asks: "Show me an example configuration file."

The model didn't crash. It just leaked credentials. Why? Models memorize things from training data. Or someone put secrets in the system prompt. Or the model is pulling from internal docs that contain credentials. It doesn't know these are secrets. It's just generating plausible text.

This is the same class of bug as accidentally logging environment variables, except the content is generated rather than passed through. You need output filtering for the same reason you scrub secrets from logs.

With containers, you worry about pulling compromised images from untrusted registries. With LLMs, the risks are similar but harder to spot.

Models are binary blobs. You can't inspect them the way you can read source code. A model downloaded from Hugging Face could have backdoors, hidden biases, or behaviors that only trigger in specific contexts. Someone could fine-tune a popular model to bypass safety features, score well on benchmarks, and publish it for others to use. You'd have no idea until something goes wrong.

There's also version drift. llama3.2:latest today might behave differently than llama3.2:latest next month. If you're not pinning versions, you're not in control of what's running.

This isn't something a gateway can solve. Supply chain security happens at deployment time: where did this model come from? Who published it? Can you verify it hasn't been tampered with? You need the same governance you apply to container images, versioning, provenance, access controls, audit trails.

We'll come back to this when we talk about artifact management with Cloudsmith.

4. Tool permissions (Excessive Agency - LLM06)

Modern LLMs can be given access to "tools" or "functions", essentially APIs they can call to perform actions like querying databases, sending emails, or executing code. When you give a model access to these capabilities, you're granting it the ability to perform operations:

execute_sql

This is why controllers don't get cluster-admin by default. The principle is identical. The difference is that the entity making authorization decisions is probabilistic rather than deterministic. You need the same kind of least-privilege thinking, but applied to a model's tool access.

Notice something about these patterns. None of them belong in the model runtime itself.

Ollama's job is to load models and generate responses efficiently. It shouldn't also be deciding whether a prompt is safe, whether output contains secrets, or whether a tool should be allowed. That's a separation of concerns issue: mixing inference with policy makes both harder to reason about and harder to change.

What you need is something in front of the model that handles policy. It forwards requests, but it also enforces rules. Think of it as similar to an API gateway, but with awareness of LLM-specific patterns. It understands prompts, tool calls, and generated content, not just HTTP semantics.

If you're using managed AI services like ChatGPT, Claude, or most AI agent platforms, these controls are handled for you. The provider manages prompt filtering, content moderation, and rate limiting. You trade control for convenience.

When you run models in your own cluster, you need to build or adopt a policy layer. Several options exist:

 is a popular open-source gateway that provides a unified OpenAI-compatible API across 100+ models, with features like rate limiting and cost tracking

 brings LLM traffic management into Kong's mature API management platform

 offers caching, observability, and cost controls as a drop-in proxy

 (formerly Gloo) implements the Kubernetes Gateway API with AI-specific extensions

These are solid options, especially if you need multi-provider routing or are already using their ecosystems. But they're also general-purpose tools that may be more than you need, or may not cover the specific OWASP LLM controls we've discussed.

For this post, we're building a minimal reference implementation focused specifically on those security patterns: prompt injection detection, output filtering, model allowlists, and tool restrictions. It's not a product, it's a learning tool you can understand completely, then adapt or replace with something more robust when you need to.

The challenges of running LLMs in Kubernetes

If you've worked with Kubernetes for a while, you've developed workflows for testing, deploying, and governing your services. LLMs break some of those assumptions.

You can't run the full stack locally anymore.

 A 7B parameter model needs significant GPU resources. A 70B model needs multiple GPUs. Your laptop isn't going to cut it, and even local Kubernetes clusters struggle. But your gateway, your policies, your application code - that still needs fast iteration. You need a way to develop and test the components that 

 to the LLM without running the LLM locally.

 You've got container registries, Helm charts, maybe some ML model registries. But LLM models are different: they're large (gigabytes to hundreds of gigabytes), they're versioned differently, and they determine your application's behavior as much as your code does. Where do they live? How do you version them? How do you ensure the model running in production is the one you tested?

Security policies need tuning against real behavior.

 You can't write a prompt injection detection pattern in isolation and trust it works. You need to see how it handles real prompts, edge cases, false positives. That means testing against actual traffic patterns, which traditionally means deploying to a cluster and waiting.

These aren't hypothetical problems. They're what you hit the first time you try to build something serious with LLMs on Kubernetes.

For this walkthrough, we'll use two tools that address these challenges:

 connects your locally running process to a target in your configured cluster. Your local code talks to the real Ollama instance running in the remote cluster, receives real traffic, resolves cluster DNS. You get real environment testing without needing local GPU resources or waiting for deployments.

 provides universal artifact management. Store your gateway images and model files in the same registry, with versioning, access controls, and audit trails. Treat models with the same governance rigor you apply to containers.

Let's see how these fit into the workflow.

An LLM gateway provides a single location to enforce policy:

Which models are allowed to run, which prompts look suspicious, which tools can be called, what gets logged, what gets redacted, what never leaves the cluster.

For this post, we've built a working example gateway you can deploy and experiment with. It's not a production-ready product, it's a learning tool that demonstrates the patterns and gives you a starting point to build from.

The gateway acts as a reverse proxy with LLM-aware middleware. Requests pass through policy checks before reaching the model. Responses pass through output filters before reaching users.

From an operational perspective, this gives you:

 Log policy violations without blocking requests. Useful for understanding what's happening before enforcing rules.

 Block requests that violate policy. Useful once you understand your traffic patterns and trust your rules.

 Start in monitor mode, tune policies based on real traffic, switch to enforce mode when ready. This is the same pattern you use for validating NetworkPolicies or RBAC rules before enforcement.

​​Security policies need tuning against real behavior. A prompt injection pattern that's too aggressive blocks legitimate requests. Too loose, and it misses attacks. You find out which you have by testing.

The obvious approach: run a small model locally, point your gateway at it, iterate. That works for basic functionality testing, but it has gaps:

 A prompt injection that works on llama3.2:1b might not work on llama3.2:70b. Output filtering tuned against one model's response patterns might miss secrets when a different model phrases things differently. If your production model isn't what you tested against, your policies have blind spots.

 You write test prompts you think of. Real users send things you'd never imagine. Testing against actual traffic patterns catches issues synthetic tests miss.

 It might need to resolve cluster DNS, talk to auth services, or access ConfigMaps. Those dependencies don't exist on your laptop.

What you want is your local code running against the real cluster environment: real model, real traffic, real services. But without the 10-15 minute deploy cycle every time you change a config file.

That's what mirrord does. It lets you run your local process in the context of your cluster. When you start your process with mirrord, it creates a temporary agent pod that listens in on your target pod, overriding your local process's syscalls and proxying them to the cluster. Your local gateway talks to the real Ollama instance, receives real traffic, resolves cluster DNS. You edit a file, restart, and test in seconds.

Here's the approach we'll use. The gateway runs in your cluster as normal, but during development, with mirrord you run a local copy that intercepts traffic from the cluster. Your local process talks to real cluster services (Ollama, internal DNS, everything), but you can change configuration and restart in seconds.

Clone the repository and deploy the infrastructure:

LLMs on Kubernetes: same cluster, different threat model

 hosted on Hugging Face. While this democratisation of AI is changing how all work and develop with AI, it also introduces a massive supply chain risk. Every time a developer runs 

, they are essentially pulling an opaque blob of data from a public registry.

The core of the issue? We often don't know the provenance of these models, their true licensing constraints, or (most importantly) what code is tucked inside their weight files.

What is a Pickle and why is it dangerous?

 is the standard way to serialise object structures into binary. In machine learning, it is the default format for 

However, the Pickle protocol is not just a data format; it is a stack-based virtual machine. When you 

 a file, you aren't just reading data, you’re also executing a sequence of instructions (

Pickle was never designed to be secure against erroneous or maliciously constructed data. A malicious actor can craft a pickle file that, when opened, executes arbitrary code on your machine, like opening a reverse shell or exfiltrating environment variables.

You can see this in action using open-source tools like 

. By scanning a known dummy malicious model (

), we can see exactly where the trap was set.

Again, this is a dummy model. It’s not actually malicious. To my knowledge it doesn’t do anything. This is purely to demonstrate what a picklescan is looking for:

 during the load process, which executes the arbitrary code. This is the smoking gun of a serialisation attack. 

The scanner can also load Pickles from local files, directories, URLs, and zip archives.

For the purpose of demonstration, let’s scan the 

sshleifer/tiny-distilbert-base-cased-distilled-squad

Preventing model serialisation attacks with Modelscan

As discussed above, ML models are shared publicly over the internet, within and across teams. The rise of Foundation Models resulted in increasing consumption and further training/fine tuning of public ML models. Because developers use ML models to make critical decisions and power mission-critical applications, it makes sense that there would be more than one open-source scanning option, especially when vulnerabilities can appear in other scanners such as 

 that scans models to determine if they contain unsafe code. It is the first model scanning tool to support multiple model formats. ModelScan currently supports: 

Scanning the entire local Hugging Face cache on my Macbook with Modelscan showed nothing suspicious when I scanned the original 

’s Totally Harmless Model we downloaded earlier.

Then run the below commands to create the model and scan it with Modelscan:

The above Python script provides a classic example of why pickling is dangerous and why tools like 

, you tell Python exactly how to reconstruct the object when it's loaded. By putting 

 inside that method, you turn a simple data file into an executable script.

Once you point Modelscan at the correct filename, it should successfully flag 

When you’re done, you can clean up all the newly-created files with the below command:

To secure your AI pipeline, you should adopt a defence-in-depth strategy:

 format, which is designed to be zero-copy and, crucially, non-executable. This is the ideal starting point.

: Because some models force us to use file formats considered “less safe” than safetensors, we should only load models from trusted organisations, where possible. For example, I trust Nvidia or Google more than random publishers on the internet.

Automated protection with Cloudsmith’s Rego policies

Manually scanning every model isn't scalable. This is where Cloudsmith comes in. In a 

, we explained how to use Cloudsmith as your private proxy for AI models, and how to enforce Hugging Face policies in Enterprise Policy Manager (EPM) to automatically block potentially infected or unsafe models before they ever reach a developer's machine.

Example 1: Blocking based on scan results

The nice thing for Hugging Face users is that Hugging Face Hub already performs 

 on all LLM Models. It then flags a model as safe or not. This Cloudsmith 

 policy rejects ingesting any model Hugging Face’s internal security scan did not mark as "SAFE".

But as discussed earlier, we can run standalone picklescan almost anywhere to scan for files deemed insecure and verify those results against the existing Cloudsmith scans. However, it might be worth considering a more restrictive approach to the risky file formats that we accept into production.

Example 2: Reducing the potential attack surface by extension

If your LLMOps and security teams have standardised on the 

 format, you can explicitly block legacy or high-risk formats. This reduces the overall attack surface by preventing the entry of formats known to support execution (like 

Like a funhouse mirror, securing AL models isn’t always what it seems. Securing generative AI is about more than just protecting the code – it’s about protecting the data that behaves like code. By utilising flexible Rego policies within Cloudsmith, you move from a reactive posture (scanning after the fact) to a proactive one (blocking by policy).

Check out our upcoming webinar with great insights about Hugging Face and evolving AI threats:

Want a broader framework for protecting AI artifacts and model supply chains? Explore our 

securing non-deterministic systems in LLMOps

Nigel Douglas

Head of Developer Relations

Secure LLM models

Securing LLM dependencies against serialisation attacks

 know your LLM-generated code? LLM-powered copilots now write a lot of code, and they tend to suggest new dependencies your organization may not have used before. Without systematic security checks, you’re at risk of a hallucination exposing your production systems to a supply chain attack. Our increased reliance on open source and other third-party code increases risk to your builds. AI-generated code exacerbates those risks.

Let’s talk about how Cloudsmith secures your AI-generated code. By leveraging policy-as-code, private repo caching, and other best practices, Cloudsmith helps software development teams adopt a “verify and then trust” architecture, balancing AI-assisted software development with the need to defend system integrity.

Stop LLM hallucinations from breaking your build

LLMs are a great example of an untrusted contributor. They generate code without a complete understanding of your internal security standards. Their code may reference non-existent packages in a phenomenon known as AI hallucinations, and they may pull in malicious dependencies, created via a new attack vector dubbed slopsquatting. Cloudsmith’s 

 revealed that 79% of professionals believe that AI will exacerbate open-source malware threats, including typosquatting and dependency confusion.

The traditional "trust, then verify" model is no longer viable, because there is no true human intent behind an LLM’s package selection. Only 67% of developers review AI-generated code before every single deployment, per the 2025 report. To ship AI-generated code safely, we recommend moving to a "verify, then trust" architecture. This means treating every AI-suggested dependency as a potential threat until it passes a programmable gate.

Cloudsmith acts as that gate. By sitting between your LLM-powered copilots and your package ecosystem, we provide the metadata layer and policy enforcement needed to ensure that AI-generated code only utilizes verified, licensed dependencies within your private, controlled repositories.

Here is how you use Cloudsmith to stop AI-induced challenges at the front door.

The role of programmable security policies

What does “good” software supply chain security look like? It should do a few things:

Builds pull packages from trusted sources.

Scan new dependencies for malware and other vulnerabilities.

Automate blocking vulnerable packages from production environments.

Check package license(s) before it enters a build.

Continuous and systematic performance of these tasks at scale for end-to-end protection.

When you introduce AI into the equation, these tasks become more important. Implementing automated security processes and policies is the best way to make sure they happen.

The tradeoff between power and simplicity is one developers often face. “Checkbox security” is simple and straightforward, but it has its limits. You set policies via UI, using checkboxes, radio buttons, and other basic interface elements. These security interfaces are easy to understand, but they’re static and are not fully customizable to the user, organization, or project. Limited options and functionality mean that checkbox security doesn’t scale for enterprise-level development. It’s hard to do things like apply unique or fine-grained security policies to different projects, teams, environments, formats, and contexts.

Contrast that with policy-as-code where you get granular control over security policies, which is an inherently more scalable approach. 

 (OPA) is an industry standard for policy-as-code. It pairs with the Rego language to define rules for software usage and consumption. While Rego introduces a learning curve, OPA’s benefits are an enterprise-level industry standard.

 acts as an OPA engine so you can use the same 

 you may already be familiar with to create policy-as-code controls in Cloudsmith. You use Rego to create universal, baseline policies for every artifact in your Cloudsmith repos.

With EPM and Rego, you can create custom rules for specific repos, projects, or applications that cater to fine-grained security needs. EPM policies can evaluate SBOM data to ensure end-to-end consistency throughout your data pipeline. Our 

 highlights some of the different approaches to building policies, and serves as a great starting point for creating your own. We also developed the 

 for EPM, you can enforce an organization-wide requirement for a package with a specific version range. The policy evaluates the version of a package against a specified package version. It then triggers an action, like quarantining the package, if the version of the current package being evaluated is older than the specified package version.

Cloudsmith functions as a central source of truth for all your development packages and artifacts. From a security perspective, it functions as a gatekeeper, blocking or quarantining malicious, vulnerable, or non-compliant packages, in accordance with your policies, before they enter your build systems. When you pull packages, you always pull them from Cloudsmith, which makes sure they meet your security requirements.

Are you looking for a complete strategy to protect AI-driven development workflows? Read our practical guide to

securing AI artifacts and operationalizing LLMOps

Jason Myers

Technical Content Marketer

Securing AI-generated code with Cloudsmith

Hugging Face has evolved from a repository for niche research into the definitive backbone of the global AI ecosystem. Often described as the "GitHub of Machine Learning", it serves as a central hub where the boundary between research and industry vanishes. By providing a unified platform for open-source 

), Hugging Face democratises access to state-of-the-art Natural Language Processing (NLP), Computer Vision, and Multimodal AI.

Determining the "top" models in such a vast ecosystem is complex, as "likes", trending status, or sheer download volume can measure popularity. However, as we start February 2026, download counts remain the most reliable metric for real-world utility. They represent models being actively integrated into production pipelines, automated workflows, and enterprise applications.

 (January 2026), exploring their unique architectures and the specific business value they provide in today's AI-driven economy.


This LLM model acts as a digital translator that converts text into a compact list of 384 numbers called an 

. By representing sentences as coordinates in a multi-dimensional space, it allows computers to "calculate" meaning. Sentences with similar topics are placed close together, while unrelated ones are far apart. Trained on over a billion sentence pairs to excel at 

, it effectively finds the intent behind a query rather than just matching keywords.

) specialised for content moderation, specifically designed to distinguish between "normal" and "Not Safe For Work" (NSFW) images. Built upon the 

 architecture, it leverages a transformer encoder to process images as sequences of patches. It was fine-tuned on a proprietary dataset of 80,000 diverse images. The final model achieves a high evaluation accuracy of 98%, making it a robust tool for automated safety filtering and explicit content detection in digital applications.

 is a highly efficient pre-training method for transformer networks that replaces the traditional "Masked Language Modeling" (

. Instead of masking words and asking the model to predict the missing pieces, ELECTRA uses a small "generator" network to swap certain words with plausible alternatives. The main "discriminator" model then learns to identify which tokens are original and which are "fake." This approach is significantly more compute-efficient because the model learns from every single token in the input, rather than just the small percentage that are typically masked, allowing for state-of-the-art performance even on limited hardware.


The Fairface age image detection model is another example of a vision transformer designed to classify individuals into nine distinct age groups from images. Built using the 

 dataset and licensed under Apache-2.0, the model achieves an overall accuracy of approximately 59%. Performance varies significantly across demographics. It is most effective at identifying young children (0–9 years), where F1-scores reach nearly 80%, but struggles with older age brackets, particularly the "more than 70" category, which shows a low recall of 18%.

 base uncased is a bidirectional transformer model pre-trained on a massive corpus of English books and Wikipedia articles using self-supervised learning. Unlike models that read text left-to-right, BERT also uses MLM to predict hidden words and Next Sentence Prediction (

) to understand relationships between sentences, allowing it to capture deep contextual meaning. While it can be used for basic tasks like filling in the blanks, it is primarily designed to be fine-tuned for specific downstream applications such as text classification, sentiment analysis, and question answering. As an "uncased" model, it treats uppercase and lowercase letters identically and ignores accent marks, though it may reflect social biases present in its original training data.


MobileNet is an efficient image classification model and feature backbone designed for mobile and edge devices. This specific version was trained on the ImageNet-1k dataset using the 

 and an exponential decay learning rate schedule. With only 2.5 million parameters and 0.1 GMACs, it offers a highly compact architecture optimised for low-latency performance while maintaining accuracy through advanced training techniques like EMA weight averaging and a 224x224 input resolution.

7. Paraphrase Multilingual MiniLM L12 (v2)

sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2


The is a great example of a versatile sentence-transformer model designed to map multilingual text into a 

 with a 128-token sequence limit, it utilises a 

 strategy to convert contextualised word embeddings into fixed-size sentence embeddings. This makes it highly effective for downstream 

 tasks such as semantic search, clustering, and paraphrase detection. While it can be implemented using the standard HuggingFace 

 library with manual pooling, it is optimised for seamless use with the 


This is also a sentence transformers model and was designed to produce 

 for tasks like semantic search and information retrieval. Fine-tuned from 

, it uses a self-supervised contrastive learning objective to maximise semantic accuracy. Unlike the previously mentioned Multilingual MiniLM L12 model, this version includes an additional 

 for its embeddings and is specifically optimised for high-quality English sentence representations. While it supports standard library implementations, it is also compatible with 

 for high-speed, production-grade deployment.


 if you need to support multiple languages or if you are running on limited hardware (CPU) and need the fastest possible inference.

 if you are working exclusively with English and need the highest possible accuracy for search results or clustering.


RoBERTa (Robustly Optimised BERT Approach) is a large-scale transformer model pretrained on 160GB of English text using a 

 MLM objective. By masking 15% of tokens and challenging the model to predict them, RoBERTa develops a deep, bidirectional understanding of language that is highly effective for downstream tasks like text classification and question answering. While it inherits societal biases present in its internet-based training data, its "large" architecture and case-sensitive nature make it a powerful tool for extracting complex linguistic features.


This is an example of a speaker segmentation model designed to process 10-second mono audio chunks sampled at 16kHz. Utilising a "powerset" multi-class encoding, it identifies up to three distinct speakers and specifically detects overlapped speech by classifying frames into seven categories (including non-speech and specific speaker combinations). While it is highly effective for tasks like Voice Activity Detection (

) and overlapped speech detection, it is intended as a building block rather than a standalone solution. For full-length recording diarisation, it must be integrated into a larger pipeline (such as 

Cloudsmith Blog

LLMs on Kubernetes: same cluster, different threat model

Securing LLM dependencies against serialisation attacks

Securing AI-generated code with Cloudsmith

Top 10 most popular LLM models on Hugging Face

Protect your software supply chain from typosquatting with Cloudsmith

From ingredient list to control point: SBOM-based component-level security

7 key metrics to measure software supply chain security

How artifact management enables S2C2F maturity

The 8 core principles of S2C2F

Understanding S2C2F: How it strengthens OSS security

What is software supply chain integrity?

Extend EPM policies to Hugging Face artifacts