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, authorisation, 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 behaviour 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 behaviour 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 behaviour 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 behaviour 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 behaviour 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 memorise 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 behaviours 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 authorisation 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 behaviour 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 behaviour.

 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 behaviour. 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

That’s what I want for Northern Ireland’s software sector. And we are doing it together.

Northern Ireland is a great place to live. Culturally, we are a country of innovators and builders, and it is already a great place to build software. Whether you are starting something new or want to contribute to systems and tools used all over the world, the software industry in NI is well-established.

Yes, we have our challenges as a country, just like anywhere else. But we have an exciting and emerging startup ecosystem, circling venture capital, and we are the software development headquarters for big companies like Aflac, Allstate, and Liberty Mutual. And we finally have an official LEGO store.

I left Northern Ireland two days after graduating from Queen’s University Belfast in 2002, and lived in the United States and then England for a few years. But soon the love of grey skies pulled me back home and into a job at a newly minted startup, albeit one that struggled to find its feet. 

After moving on from my first NI-based startup. I then watched Danny Moore sell Wombat Financial Technologies to the mighty New York Stock Exchange in 2008. This was a signpost of what is possible with great leadership and execution. So when Lee and I founded Cloudsmith, our goal was, and still is, to build a world-class product company headquartered in Belfast.

There are many challenges with building a business, especially in a small country with just under 2 million people. We have great universities in Ulster University and Queen’s (and not forgetting our friends at the Open University), producing a steady stream of graduates; there is a growing talent pool and lots of opportunity for innovation.

Those who have tasted success can inspire, guide, and expand the limits of what is possible.

It's pretty unusual to be more than two degrees of (Kevin Bacon) separation away from anyone from Northern Ireland here. We witnessed firsthand the power of diaspora: Northern Ireland looks out for its own, and we made connections all over the world with folks who left to seek their fortune in faraway lands. Some have been absolutely key to Cloudsmith’s success to date, and it’s always a pleasure to hear the unmistakable accent come back at you over Zoom.

We need more success stories. We need to show the workforce that share options are worth something. We need more exits. We need to create more wealth.

I’ve seen the power of being in a well-funded startup with great, founder-friendly early-stage backers (thank you, Techstart, Frontline, and MMC) that can elevate you to take on the competition.

How do we get more money into Northern Ireland companies? How do we get the light from Sauron’s Eye shining on our little country? OK, that sounds ominous, but I mean it in a good way. How can we position ourselves as a hotbed of innovation and talent, to rival Silicon Valley or Tel Aviv?

That is something we are tackling at Software NI, but we need all the help we can get. 

 is dedicated to making Northern Ireland a global leader in technology and software innovation through community, education, advocacy, and support. Everything from championing software literacy in schools to affecting governmental policies to ensure software is part of our future.

We welcome you to engage with the community at the new 

, organized by Software NI. The inaugural event will take place on Thursday, 26th March, in The Mac. It promises to be an excellent opportunity to listen to industry leaders, including Danny Moore, discuss how they scaled their businesses and created value. I’ll be there too :)

Remember, Northern Ireland is amazing, Cloudsmith is building something great, and Software NI is striving to create an ecosystem where people and software companies of all shapes and sizes can thrive.

I love Software (in) NI

For years, the bottleneck in software was “how fast can we write code?” Today, Generative AI shifts that bottleneck to 

For years, the bottleneck in software was “how fast can we write code?” Today, Generative AI shifts that bottleneck to “how fast can we secure it?”

As organizations move from experimentation to production-grade AI, they are discovering that traditional DevOps tooling wasn’t built for a non-deterministic world. For example, static software composition analysis (SCA) scanners that assume deterministic dependency graphs or CI policy gates that validate known build artifacts. When a model generates code rather than a human, the software supply chain changes overnight.

Securing non-deterministic systems: A practical guide for AI artifacts and LLMOps

, explores three emerging security frontiers that every organization adopting AI must address:

1. AI-generated code introduces supply-chain hallucinations

LLMs generate dependencies probabilistically, not deterministically. This creates the emerging 

 attack vector, where attackers register hallucinated package names suggested by AI tools and weaponize them with malicious payloads.Without validation and artifact governance, a single copied command can silently compromise an enterprise environment.

2. AI models behave like executable software, not passive data

Modern model formats can execute arbitrary code during deserialization, most notably through Python pickle-based loading.This 

 means downloading an unverified model from public registries such as Hugging Face or Ollama can result in full system compromise.Secure AI development requires scanning, signing, and favoring restricted formats like 

, alongside enforcing trusted provenance for every model artifact.

3. AI productivity and orchestration layers expand the attack surface

Frameworks that connect models to enterprise data and automate workflows introduce a new class of high-impact vulnerabilities.Recent RCE exploits in orchestration tools demonstrate that 

LLMOps infrastructure itself is now part of the software supply chain

, and must be sandboxed, authenticated, and governed like any production system.

Our full guide provides a strategic roadmap for navigating the shift from DevOps to LLMOps, deconstructing threats in frameworks like Langflow, and building a “sandbox-by-default” development lifecycle.

AI artifacts: The new software supply chain blind spot

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.

: This is a variation of typosquatting driven by generative AI large language models (LLMs). These LLMs hallucinate package names that sound realistic, but do not actually exist. Bad actors identify these names and create malicious packages using the previously non-existent name, so the next time an LLM suggests the package, it exists, and it’s malicious. At present the standard defence against slopsquatting is to review PRs that may contain untrusted package names, and ensure all package pulls come from a trusted source. This article focuses on typosquatting, but it’s helpful to be aware of slopsquatting and how it fits into the typosquatting process.

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.

Assume you need to pull in the latest version of the PyPI 

 package. It has a generic name and could easily be typosquatted. There’s a known malicious package called 

. No doubt its author was banking on the fact that developers who forgot the ‘q’ in the package name would load this cryptomining malware into their development pipeline.

Let’s say that because you know this malicious package exists, you want to create a policy to explicitly target it.

An EPM policy to do this starts with the following code:

That policy looks for packages with the exact name 

. If it finds a match, you can define what action you want Cloudsmith to take later in the policy.

: You know the exact package you want to limit and the policy does that.

: You limited the policy to look for one specific malicious package, but others may get through.

package is really important to your work, another approach would be to limit other likely spelling variations that a typosquatted package may take.

You can update the policy in approach 1 to include an array of potential package names.

: You identify the known malicious package, and you proactively identify any other, similar packages that are likely to be problematic.

: This approach isn’t scalable. You would have to become an active threat researcher to properly maintain this policy. It’s also a very narrow policy focused on one specific package.

The first two approaches take a package-centric view of security. And really, they’re both reactive. While both will help you keep typosquatted packages out of your development pipeline, they don’t conform to the principle of least privilege.

Enterprises need a more comprehensive and scalable solution and least privilege does just that. The idea is to define what you 

want to use in your software supply chain and to allow only those packages. You set up rules to deal with anything that doesn’t agree with your policy.

The primary concern with typosquatted packages is that they contain malware. So, in this case, you want a policy that allows the things you 

 want (safe packages) and flags the things you 

 want (malicious packages). A proactive, scalable policy flags all known malicious packages and lets you take whatever actions are appropriate for your organization on them.

This is a simple, straightforward policy that identifies all known malicious packages. In the OSV database, packages with malicious code receive a “MAL-” identifier. For example, the ID for the 

. This policy compares the packages in your Cloudsmith repo with the OSV database and flags all matches with a “

There’s a broad community that, in effect, maintains the OSV database. Relying on this crowdsourced database is much more scalable, reliable, and ultimately accurate than trying to track down threats on your own.

: Scalable, applies principle of least privilege, relies on trusted third-party data for comprehensive scanning.

: Automatic scanning only occurs when a new instance of malware hits the source databases. If you are aware of a new example of malware before it appears in one of the source databases you may need to use one of the other approaches as a stopgap.

There’s one more scenario worth considering (for now) related to typosquatting. What if you already have a typosquatted package in your software supply chain. This may be a dependency that pre-dated current policies, or something that was a temporary exception that the team forgot about. Or perhaps someone found a bit of malicious code in a package that went unnoticed and was previously deemed safe.

Regardless of how it ended up in your supply chain, once knowledge of a compromised package hits the OSV database you want to know if it impacts your software supply chain. For most artifact managers, you would need to initiate a manual scan of your repos. Sure, you can set up alerts for OSV updates and/or schedule scans, but those are the kind of maintenance burdens that users want to avoid.

 feature. As mentioned above, Cloudsmith does an initial security scan when first pushing packages to the platform. Continuous Security, however, checks the source databases (i.e., OSV, Trivy) every hour. When it detects a new vulnerability or malicious package, it looks at your repository to see if it contains anything that may be affected. If so, Continuous Security triggers a scan of your repository against your EPM policies. This process happens automatically so you don’t have to schedule checks or scans.

The constant push to accelerate software development increases potential security risks to developer software supply chains. Bad actors create malware faster than security professionals can identify it. Taking proactive security measures mitigates the risks posed by malicious typosquatted or slopsquatted packages. This will become increasingly important as AI-generated code proliferates more builds.

Utilizing an artifact manager, like Cloudsmith, allows organizations to create policies around package consumption and implement automation for how to handle malicious packages when they appear. By acting as a centralized control point for all package consumption within your organization, Cloudsmith enables a proactive, scalable, and transparent security posture that allows developers to work fast and securely. In the speed vs security tug-of-war, Cloudsmith provides the middle ground that caters to both sides.

Want to see how Cloudsmith can help your organization? Book a 

Protect your software supply chain from typosquatting with Cloudsmith

 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.

Cloudsmith Blog

Intelligence and governance in the software supply chain with Endor Labs and Cloudsmith

13 KubeCon Europe 2026 sessions not to miss

LLMOps vs DevOps: What LLMOps means for artifact management

Kubernetes 1.36 – What you need to know

Dependency confusion and trust boundaries in modern builds

Why cloud migrations are the best time to re-evaluate your artifact management

Securing LLM dependencies against serialisation attacks

Top 10 most popular LLM models on Hugging Face

7 key metrics to measure software supply chain security

LLMs on Kubernetes: same cluster, different threat model

I love Software (in) NI

AI artifacts: The new software supply chain blind spot

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