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:

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

Securing LLM dependencies against serialisation attacks

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 

) that incorporates speaker embedding models.

” on Hugging Face, we get a very different picture of the projects that excite AI software engineers. Aside from the obvious lack of correlation between the superfluous “likes” metrics and actual downloads, there’s another interesting difference in 

 assigned to those LLM models. Different open-source and proprietary licenses impose varying legal requirements. Dataset licenses may restrict usage, distribution, or commercialisation.

Modern AI development is navigating a complex spectrum of licensing, primarily split between "

) software. Models like Meta’s Llama 3.1 and Google’s Gemma utilise custom licenses that, while accessible, impose significant restrictions, such as user-capacity caps, prohibitions on training competing models, or specific redistribution requirements. Similarly, the OpenRAIL++ license used by Stable Diffusion XL permits commercial use but legally binds developers to strict "Responsible AI" terms, prohibiting use cases like medical advice or deceptive content. These models offer transparency and accessibility without granting the full legal freedom found in traditional open-source ecosystems.

In contrast, models like DeepSeek’s R1 and OpenAI’s Whisper employ highly permissive licenses such as 

 which are the gold standard for commercial flexibility. The MIT license is concise and allows for modification and monetisation with almost no strings attached, while the Apache 2.0 license provides similar freedoms but adds robust legal protections regarding patents and trademarks.

 enables enterprises to govern ML models and datasets by enforcing strict policies. This ensures that only models with approved, compliant licenses enter the production pipeline, safeguarding your operations teams from the legal risks associated with restrictive or non-commercial terms. While the ease of downloading models from Hugging Face fuels rapid innovation, building a resilient enterprise on these foundations requires rigorous governance. Cloudsmith provides the control and oversight necessary to turn experimental AI into a secure, commercially viable reality.

Top 10 most popular LLM models on Hugging Face

A single typo is all it takes. A simple oversight and your whole application is handing out 404 errors like an episode of Oprah’s favorite things.

Bad actors leverage typos to introduce malicious code into the software supply chain. Once these packages get into your supply chain they can create a lot of damage. And it’s not just end users unable to access your application. We’re talking PR nightmares, data leaks, security threats, and all sorts of disruptive events. Having a central security and control plane for your software supply chain helps to identify and mitigate threats from typosquatting and other malicious software.

This post discusses typosquatting and how using an artifact manager can significantly mitigate these threats. We’ll look at some best practices for dealing with typosquatting and some Cloudsmith features that help you create a proactive security posture that doesn’t interfere with developer velocity.

: Typosquatting & Slopsquatting: Detecting and defending against malicious packages – Watch on-demand 

Slopsquatting and Typosquatting: How to Detect AI-Hallucinated Malicious Packages

To level set things, let’s define typosquatting. If you’re already familiar with the term feel free to skip to the next section.

 is a form of cyberattack where bad actors create packages that contain malicious code. They give these packages names that are similar to, or slight variations of known, trusted packages. They’re banking on developers making typing mistakes and not noticing them, essentially tricking devs into pulling these packages into their production environments where they can do damage.

These bad actors understand that speed in development is a driving force. This is especially true as developers experiment with new tools and technologies. It’s common for developers to see if a solution works first, then go back and think about security later. As a result, security struggles to keep up with the overall pace of development. It’s in this gap where typosquatting is at its most threatening.

Because anyone can upload packages to public open source registries (we’re talking about places like npm, PyPI, Maven Central, and the like), bad actors have ready access to distribution platforms for their malicious packages. Maintainers of these public registries may not have the time or authority to remove malicious packages. Plus, bad actors can upload packages faster than maintainers can address them.

That means the end user takes on the security burden by default. Developers benefit from an artifact manager to act as a firewall between public registries and their development environments. An artifact manager, like Cloudsmith, functions as a control plane for the entire software supply chain.

An artifact manager determines what enters, moves through, and leaves the software supply chain. It proxies packages from public registries and caches them in a private registry. Setting that private repo as the default location for package pulls ensures consistency across a development team and/or organization. It creates a private repository of known, trusted, and secure artifacts.

Why does all this matter for typosquatting? When developers default to public registries and pull directly from them for all their builds, they introduce the risks of typos or mistakes that could pull a typosquatted package into their environment. Pulling from a private repo in an artifact manager ensures you pull the same package every time.

Simply having a private repo does not make your packages secure. This is where security policies come into play.

The first time you push a package of any kind to Cloudsmith, the platform scans for malware. 

 have access to additional security features that detect package vulnerabilities and malicious packages. This includes scanning packages against trusted third-party databases, e.g., Open Source Vulnerability (

, which tell you what, if any, vulnerabilities exist for each package. It also uses Common Vulnerability Scoring System (

), and Exploit Prediction Scoring System (

) to score those threats and provide information about the severity impact of those vulnerabilities.

You can use this information to create your own policies that suit your security needs. For example, you may want to quarantine some packages. Others you may want to tag. You can build automations using these actions and policies to support a scalable security posture. Learn more about the current EPM actions 

Regarding typosquatting, qualified plans provide you baseline package health information before you ever create a security policy. A baseline understanding is not the same thing as proactive prevention, so let's take a look at how to begin addressing typosquatting from a policy perspective.

Creating a proactive anti-malware posture

Detection is only as effective as the policy that supports it. To secure the software supply chain without slowing down engineering, organizations need more than just scans. They need systemic governance.

 (EPM) lets you define, interpret, and take action on identified security threats. This translates into the implementation of transparent, automated, and scalable standards that protect the build process while remaining invisible to the developer. What does this look like in practice? Let’s look at a couple different options.

Teams and Access Controls

More articles

LLMs on Kubernetes: same cluster, different threat model

Securing LLM dependencies against serialisation attacks

Top 10 most popular LLM models on Hugging Face

Protect your software supply chain from typosquatting with Cloudsmith

Securing AI-generated code with Cloudsmith

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