The Kernels project standardizes how custom kernels are packaged, distributed and consumed, with a focus on frictionless integration, security, and Hub compatibility. Over recent months the project was substantially redesigned: a new repository type, strengthened security layers, CLI reorganization, and agent-focused development foundations have been shipped. Below is a structured summary of the main changes and related details.
New repository type: "kernel"
A new repository type called "kernel" is now available on the Hugging Face Hub. This lets kernel authors declare compute-specific metadata and helps users understand which accelerators, operating systems and backend versions a kernel supports.
- Example kernel page: kernels-community/flash-attn3
- Browse all kernels on the Hub: https://huggingface.co/kernels
Treating kernels as first-class Hub entities improves discoverability and enables cross-entity insights across kernels, models and their applications.
Improved security
Because kernels execute native code with the same privileges as the Python process that loads them, a malicious kernel can cause real harm. The Kernels project therefore places strong emphasis on security.
-
Reproducibility: builds use Nix for hermetic evaluation and isolation, and the source Git SHA1 is embedded into the kernel to improve provenance and verifiability.
-
Trusted kernel publishers: with the new repo type, kernels are by default only loaded from "trusted publishers". A trusted publisher is an organization the community relies on to act in good faith. Loading kernels from non-trusted organizations or users is still possible but requires explicitly opting in with the trust_remote_code argument when calling get_kernel, for example:
from kernels import get_kernel
kernel_module = get_kernel( "Atlas-Inference/gdn", version=1, trust_remote_code=True )
Publishing kernel repositories to the Hub is not public by default: users and organizations must request kernel publisher access via their account settings, and requests are processed case-by-case.
-
Kernel signing: an additional safety layer is code signing. A kernel is signed with a developer-held private key and validated with a public key. This defends against a scenario in which an attacker who compromises a trusted publisher’s Hub credentials uploads a malicious kernel — the attacker cannot produce a valid signature without the private key.
- Signing uses Sigstore’s cosign with ephemeral private keys. Because those keys are time-limited, leaked keys typically cannot be reused indefinitely.
- The system also verifies that a kernel was signed by a trusted GitHub workflow from a trusted GitHub repository.
Kernel signing is supported by kernel-builder and the project provides a kernels verify-signature command to check a kernel. Automatic signature verification on load is not enabled yet; the team intends to test this functionality further before rolling it out. Preliminary setup notes are available in the kernels 0.16.0 release notes.
Revamped CLIs
Utilities that were previously mixed between kernels and kernel-builder have been separated. The core mental model is that kernels is a library for loading and preparing kernels for use, while kernel-builder handles building kernels.
As a result both packages are leaner and more focused. Refer to the kernels CLI and kernel-builder CLI documentation for details.
Broader framework and backend coverage
Support has been extended for additional frameworks and ABIs:
-
Torch Stable ABI: kernels and kernel-builder now support the Torch Stable ABI, which lets kernel developers target a specific Torch ABI and be compatible with that version and subsequent releases for roughly two years. For example, a kernel targeting the Torch 2.9 Stable ABI should work with Torch >= 2.9.
-
Apache TVM FFI: TVM FFI is the first non-Torch framework supported. It provides a standardized ABI that interoperates with frameworks like PyTorch, Jax and CuPy, enabling kernels that run across frameworks.
Foundation for agentic kernel development
kernel-builder and kernels are intended to complement the rise of agentic kernel development, where an agent can scaffold, build, benchmark and iteratively optimize kernels.
- kernel-builder enforces a predictable project layout and reproducible build workflow, which is important for agent-driven automation.
- CLIs are designed to be agent-optimized (non-interactive commands, outputs that are easy for agents to parse programmatically).
- Backend-specific "skills" capture toolchain details, compilation paths and performance considerations to guide agents through backend idiosyncrasies.
Building a kernel successfully is only the first step: the kernel must yield measurable speedups on target hardware. That often requires benchmarking across multiple accelerators and generations. The tight integration with HF Jobs helps agents run benchmark suites, collect performance results and compare them against baselines so agents can iterate on optimizations.
Example agent-augmented kernels:
Miscellaneous improvements
-
Environment setup: the kernel-builder environment setup has been simplified with an installation script for one-click setup. A Terraform setup guide is available for ephemeral instances.
-
System card: after building a kernel a system card is produced that exposes usage information and interfaces. This system card becomes the front matter when pushing the kernel to the Hub (example: kernels-community/flash-attn3).
-
Compatibility checks: has_kernel() returns a boolean indicating whether a kernel is compatible with the current system. For detailed accept/reject reasons use get_kernel_variants(), which enumerates variant decisions and rejection reasons.
-
manylinux_2_28 improvements: to avoid potential memory corruption issues caused by mixing statically and dynamically linked libstdc++ versions (for example, a statically linked kernel and dynamically linked PyTorch), kernels now link libstdc++ dynamically and compile with the official manylinux_2_28 toolchain to preserve compatibility.
Conclusion
The Kernels project aims to serve both kernel developers and users of custom kernels by simplifying packaging and distribution while strengthening reproducibility and security. The new kernel repo type, trusted publishers and code-signing add important security assurances; CLI separation, expanded framework coverage and agent-focused features improve developer workflows. The project welcomes community feedback and contributions.
Acknowledgements: Thanks to Aritra for reviewing the post.
