Hugging Face revamps Kernels: security, agents and performance | Keryc
Hugging Face has just published a major revamp of Kernels that affects everything from how they’re published on the Hub to how they’re built, signed and optimized with agents. Want to know what changes for developers, users with accelerators, and for those who want to automate optimizations with agents? Here I explain it step by step.
Kernels as a new repository type
Now there’s a new repository type on the Hub called kernel. Why does it matter? Because Kernels are first-class citizens: you can see which accelerators, operating systems and backend versions each kernel supports, which makes it much easier to decide if a kernel will work on your hardware.
Kernels become more discoverable and also allow analyzing trends across kernels, models and applications.
Security and reproducibility: Nix, signing and trusted publishers
Kernels run native code with the same privileges as the Python process that loads them. That means security isn’t optional. Hugging Face reinforced several layers:
Reproducibility with Nix: hermetic builds and pure recipes that let you rebuild a kernel and verify it matches the public code.
Provenance: the commit SHA1 is embedded in the kernel to trace its origin.
Trusted publishers: by default only kernels from trusted publishers are loaded. If you want to load a kernel from an unverified repository, you must explicitly opt in with trust_remote_code=True.
Publishing a repository as a kernel isn’t open by default: you have to request access from account settings. This allows careful review of cases.
Code signing with Sigstore
To protect against Hub compromises, code signing was added. In short:
A kernel is signed with a private key known only to the developer.
Verification uses the public key available, so an attacker uploading a malicious kernel won’t be able to sign it.
Sigstore cosign is used with ephemeral keys to reduce risk when a key is leaked.
Additionally, it’s verified that the signature came from a trusted GitHub workflow.
The kernel-builder utility already supports signing, and there’s kernels verify-signature to check signatures. For now, automatic upload doesn’t verify signatures at upload time until the flow is fully tested.
Previously many utilities were mixed between kernels and kernel-builder. Now there’s a clear separation:
kernels: library to load and prepare kernels at runtime.
kernel-builder: CLI and tools focused on building kernels and enforcing a reproducible structure.
This makes each tool lighter and more focused, and easier to integrate in automated flows or agents.
More frameworks and backends: Torch Stable ABI and TVM FFI
Coverage of frameworks and backends was expanded:
Support for the Torch Stable ABI: allows a kernel targeting a stable Torch version (for example Torch 2.9 Stable ABI) to work with Torch >= 2.9 for roughly two years.
Apache TVM FFI: added as the first framework other than Torch. TVM FFI is an ABI that eases interoperability with PyTorch, Jax, CuPy and others, allowing kernels to be more portable across frameworks.
Foundation for agentic kernel development
Hugging Face is building tools with workflows in mind where an agent generates, builds, measures and optimizes kernels iteratively.
kernel-builder enforces a reproducible project structure that agents can expect and leverage.
CLIs are designed to be agent-friendly: non-interactive commands and outputs that are easy to parse.
There are backend-specific skills that capture toolchains, build paths and performance considerations.
The goal is that an agent can:
Scaffold a kernel.
Run a reproducible build.
Launch benchmarks (integration with HF Jobs).
Analyze results and re-optimize.
Integration with HF Jobs makes it easy to run benchmark suites on different hardware and compare against a baseline.
Practical examples and utilities
Want to know if a kernel is compatible before trying to load it? Use has_kernel():
from kernels import has_kernel
print(has_kernel("kernels-community/activation", version=1))
# Returns True or False
If you need to understand why a kernel was rejected, get_kernel_variants() gives you detailed decisions:
from kernels import get_kernel_variants, VariantAccepted
for decision in get_kernel_variants("kernels-community/activation", version=1):
name = decision.variant.variant_str
if isinstance(decision, VariantAccepted):
print(f"{name}: compatible")
else:
print(f"{name}: rejected ({decision.reason})")
Example output (depends on your machine):
torch212-cxx11-cu130-aarch64-linux: compatible
torch210-cu128-x86_64-windows: rejected (CPU (x86_64) does not match system CPU (aarch64))
torch212-metal-aarch64-darwin: rejected (OS (darwin) does not match system OS (linux))
Binary compatibility and manylinux
A technical detail that caused headaches was the previous decision to statically link libstdc++ to meet manylinux and avoid incompatibilities. Result: problems from global initializations when multiple versions of libstdc++ coexist (for example, PyTorch's and the kernel's), which can cause data corruption and segfaults.
Adopted solution:
Kernels now link libstdc++ dynamically.
To keep compatibility with older versions, builds use the official manylinux_2_28 toolchain.
This reduces collisions between runtimes and improves stability in heterogeneous environments.
Misc: installation, Terraform and system cards
There’s an installation script that prepares the kernel-builder environment in one click, useful if you don't want to set everything up manually.
If you prefer ephemeral cloud instances, there’s a Terraform guide to deploy reproducible environments.
Publishing a kernel generates a system card that exposes useful info: interfaces, usage and metadata. That system card works like the kernel's front matter on the Hub.
Final thoughts
This set of changes makes the kernels ecosystem more secure, reproducible and ready for advanced automations with agents. If you work with accelerators or develop native ML code, these improvements help you reduce risk and speed up optimization cycles.
What about you? If you already have kernels in production, it's worth reviewing the new signing practices, publisher policies and how to adjust your build pipelines for manylinux_2_28. If you want to start experimenting, the quick install and the has_kernel/get_kernel_variants examples make the first steps easier.
Acknowledgments: thanks to Aritra for reviewing the post.
