By submitting this form, you agree to our 

Answer twenty questions about your artifact and supply chain practices. Get a custom report card showing your maturity score against key regulatory and compliance frameworks.

Artifact Security Maturity Assessment

Someone on your team writes a skill that automates a tedious task. It works well, so they share it in Slack. Within a few weeks, dozens of people have installed a copy of it, and their agents run it. Which version is current? Who wrote it? Has anyone reviewed it?

This is happening well beyond engineering. Analysts, operations staff, and other citizen developers now write skills to automate their own work, and useful tools spread faster than anyone can track. If that sounds like shadow IT in the early days of cloud computing, it is the same pattern with a new kind of artifact.

manage agent skills and Claude plugins as artifact types in Cloudsmith

, alongside your packages and containers. Host the skills your teams write so everyone can discover them, bring in public ones from the GitHub repositories you trust, and block the skills you don't want.

Skills are spreading faster than anyone can govern

Skills spread because they work. Teams share them by email, Slack, and Google Drive, and pull others from Git repositories, community catalogs, and standalone registries. Each source has its own way to publish, version, and control access, so many teams can’t say which skills their agents pull, or which versions. It’s the early days of cloud again: useful tools spread team by team, and IT often spends years catching up on what’s running where.

A skill is a bundle of instructions and resources that an agent loads for a specific job, such as following your team's review process. It's a 

 file plus the scripts, references, and templates it needs. A Claude plugin bundles skills so teams can install them as one unit.

That makes skills a software supply chain question. Agents act on those instructions and run those scripts, sometimes with access to sensitive systems and data. A skill pulled from a public source carries the same unknowns as other third-party open source packages: you don't know who wrote it, what changed, or whether anyone reviewed it.

A skill that is malicious, changed, or simply wrong can cause an agent to leak data, run harmful commands, or take actions no one intended, using the access the agent already has.

Store and govern skills alongside everything else your agents rely on

A skill is a bundle of files, so Cloudsmith can treat it like any other package and give it a version. That makes Cloudsmith the place to store and govern skills alongside the packages and dependencies your AI agents and teams already rely on, instead of in a separate, standalone tool. With Cloudsmith, you can:

Host the skills your teams write, versioned, alongside packages, containers, and other artifacts

Bring in public skills from sources you trust

Control which skills and versions your teams can pull

Cloudsmith supports more than 30 artifact formats, so skills sit in the same system of record as the packages, containers, and dependencies your agents and teams use every day.

Cloudsmith gives developers approved skills in the repositories they already use, while giving security the visibility and control to decide which skills agents can use. Four capabilities make that work.

Host skills and plugins as a package type

Host versioned skills and Claude plugins in a governed control plane, right next to packages and containers. Each release gets a semantic version or a git commit SHA, plus a SHA-256 checksum. Keep your Cloudsmith repositories private, or share them publicly. Developers discover skills in the same repositories as every other artifact.

GitHub is where we built first, because it's the source our customers told us they use. Add a GitHub repository as an upstream with a token, and Cloudsmith caches its skills and plugins so your teams pull from the sources you chose. Private repositories work too, as long as the token has access.

Through Cloudsmith, your teams only get skills from the publishers you add to your GitHub upstreams. Add deny rules to block a specific skill or version by name without giving up the rest of the repository. A blocked skill doesn't show up when developers pull or list, and they get a "nothing found" error, just like other formats.

Skills use the same audit logging as every other format in Cloudsmith, so security can see which skills and versions get pulled, in the same trail as the rest of your software supply chain.

Keep teams moving while you govern skills

Governance works when developers keep using it, so we kept the workflow familiar. Publish a skill once to your Cloudsmith repository, and every team can discover and use the same version. Upload through the web app or the API, or use the CLI. Repository privileges decide who can publish. Security chooses the sources and rules once. Teams use approved skills without waiting on sign-off for each one.

Your Cloudsmith repository also works as a Claude Code plugin marketplace. Developers add it once, then install plugins right in their session with 

Platform engineering controls which skills teams use. Security extends software supply chain governance to agent skills. Developers publish once and discover what their teams have already published. And citizen developers can upload a skill in the web app.

Skills deserve the same management as every other artifact

Skills belong in a universal artifact management platform, alongside your packages and containers, with the same policies and the same audit trail. Early access is open now. 

Jamie Smith

Technical Product Marketing Manger

Manage your AI skills along with all your other packages and dependencies

Every skill a team installs hands an AI agent new instructions to follow and, often, new code to run. A skill is a set of written instructions, sometimes with scripts and reference files, that an agent loads when a task calls for it: following a review process, querying an internal tool, or formatting a report to the team’s standard. Like a package, a skill is a separate bundle that gets pulled in and run, whether your own team wrote it or someone else did.

People in engineering, operations, analytics, and beyond now write their own skills or pull them from wherever they find them, often with no one outside the team reviewing them. And a skill’s instructions can tell an agent to install packages, so one unreviewed skill can bring in more dependencies.

Teams already govern npm packages and container images through an artifact registry and the packages agents install can go through the same checks today. The skills themselves are the next dependency to bring under that control.

What a skill is and why it behaves like a dependency

An AI agent skill can include several types of files. A 

 holds the skill’s metadata (a required name and description) and the instructions the agent follows. Optional folders hold reference docs, templates, and scripts that can include executable code the agent can run.

Agents typically have access to your repository credentials, internal APIs, production data, and other potentially sensitive information, depending on how you configure them. The agent follows the instructions in the 

 file and runs any bundled scripts as necessary, giving those scripts the same access that the agent has or, where the agent asks for approval, whatever the user approves. A skill that is malicious, changed, or simply wrong can cause an agent to leak data, run harmful commands, or take actions no one intended.

A skill pulled from a public catalog or repository raises the same questions as any open source package: who wrote it, what changed, and whether anyone reviewed it. Skill instructions can tell an agent to install packages, so one unreviewed skill can pull in dependencies nobody chose. We’ve written previously about the need to 

secure the packages that AI agents install

Skills spread faster than anyone can track them

Skill usage spreads quickly because anyone, not just developers, can create and share them. With AI assistance, analysts, operations staff, and other non-developers can build and iterate agent skills. And these skills live all over the place: Git repositories, community catalogs, standalone registries, and individual workstations.

Catalogs and Git hosts make skills easy to share and leave governance to whoever pulls them. Skills you develop within your organization may be subject to the Git-based controls in place for general development, providing visibility into review, history, and ownership of individual skills.

Security teams need insight into which version of a skill every agent pulls, what public skills people are downloading and installing, and who within the organization is making these trust decisions, and Git doesn’t tell you that.

Public skill catalogs catch some, but not all, malicious skills

Developers are used to public registries like npm and PyPI. ClawHub, OpenClaw’s public skill registry, plays that role for agent skills. Since February 2026, at least four independent research teams have 

 on ClawHub. Koi Security alone found 341 among 2,857 skills it audited. Even as ClawHub added scanning capabilities with ClawScan, attackers found routes around it. For example, 

 found one skill padded to exceed scanner size thresholds, which slipped past both ClawScan and VirusTotal until researchers reported it.

Server-side scanning and removing flagged skills help to mitigate the impact of malicious skills. Some users may pull from a centralized catalog like ClawHub, but others install straight from Git repositories, or through catalogs like skills.sh that hand off to Git instead of hosting a reviewed copy. The fragmentation of skills distribution puts the onus on your organization to decide what is allowed to cross its trust boundary.

Visibility lets security make informed decisions about approving skills

A governed control plane would let security teams quickly answer basic questions: which skills exist in the environment, which versions agents pull, and which policies were applied.

Security teams can ban or require manual review of skills, but that creates friction, slows development, and is the type of control that leads to workarounds. Rules set once let security stay in control while teams keep moving.

Agents install packages the same way developers do, often without anyone reviewing the choice. Route both through Cloudsmith to check every package against your 

 before it reaches a laptop or a pipeline. Only packages that pass your vulnerability, malware, and license rules get installed, and every pull lands in the same audit log.

The next step: treat agent skills like any other dependency

Guardrails for what a skill installs are just the start. The skill itself is the next dependency to bring under the same control. Artifact registries have done this job for packages and containers for years, and skills fit the same model. A skill is a bundle of files, like a package. The spec doesn’t require a version, so a skill pulled from Git can change under the same name. A registry that treats skills as packages would pin each release, so you’d know exactly which release every agent pulled.

Routing skills through a registry would give internal teams a place to publish, version, and control access to the skills your organization develops, and a record of which skills and versions every agent pulls.

Give skills the same entry point as everything else

Teams will keep writing and sharing skills, because skills make agents useful. Start with the packages your agents install today, then treat the skills themselves like any other dependency.

Skills will keep changing. When every skill comes through your artifact registry, you see each change as it arrives.

Cloudsmith solves artifact management challenges

Jason Myers

Technical Content Marketer

Agent skills are the newest dependency in your software supply chain

Cloudsmith now supports hosting public and private Nix binary caches. Teams that use Nix and NixOS can point existing 

 workflows at Cloudsmith without any additional tooling.

(Note: Nix format support is currently in Early Access.)

Nix builds work differently from most package ecosystems. Initiating a build in Nix begins with an evaluation of all the inputs that go into the build. This includes source code, dependencies, and build instructions, and each item gets hashed. The evaluation output is a derivation (a 

 file), which is a build recipe that describes what’s in the build. Nix then hashes the derivation to compute the package’s store path. Because downloading a pre-built version is faster than building from source, Nix then asks its substituters (remote binary caches like the default 

) whether that store path already exists. If it does and is signed by a key that Nix trusts, then Nix will download it. If it doesn’t exist, Nix builds it from scratch.

 packages from the public cache, but their own builds require a private binary cache, which is typically self-hosted. Relying on the public cache means accepting availability and bandwidth limits, which may not meet the needs of compliance-focused teams. Self-hosting a private cache with 

 or S3 means patching, scaling, and on-call duty for infrastructure that only serves packages.

 for Nix release channels. You must configure a separate upstream for each channel you want to use.

The first time you request a store path that Cloudsmith doesn’t have, it fetches the package from the configured NixOS channel, caches it, and serves it. Subsequent pulls are served from Cloudsmith’s cache, so builds are fast and keep working during a 

You can also push new Nix builds to a Cloudsmith repo, which then functions as a private Nix binary cache, but without the overhead tax of self-hosting.

Signing and verifying Nix packages in Cloudsmith

Where other ecosystems use package name and version number to identify packages, Nix uses a cryptographic hash to identify and verify them. Cloudsmith signs each package’s 

 with the repository’s ED25519 key on every read, and Nix verifies that signature against trusted keys. Because signing happens on every read rather than once at upload, key rotation takes effect immediately, with no backlog of packages to re-sign, and multiple keys can be active and signing simultaneously.

To get started using Nix with Cloudsmith, you can create a dedicated Nix repository. Add that repo to your Nix 

 list, and the repository’s public key to 

. This configuration means Nix treats Cloudsmith like cache.nixos.org. To proxy a public channel, add that as an upstream to the repo.

For private repos, authenticate with an entitlement token in a 

 file. Push Nix packages you build locally to your Cloudsmith Nix repo using 

 flag because locally built packages are unsigned and Cloudsmith handles signing on read.

For detailed setup instructions, see our 

Cloudsmith allows you to consolidate cached Nix packages in a single, cloud-native environment with multi-format repositories. Teams no longer rely on public cache availability, or pay the operational tax of self-hosting. Upstreams cache public channel packages in Cloudsmith for fast, reliable pulls.

Nix packages often sit outside the access controls and audit logging that cover the rest of your software supply chain. Bringing Nix into a Cloudsmith workspace, with 30+ formats in multi-format repositories, lets you govern Nix packages with the same access controls, entitlement tokens, and audit logs that you use on the rest of your software supply chain.

 for more information about using Nix in Cloudsmith.

Cloudsmith expands support to Nix

With legacy artifact managers, every ecosystem that dev teams use requires a separate repo. What happens when teams try to keep their line of work isolated, but they rely on the same ecosystem and packages as other teams? Platform teams have to configure multiple instances of the same repo for each team. This increases the complexity of the organizational repo structure, and means more repos, URLs, configs, and security policies to manage, not to mention greater storage needs. Using Cloudsmith’s 

 you can configure multiple upstreams in a multi-format repo, cache those packages once, and deliver them to downstream repos, all with a single URL.

Maintaining upstreams for every individual repository comes with an overhead tax. The amount of effort teams have to put into maintaining upstreams can quickly become a burden depending on how they structure their repositories. Legacy artifact managers rely on language-specific repos so teams need to configure an upstream for each repo. Therefore, if you use npm, Python, Rust, and Maven, then each language has its own upstream URL, configuration, and security policy. Now, if you’re working on a small team and those are the 

 repositories you pull from, it's manageable. But at scale, going from four repos to 40+, things get much more complex.

While maintaining dozens or hundreds of repos is a very real burden, it's the toll all those endpoints take on your security at scale that's easy to overlook.. The need to configure security policy for each individual upstream simultaneously increases the attack surface and the number of gaps within that attack surface. Policy enforcement becomes inconsistent and hard to do across enterprise-scale upstream configurations. A single enforcement point decreases risk by removing many of the gaps within the attack surface.

Connected repositories are a native Cloudsmith feature that links repositories and resolves packages through a single URL. The images below illustrate two different architectural configurations of connected repositories.

Cloudsmith supports multi-format repositories, so users can configure a single repository with multiple upstreams, as seen in configuration B. The OSS Packages Repository has upstreams for Maven, Python, and NuGet, and this is where packages from those ecosystems get cached. The repository, which is where end users pull from, doesn’t perform any caching or duplication of packages in the OSS Packages repo; it inherits the upstreams from the OSS repo and pulls packages straight through. When configuring connected repositories, teams can set priorities for each upstream (see config B). If two upstreams have the same priority, Cloudsmith automatically breaks these ties based on the upstream creation timestamp.

Package resolution is also automatic for connected repositories. You can see in configuration B above that the Enterprise Packages Repository is PRIORITY 1, the Shared Packages Repository is PRIORITY 2, and the OSS Packages Repository is PRIORITY 3 for the main repository. Cloudsmith resolves packages inside Cloudsmith in priority order first, then resolves packages outside Cloudsmith in priority order. Going back to the diagram, any packages in the main repository get resolved first, followed by packages in the Enterprise Packages Repository, then packages in the Shared Packages Repository, and finally packages in OSS Packages Repository. Each of the upstreams in the OSS repo will have a priority status, so those will resolve according to their established priority.

Connected repositories can reduce upstream sprawl and provide teams with more flexibility in how they structure their repos within their artifact manager. The repo architecture that’s right for your team will depend on what factors you value. Typically the key tradeoffs come down to isolation, visibility, access controls, and operational overhead. (If you want a detailed breakdown of the architecture configurations below, our team can 

 This configuration is exactly what it sounds like. A single repo for every package. While this is structurally simple to set up and run, there is no isolation between lines of work or development environments. This approach works for small teams, but quickly becomes unwieldy for larger teams.

 This approach creates one repo for every language or format a team uses. This is a familiar repo structure used by legacy artifact managers. It offers a single source of truth for each development language and keeping a format-specific approach can make migrating to a new artifact manager easier. However, this structure lacks combined visibility across formats for usage, licenses, vulnerabilities, logs, etc.

 This structure has a repo for each team, service, or product. The line of work approach allows teams to own their repos, which means they can set up granular access controls, giving them more accountability over the trust decisions in their development environment. As for tradeoffs, this structure has higher potential to house duplicate packages and to create sprawl, especially if the repos don’t support multiple formats. Teams need strict tagging discipline when using this approach. For example, poor tagging could lead to deleting packages needed for production

This approach includes one repo for each different production environment, typically build, test, and production. Environment-scoped RBAC and retention rules help to avoid some of the challenges with the line of work approach. This structure also provides a really clean promotion pathway; teams can clearly tell which development stage a package in is based on the repo storing it. The tradeoff is that teams have less visibility into specific lines of work, and need to make sure they follow clear naming conventions to avoid package conflicts.

 This approach combines the line of work and environment-based structures. It consists of one repo for each line of work within each environment-based repo. While it combines the best aspects of those two approaches, it also introduces the potential for repo sprawl, depending on how many lines of work a company has. This structure also requires advanced package promotion logic to ensure the right packages get promoted to the right location. Sharing packages across lines of work can also be challenging, depending on how teams configure their repos.

Connected repositories give you flexibility. The flexibility to pick a repo structure that fits the needs of your organization and the way your teams want to work. You get the flexibility of optimizing your repo structure to accentuate the tradeoffs you want over the ones forced on you from inherited systems. Connected repositories can reduce the URL- and upstream-sprawl that resulted from choosing anything other than a super-repo.

Ready to optimize your repo architecture? 

Simplify repository structure with connected repositories

 is a software supply chain weakness that arises from how package managers resolve dependencies across multiple sources.

It does not rely on complex exploits. It relies on normal dependency resolution.

If a build resolves from both private and public registries, and a public package shares the same name as an internal dependency, the public package may be selected. That is sufficient to introduce unintended code into a build.

Modern dependency trees often include extensive transitive dependencies, increasing the number of automatic resolution decisions made during builds.

when researchers demonstrated it against more than 35 large organizations by publishing public packages that matched internal names. Since then, dependency confusion has remained a known and preventable risk in modern build systems.

If resolution rules are not explicit, package managers make decisions on your behalf.

Different ecosystems provide different structural protections and different pitfalls.

PyPI operates on a flat global namespace. There are no built-in organizational scopes and no domain bound identifiers. Package names are globally unique and first come, first served.

This means internal package names, for example acme utils or internal ml core, are structurally indistinguishable from public ones unless additional controls are applied.

Python projects frequently configure multiple indexes. It is common to see:

Vendor-hosted repositories such as PyTorch wheel indexes for CUDA builds

Python tooling such as pip, uv, and Poetry evaluates candidate versions across configured sources. If the same package name exists in more than one index, the resolver may select the highest compatible version, regardless of origin.

Real-world incidents demonstrate this behavior. 

In 2022, a malicious package mimicking a PyTorch dependency

 was published to PyPI and installed via pip resolution during nightly builds, leading to data exfiltration before detection.

Without explicit trust boundaries or source mapping, this multi index behavior introduces ambiguity. If an internal package name is exposed and a higher version appears on a public index included in resolution, the public package may be selected.

Python’s flat namespace model, combined with common multi index configurations, makes careful source control particularly important.

npm supports scoped packages using the @org/package format. Once registered, a scope is controlled by that organization.

However, unregistered scopes remain claimable. If an organization uses scoped internal packages but has not reserved the scope publicly, an attacker could register it and publish similarly named packages, for example @org/app. A configuration mistake in development or CI could then result in the malicious package being resolved and executed, including via lifecycle hooks such as preinstall.

Unscoped internal package names carry exposure similar to Python.

Maven Central uses domain-based groupId verification, providing stronger ownership guarantees when correctly configured.

However, inconsistent repository usage or additional repositories can reintroduce ambiguity in resolution order if trust boundaries are not clearly defined.

While NuGet supports ID prefix reservation to prevent public name squatting, resolution ambiguity can still arise if multiple feeds are configured.

ID prefix reservationReserve your organization’s package ID prefix on nuget.org to prevent public impersonation.

Package Source Mapping Use NuGet 6+ source mapping to bind specific package IDs or prefixes to a single trusted feed.

Strict nuget.config configurationClear default feeds and explicitly define approved sources to prevent unintended restores.

Signature enforcementNuGet repository signing using X.509 certificates. When signature verification is enforced in the NuGet or .NET CLI, consumers can verify that a package originated from the expected repository and has not been tampered with.

Docker Hub differs from language ecosystems because image references are typically registry qualified, making classic multi-source confusion less common.

Implicit Docker Hub fallback when no registry is specified

These are mitigated through fully qualified image references, namespace reservation, digest pinning using SHA256, and image signing.

Preventing dependency confusion does not require dramatic changes to developer workflows. It requires clear trust boundaries in how dependencies are resolved.

In practice, this is implemented through an internal artifact repository that controls how dependencies are proxied, cached, and resolved.

Enforcing artifact signing and verification

Route all builds through a central artifact repository that acts as the single source of truth for dependencies. Public packages should be proxied and cached internally rather than resolved directly from the internet.

Explicitly distinguish between trusted and untrusted sources.

Cloudsmith provides upstream trust controls that allow repositories to designate upstream sources accordingly and control how packages are blended during resolution. If a package exists in a trusted source, it cannot be overridden by an untrusted one.

Cloudsmith’s Upstream Trust currently supports:

Support for additional ecosystems is expanding. In addition to source trust controls, policy enforcement provides another layer of protection. 

 allows organizations to define rules around what packages are permitted, including conditions based on vulnerability data, malware data, version constraints, or upstream origin. This enables teams to combine resolution boundaries with policy-based controls.

Namespace ownership significantly reduces collision risk.

Lockfiles improve determinism, traceability, and visibility into unexpected changes. They do not eliminate dependency confusion, but they reduce instability and make tampering easier to detect.

Signing adds cryptographic integrity to artifacts.

Cloudsmith signs hosted packages by default. Cloudsmith supports both native and non-native signing across package formats, including native signing for 

. Signature validation workflows in supported ecosystems provide an additional verification layer if substitution is attempted.

Signing strengthens integrity guarantees but does not replace resolution controls.

Dependency confusion is not a sophisticated exploit. It is a consequence of ambiguous resolution behavior across multiple sources.

A central artifact repository serving as the single source of truth for dependencies

Clear boundaries remove ambiguity. Removing ambiguity removes the attack path.


Stop leaving your build integrity to chance. 

 today to see how Cloudsmith's enterprise-grade repository controls can remove ambiguity and harden your delivery process.

Ciara Carey

Solutions Engineer

Dependency confusion and trust boundaries in modern builds

 LLMOps is the operational framework for managing the lifecycle of Large Language Models (LLMs). Unlike DevOps, which focuses on deterministic code, 

 must handle probabilistic assets like prompts, embeddings, and fine-tuned models. This shift requires a move from standard CI/CD to specialized 

 to ensure system traceability and trust.

 is a specialized set of practices for automating and managing the end-to-end lifecycle of LLM-powered applications. It extends MLOps principles to address the unique requirements of generative AI, specifically focusing on 

, prompt engineering, and vector-based data flows.

While DevOps focuses on application code and MLOps on traditional machine learning models, 

 Managing base models and their task-specific variants.

 Versioning the system instructions that dictate model behavior.

 Curating the "knowledge" used in Retrieval-Augmented Generation (RAG) systems.

 Monitoring outputs that change even when input code remains the same.

In essence, LLMOps is about operationalizing AI rather than just software binaries.

LLMOps vs DevOps: Why the difference matters

 isn't about choosing one over the other; it’s about understanding where 

 begin. DevOps is built for deterministic systems; if you deploy the same code, you get the same result. LLM pipelines are probabilistic, meaning the same "code" (prompt) can yield different outputs.

The core takeaway is that the shift from 

 involves handling much larger, more volatile assets that directly influence the "logic" of the application.

Why artifact management matters in LLMOps

In a traditional app, an artifact is just a compiled file. In AI, 

, teams face a "black box" problem where they cannot explain why a model suddenly began hallucinating or failing.

Effective AI artifact management solves for:

 Re-creating a specific model state using exact dataset snapshots.

 Tracking the lineage of a prompt to meet emerging AI regulations.

 Quickly reverting to a previous "known good" version of a prompt or embedding index.

 Preventing redundant training by reusing existing 

 generates a diverse array of non-code assets across the 

. Understanding these is key to moving beyond simple script-based deployments.

 These include base foundation models (like Llama 3 or GPT-4), fine-tuned adapters (LoRA/QLoRA), and quantized versions for edge deployment.

 Snapshots of training data, evaluation sets (Golden Sets), and synthetic data used for testing.

 Versioned system prompts, few-shot examples, and complex prompt chains that function as the "new source code."

 Vector database snapshots and the specific embedding models (e.g., Ada, BERT) used to generate them.

 Production logs, "LLM-as-a-judge" evaluation scores, and human-in-the-loop feedback.

MLOps vs LLMOps: Where traditional approaches fall short

Many teams assume their existing MLOps stacks can handle LLMs. However, 

 Traditional MLOps tools aren't built to treat a 50-word text string (a prompt) as a deployment-critical artifact. Furthermore, the 

 in LLMOps are much richer, requiring semantic monitoring rather than just simple accuracy metrics.

A common point of confusion is the choice between a 

 are for structured data used in tabular ML.

 (like weights and biases or MLflow) are the "System of Record" for the unstructured models and prompts that define an LLM app.

Universal Package Tags

More articles

Manage your AI skills along with all your other packages and dependencies

Agent skills are the newest dependency in your software supply chain

Cloudsmith expands support to Nix

Simplify repository structure with connected repositories

Dependency confusion and trust boundaries in modern builds

LLMOps vs DevOps: What LLMOps means for artifact management