deso-pk/make-trust-irrelevantKernel-enforced authority and runtime security for AI agents, autonomous systems, and general Linux workloads.
TLDR: I built a kernel-level wall for untrusted agents, scripts, and compromised userland processes. The point is to make whole classes of unauthorized privileged effects fail closed under a stated threat model, especially the ones that work by inheriting authority or trust they were never actually granted. It's about the safe expansion of agentic ability, not restriction. If an action wasn't explicitly signed off through the trusted path, it doesn't run, no matter who's asking or how convincing the reason sounds.
KERNHELM is a kernel-level enforcement layer that sits between anything I don't fully trust (an AI agent, a script, a process that's been compromised and nobody's noticed yet) and any privileged effect that thing is actually trying to take. The current proof lane demonstrates that shape at file-object and execution boundaries. The broader design is the same wall extended to surfaces like network connections, process inspection, devices, and other privileged effects.
This is the part that makes it different from everything else. Almost all security ever built asks some version of who are you. Do you know the password? Are you an administrator? Is this key the right key? KERNHELM doesn't ask who. It asks why. Is this action actually something that was meant to happen, signed off by the one path allowed to sign off on anything, before it's allowed to touch the system at all. Knowing the password just proves you know the password. It says nothing about whether what's happening right now is supposed to be happening. So none of it goes through without a cryptographically signed permit coming from a completely separate path the requesting side has zero control over, which means it doesn't matter how good the reasoning sounded on the other side. The untrusted side never gets a vote in the first place.
And just so this doesn't read as vaporware: it's a provisional patent, filed back in February 2026, and it's already built and measured, with enforcement decisions landing at single-digit microseconds, small enough that it's very unlikely to matter for almost anything you'd actually run.
I built it because I'm done pretending that "the model probably won't do that" counts as an actual security model. That's not a defense, that's a hope, and I watched the entire industry dress that hope up in increasingly elaborate language and say its finished.
So instead of trying to get anything to behave, I went after something more basic: making misbehavior hit a mechanical authority boundary before it can do anything privileged, no matter what's doing the misbehaving, and no matter how convincing its reasoning was on the way in.
And here's the part that actually matters, the part most security framing gets backwards. This isn't about restricting what an agent can do. It's the opposite. Right now the only way people feel safe running an agent is to box it in, take tools away, keep it on a short leash, watch it constantly. They limit the agent because they can't trust the floor underneath it. KERNHELM makes the floor solid, and once the floor is solid you can let the agent do far more, not less. You can hand it real tools and real reach, because the worst case stops being catastrophic, it just becomes a denied request and a receipt. The wall isn't there to shrink what your agent is allowed to attempt. It's there so you can finally stop being afraid to let it attempt things.
This gets read as an AI safety project, which makes sense, because that's the loudest issue right now, but it's not really that, or at least it's not only that. My own filing doesn't even say "AI model" when it describes the threat. It says the thing being governed can be an LLM, an autonomous script, "or any other process whose behavior is not fully predictable," which is the actual target here. A model that's hallucinating and a rootkit that just found a foothold look exactly the same to this wall, because neither one of them gets a vote either way one hits it from the front of the wall the other the back but they all meet at the syscall.
And that breadth includes software that isn't even yours. If some provider builds an agentic AI product and you install it and let it run on your own hardware, that agent is just another untrusted requestor as far as the wall's concerned, no different from a script you wrote yourself. It still has to clear the same local check, against the same local stance, with the same signed-permit requirement, regardless of whose name is on the install or whose interests the software was originally built to serve. The provider doesn't get to grant their own product extra standing on your machine just because they wrote it. Kernhelm still decides.
Pretty much every approach I've run into tries to manage the actor somehow, whether that's a better sandbox, a smarter policy, better detection running on the input, or a human reviewing things more carefully when there's actually time for that. And all of that is real and worth doing, but none of it actually changes the shape of the underlying problem, which is that something downstream is trying to infer intent from the actor's own behavior in the moment, and behavior in the moment is exactly the thing a motivated attacker can manufacture on demand. It doesn't matter whether that attacker is a person who wrote one really clever sentence or a supply chain compromise that's been sitting quietly for three versions.
So at some point I stopped trying to read intent off the actor at the moment it acts, and started gating the effect instead. Intent still matters, it matters more than anything, but it gets established up front, by the real authority, and frozen into a signed permit. Nothing tries to guess it at runtime from how the thing is behaving. The right intent was already stamped in. The wall just checks the shape.
What that actually means is splitting the thing that wants to do something from the thing that's allowed to do something, and then putting a wall between those two that the wanting side has zero authority over, not because it got locked out today specifically, but because it was never handed a key to begin with.
It's worth being precise, because deciding what we actually want an agent to do, what values it should be serving, what context makes one action totally fine and the exact same action somewhere else a disaster, that's a human question, and it always has been. Nothing in this architecture tries to answer that question, and nothing here was ever meant to. Every single permit that gets minted traces back to an explicit decision a person made through a trusted authorizer (I call it Gate Clerk, more on that in a second). The wall doesn't decide what's worth wanting in the first place. That was never its job.
What it does remove is a second, separate trust requirement that shows up right after that first decision gets made. Because right now, once you've decided what you want, you also have to trust the agent to actually stick to it, every single time, against every possible phrasing an attacker hasn't even thought of yet. And that second trust requirement is the one that keeps failing in practice, because intent just doesn't survive contact with a system that's adversarial, or confused, or simply wrong about what it thought you meant.
