Hugging Face Kernels: Major updates and security changes

Hugging Face updated its Kernels project on July 6, 2026, introducing a new "kernel" repository type on the Hub, tightened kernel security with trusted publishers and code signing, and broadened framework support including Torch Stable ABI and Apache TVM FFI.

What changed in the Kernels project?

The Kernels project now treats kernels as a first-class repository type and ships multiple tooling and compatibility improvements: a new "kernel" repo type on the Hub, a clearer separation between the kernels library and the kernel-builder toolchain, support for the Torch Stable ABI and Apache TVM FFI, and a system card for each built kernel. These changes make kernels more discoverable, let developers target stable PyTorch ABIs (for example the Torch 2.9 Stable ABI), and expose build and usage details directly on the Hub.

Hugging Face also added a one-click environment installation script and a Terraform guide for ephemeral instances to simplify environment setup for kernel-builder. Each pushed kernel now gets a system card that documents how to use the kernel and its interfaces.

How does the new security model work?

Kernels now load only from "trusted publishers" by default and add code signing using Sigstore's cosign to protect against repository compromise; users must opt in to load untrusted kernels using the trust_remote_code flag. The Hub will only load kernels from community-trusted organizations unless a user explicitly calls get_kernel(..., trust_remote_code=True), and publishers must request kernel-publishing access from their account settings before they can publish.

Code signing is already supported by kernel-builder and a verify command is available (kernels verify-signature). Signing uses Sigstore's cosign with ephemeral private keys and the project verifies that a kernel was signed by a trusted GitHub workflow from a trusted repository. Kernels does not yet verify signatures on load; the team says they will test this new functionality further before enabling verification on load. The project also embeds source Git SHA1 into kernels and uses Nix to make builds reproducible.

What else changed for developers and runtimes?

Kernel-builder and kernels now have leaner, more focused CLIs: kernels is positioned as a library for loading and preparing kernels while kernel-builder handles building. The CLI design is meant to be agent-friendly, with non-interactive commands and outputs that agents can parse programmatically. The project added backend-specific "skills" to capture toolchains, compilation paths and performance concerns across accelerators. Tight integration with HF Jobs lets agents orchestrate benchmark suites and compare results against baselines across hardware variants.

Compatibility work includes moving from statically linking libstdc++ to linking it dynamically to avoid global-initialization conflicts. Kernel-builder now targets the official manylinux_2_28 toolchain to maintain compatibility with older libstdc++ versions while avoiding segfaults caused by mixed libstdc++ linkages.

The Hub provides runtime checks such as has_kernel() and get_kernel_variants() so users can programmatically determine if a kernel is compatible with their system and inspect rejection reasons (for example, OS or CPU mismatches).

Why it matters

Treating kernels as a first-class Hub entity and building-in provenance and signing addresses two core frictions: discoverability and risk. Developers get clearer ABI targets and cross-framework options (Torch Stable ABI and TVM FFI) that reduce porting and maintenance overhead. Users gain an explicit trust model (trusted publishers plus an opt-in for remote code) and a path toward cryptographic signing that helps limit the blast radius of compromised Hub credentials.

The agent-oriented CLI and HF Jobs integration telegraph where the project expects future development: automated, iterative kernel optimization and reproducible benchmarking across hardware.

What to watch

Watch for when kernels begin verifying signatures on load; the team says signature verification is not enabled yet and will be rolled out after more testing. Also monitor kernel-publisher access requests on the Hub, and adoption signals for agentic kernel development workflows that use kernel-builder plus HF Jobs.

Published on July 6, 2026. See the kernels v0.16.0 release notes for preliminary guidance on setting up code signing.