🤗 Kernels: Major Updates

Log In<br>Sign Up

Back to Articles<br>a]:hidden">

🤗 Kernels: Major Updates

Published<br>July 6, 2026

Update on GitHub<br>Upvote 16

+10

Sayak Paul sayakpaul Follow

Daniël de Kok danieldk Follow

David Holtz drbh Follow

In our previous post (From Zero to GPU), we introduced the 🤗 Kernels project, which aims at standardizing how custom kernels are packaged, distributed, and consumed. We want the project to be frictionless and secure, while making it as Hub-friendly as possible.

Over the past few months, we have worked towards this goal. In the process, we also almost completely redesigned the project. This post will summarize the major updates we have shipped and what’s coming.

Table of contents

Kernels – a new repository type

Improved security

Revamped CLIs

More coverage of frameworks and backends

Foundation for agentic kernel development

Misc

Conclusion

Kernels – a new repository type

We have introduced a new repository type on the Hub called "kernel". This enables us to cater to users with compute-related specificities. For example, a user can get a sense of which accelerators, operating systems, and backend versions are supported for a given kernel:

Kernel page: kernels-community/flash-attn3

One can browse all available kernels on the Hub here: https://huggingface.co/kernels.

Making these kernels first-class citizens of the Hub also benefits the AI ecosystem. Users can now see trends across kernels, models, and the applications that use them. The kernels become more discoverable to users.

Improved security

Kernels run native code with the same privileges as the Python process that loads them, so a malicious kernel can do real harm. Therefore, security has always been of utmost importance to the Kernels project.

This is why we focused early on reproducibility: you should be able to recompile a kernel yourself and verify that it matches the publicly available source. We use Nix to make this possible, since it keeps builds pure through hermetic evaluation of the build recipe and a strongly isolated sandbox. We further improve provenance by embedding the source Git SHA1 into the kernel itself.

In recent months, we have added additional layers of defense: trusted kernel publishers and code signing.

Trusted kernel publishers

With the new repo type, we also introduced “trusted publishers”. Since kernels execute code on a machine with the same privileges as the Python process they are used in, an attacker could compromise machines by uploading a malicious kernel and coaxing you to use that kernel. To help you avoid such malicious kernels, the kernels package will now only load kernels by trusted publishers by default. A trusted publisher is an organization that is trusted by the community to act in good faith.

We still want to support loading kernels from organizations or users that are not trusted publishers, but you have to explicitly opt in using the trust_remote_code argument when loading a kernel from the Hub:

from kernels import get_kernel

kernel_module = get_kernel(<br>“Atlas-Inference/gdn”, version=1, trust_remote_code=True

By default, users cannot publish kernel repositories on the Hub. They have to request to be a kernel publisher. Users and organizations can request for access from their account settings. This gives us time to treat these requests on a case-by-case basis.

Kernel signing

An additional layer of security that we are adding is code signing. Code signing protects against the scenario where an attacker uploads a malicious kernel to a kernel repo from a trusted publisher whose Hub credentials were compromised. In code signing, a kernel is signed with a private key known only to the kernel developer and validated with a public key that is generally available. In the Hub compromise scenario, an attacker cannot sign the malicious kernel since they do not own the private key needed for signing.

To further improve security, we use Sigstore’s cosign to sign using ephemeral private keys. Since these signing keys are only valid for a limited time, an attacker typically cannot use the private key, even when it is leaked. We also verify that the kernel was signed by a trusted GitHub workflow from a trusted GitHub repository.

Kernel signing is already supported by kernel-builder and we have provided the kernels verify-signature to verify a kernel. Kernels does not verify the signature upon loading a kernel yet, since we would like to test this new functionality more before fully rolling it out. Preliminary notes on setting up code signing for your own kernels can be found in the kernels 0.16.0 release notes: https://github.com/huggingface/kernels/releases/tag/v0.16.0.

Revamped CLIs

Previously, a bunch of utilities were intertwined between kernels and kernel-builder. We have established a better separation of concern between the CLI of kernels and kernel-builder. The mental model here is that kernels is a library for loading and preparing kernels for...