eBPF is the most powerful enforcement tool in Linux. It runs below every application, every container, every platform. It has one problem: no one knows who authorized a program to run.
That sentence is a compliance audit finding waiting to happen.
What eBPF Actually Does
eBPF lets you load programs directly into the Linux kernel. These programs can intercept every file open, every network connection, every process execution — in real time, at kernel speed, with no application changes required.
The major security platforms have already figured this out. Cilium uses it for network policy. Falco uses it for threat detection. Tetragon uses it for runtime enforcement. The Linux kernel itself supports eBPF LSM hooks that run at the same level as SELinux and AppArmor — not on top of them, not beside them. Peer to them.
The architecture is genuinely elegant. Write a policy, compile it to BPF bytecode, load it into the kernel, and every process on the machine is subject to it. No agents. No restarts. No application modifications.
The Problem No One Has Solved
To load an eBPF program into the kernel, a process needs CAP_BPF — a Linux capability. That is the entire access control model. Anyone with that capability can load programs. Anyone who gains it illicitly can load programs. When a compliance auditor asks "who authorized this enforcement policy and when," the answer is: there is no answer. The kernel doesn't know. The audit log doesn't know.
This is not a corner case. In regulated industries — healthcare, finance, defense, energy — the requirement is explicit: every policy change must be attributable to a named, authorized human. HIPAA's audit controls. SOX's change management requirements. CMMC's configuration management domain. They all say the same thing: you must be able to prove who made the change.
eBPF gives you enforcement with no identity. That gap is a compliance failure.
What Gong Adds
Gong is a hardware signing key. Not a software token. Not a cloud credential. A key split across physical devices, where reconstruction requires physical presence and a button press.
When an operator uses Gong to authorize a compliance policy, the BPF bytecode gets a cryptographic signature tied to hardware the operator holds. The kernel loader verifies the signature before loading. The audit record says: this policy, at this time, was authorized by this hardware-verified human.
That sentence closes the audit finding.
The deployment model matters. Gong doesn't ask Epic to integrate it. Gong doesn't ask SAP to integrate it. Gong doesn't ask any of the entrenched platforms to do anything. It runs below them — the same way eBPF runs below applications — and enforces at the kernel boundary. The compliance layer wraps the entire system, including the platforms that have 10-year switching costs.
Who This Is For
The compliance officer at a hospital system is personally legally liable for HIPAA violations. Not the CISO. Not the IT director. The compliance officer. Their budget is non-discretionary. When something closes an audit finding, they buy it.
The same is true in financial services under SOX. In defense contracting under CMMC. In energy under NERC CIP. Every regulated industry has a human whose name is on the compliance attestation, and that human has a non-discretionary mandate to fix gaps.
The framing that matters: Gong doesn't ask them to replace their platform. It doesn't require a project. It ships in a box, installs in an afternoon, and produces the audit evidence that was missing.
The AI Policy Generation Loop
This is where it gets interesting for 2026.
Large language models are good at translating natural language requirements into policy code. A compliance officer writes: "no process should be able to open files in /etc/ssl without being in the 'ssl-access' group." An LLM generates the eBPF LSM hook that enforces it. The operator reviews it. The operator's Gong key signs it. It loads into the kernel.
The entire chain is auditable. The natural language requirement is a record. The generated policy is a record. The hardware-signed authorization is a record. The kernel load event is a record.
AI-generated policy is only as trustworthy as the authorization model behind it. An AI that can write enforcement policy is powerful. An AI that can write enforcement policy, get it hardware-signed by a legally accountable human, and deploy it to a kernel with a full audit trail — that is a compliance product.
The Piece That Was Missing
eBPF is ten years old. The enforcement capability has been there for a long time. The platforms built on it are mature. What was missing was the identity layer: a way to say, cryptographically, that a named human with hardware they hold authorized this specific policy.
That is a solved problem in other domains. Every bank transaction, every TLS certificate, every signed software release uses the same underlying math. It just hadn't been packaged for the compliance use case.
Gong is that packaging.