Most discussions about AI governance begin with models.
That makes sense. Models are where behavior appears to originate. They interpret requests, generate plans, select actions, and increasingly act on behalf of users. If something goes wrong, our instinct is to look at the model. We ask whether the reasoning was flawed, whether the plan drifted, or whether the system misunderstood the objective.
For a long time, we thought the same way. Then we deployed agents onto real machines. That experience changed how we thought about the problem. Because eventually every AI workflow, no matter how sophisticated, reaches the same place.
The operating system.
The moment the abstraction breaks
Imagine asking a coding agent to investigate a failing deployment.
The objective sounds straightforward. The agent examines logs, reads configuration files, reviews recent changes, and develops a plan. As it learns more, it refines its understanding of the problem. It identifies potential fixes, evaluates alternatives, and gradually narrows the space of possible actions.
At the planning layer, everything makes sense. You can inspect the workflow. You can review the reasoning. You can determine whether the proposed actions remain aligned with the original objective. The system appears understandable because the abstractions are still human-scale. We think in objectives, plans, and workflows, so the behavior remains explainable.
Then the plan reaches the machine. The elegant reasoning process disappears. The operating system sees something entirely different.
A file is opened. A process is created. A socket is established. A command is executed.
The plan that existed a moment ago has been translated into syscalls. And that is where the abstraction breaks. The agent understands intent. The kernel understands execution. Everything in between disappears.
The kernel has no concept of intent
One of the oldest lessons in systems security is that abstractions eventually collapse. A web application thinks in users and sessions. A container platform thinks in workloads and namespaces. A distributed system thinks in services and APIs. The kernel sees none of those things. The kernel sees processes, files, memory pages, sockets, capabilities, namespaces, and system calls. This has always been true.
The reason it matters for AI is that agents introduce an entirely new layer of abstraction above everything else. Agents think in objectives. They think in plans. They think in workflows. They reason about tasks in ways that are meaningful to humans. The operating system does not.
Suppose an agent decides it needs additional information to complete a task. At the planning layer, that sounds harmless. The objective may be entirely valid. The workflow may be perfectly aligned.
By the time the request reaches the kernel, however, the question has become something much more concrete.
Which file? Which process? Which network destination? Which namespace? Which system call?
The semantic distance between those two worlds is enormous. And that distance creates a control problem. Because a system can remain perfectly aligned at the planning layer while becoming unsafe at the execution layer.
The lesson computing keeps relearning
This is not actually a new problem. Computing has encountered versions of it repeatedly. Applications could not reliably enforce their own security boundaries, so operating systems emerged as the enforcement layer. Virtual machines could not reliably enforce cloud isolation, so hypervisors became the enforcement layer. Containers could not reliably govern themselves, so namespaces, cgroups, seccomp, SELinux, and AppArmor became the enforcement layer.
Every generation of computing eventually discovers the same thing. The final enforcement boundary lives lower in the stack than people initially expect. The reason is simple. The lower layers are harder to bypass. An application can ignore its own checks. A process cannot ignore the kernel. This pattern has repeated often enough that it feels almost inevitable. Until AI.
Because AI has reintroduced the same question in a new form. If an agent can generate its own behavior, where does the final enforcement boundary belong?
The investigation that led to KAP
When we first started working on agent assurance, we believed that plans and actions would be sufficient. If we could verify that an action belonged to an approved plan, and the plan remained faithful to the original objective, perhaps the problem was solved.
For a while, that felt right. Then we encountered situations where every action belonged to the plan and every plan remained aligned with the objective, yet the resulting execution still felt wrong.
The issue wasn’t that the agent had become malicious. The issue was that execution had escaped the assumptions of the planning layer. A workflow intended to gather information suddenly touched files nobody expected. A debugging task created processes nobody anticipated. A seemingly harmless operation established network connections that were technically allowed but operationally surprising. Nothing in the planning layer looked broken.
The problem emerged when intent encountered the operating system. The deeper we investigated, the more obvious it became that execution was its own control surface. Not another action. Not another plan. A distinct layer with its own failure modes.
That realization eventually became the Kernel Assurance Plane.
See it in action
The easiest way to understand this problem is to watch it happen.
In the following demonstration, the agent begins with a valid objective and a valid plan. Nothing appears unusual at the planning layer. The interesting part happens when the workflow reaches the operating system. Files are opened, processes are created, network connections are established, and execution begins interacting with resources the kernel actually understands.
The demo shows how KAP maps high-level authority into kernel-enforceable constraints and how execution can be evaluated against the authority chain that originally justified it.
What makes the demonstration interesting is not that the kernel blocks a syscall. Traditional security systems have been doing that for decades. The interesting part is that the kernel’s decision remains connected to the objective, intent, and plan that produced the execution in the first place. Once you see that connection, the rest of the architecture becomes much easier to understand.
Translating authority into execution
One of the challenges of building a kernel-level control system for agents is that the kernel does not understand plans. It never will. The kernel understands execution. That means the problem is not teaching the kernel what an objective means. The problem is translating authority into something the kernel can enforce.
A plan that authorizes reading project files must eventually become a set of filesystem constraints. A plan that authorizes network access must eventually become a set of network constraints. A plan that authorizes process creation must eventually become a set of execution constraints. The challenge is not observing execution after it occurs. The challenge is ensuring that execution remains connected to the authority chain that produced it. In other words, the question is no longer: Is this syscall valid? The question becomes: Does this syscall belong to the objective that ultimately justified it? That is a very different problem from traditional security. And it is one that existing operating systems were never designed to answer.
Every AI workflow eventually becomes syscalls
The AI industry is currently focused on models. That focus is understandable. Models are where behavior appears to originate. But every workflow eventually leaves the model. Plans become actions. Actions become execution. Execution becomes system calls.
At some point, every discussion about AI governance becomes a discussion about files, processes, sockets, memory, and operating systems. The abstraction eventually breaks. The machine remains. That is why we believe AI governance inevitably reaches the kernel. Not because kernels are particularly exciting. Not because operating systems suddenly became fashionable again. But because every meaningful control architecture eventually arrives at the same place. The last enforcement boundary.
The history of computing keeps teaching the same lesson. Whenever software becomes powerful enough to act independently, control eventually migrates downward until it reaches a layer that cannot be bypassed by the workload itself. AI agents are simply the latest example of that pattern.
The difference is that agents introduce something new into the equation: intent. For the first time, we are trying to preserve a chain of authority that begins with a human objective, flows through reasoning and planning, and eventually terminates in a syscall. The operating system was never designed for that world.
KAP is our attempt to bridge that gap.
Not by teaching the kernel to reason.Not by teaching it to understand plans. But by ensuring that execution remains accountable to the authority chain that produced it. Because eventually every AI decision becomes execution. And execution always belongs to the machine.
