Over the last three posts, we have been building toward one question:
Can an AI agent’s execution remain bound to the objective that caused it to exist, even as the agent changes, delegates, suspends, and resumes?
In Part 1, we introduced the Intent Container: a runtime object built around an objective rather than a process or agent.
In Part 2, we followed that objective down the stack. PAP decides and bounds justified authority as human purpose becomes an operational objective and is refined. IAP commits the accepted plan and proves its execution lineage cryptographically. intentd maintains the current Intent Container state and carries that assurance state across runtime boundaries. In our first reference implementation, KAP enforces the resulting authority in the Linux kernel against actual execution. PAP’s refinement model is specifically designed to prevent authority from silently expanding as an agent turns purpose into executable behavior, while IAP provides the cryptographic lineage connecting the accepted plan to its actions.
In Part 3, we added time. An agent can be checkpointed, revoked while asleep, and later restored from an old snapshot. That gave us an important invariant: Execution state can travel backward in time. Authority cannot. Now we can show the pieces working together.
What we wanted the demo to prove
There are plenty of ways to build an impressive agent demo. We deliberately chose not to. We wanted this demo to prove one narrow systems property:
An autonomous Actor remains bound to the current authority of the objective that caused it to exist.
That means we need to demonstrate more than blocking a command. The objective has to exist before the Actor. Authority has to enter the execution environment before the workload becomes active. The kernel has to enforce it independently of the agent. That authority has to survive a legitimate suspend and resume. Revocation has to invalidate previously valid execution. And an old snapshot must not be able to resurrect old authority. The target sequence is intentionally simple:
Objective → Actor → bind → allow → deny → suspend → resume → revoke → stale snapshot refused at restore.
Each transition tests a different part of the Intent Container abstraction.
The stack
The demo combines several pieces we have discussed throughout this series. At the top is the objective and the ArmorIQ assurance layer. PAP bounds justified authority. IAP provides the committed plan and proven execution lineage. intentd creates and maintains the current Intent Container state around that objective. Google’s Agent Substrate is our first reference runtime adapter and manages the Actor lifecycle. The Actor executes inside a Kata microVM. Inside that microVM is our KAP reference enforcement backend. Before the workload executes, the Actor is bound to its objective-derived authority. Conceptually, the path looks like this:
Human Purpose
↓
PAP / IAP
↓
intentd
Intent Container
↓
Agent Substrate
↓
Kata microVM
↓
KAP guest kernel
↓
Actor workload
The important architectural separation is that none of these components needs to become the others. Google Agent Substrate manages Actors in this reference runtime. Kata provides the isolated execution environment. intentd maintains current objective state. IAP commits and proves the cryptographic execution lineage; its model explicitly supports commitment, re-anchoring, scoped delegation, and revocation rather than treating the initial authorization as permanent. KAP enforces the resulting authority when agent decisions finally become kernel-visible operations. Other runtime adapters and policy enforcement points can consume the same Intent Container authority without adopting KAP.
Watch the Intent Container lifecycle
Intent Container on Agent Substrate: Objective → Actor → kernel enforcement → suspend/resume → revocation → stale snapshot refused at restore
The rest of this post walks through what is happening underneath each moment in the video.
First, the objective creates the boundary
The Actor does not start with ambient authority and acquire intent metadata afterward. The order matters. We begin with human purpose and an operational objective. PAP establishes and bounds the justified authority. IAP commits the accepted plan and proves its execution lineage. intentd creates an Intent Container carrying the current objective and assurance state. When Google Agent Substrate creates the Actor in this reference implementation, the enforcement material follows the objective into the Actor’s environment. Before the real workload becomes active, the guest binds it to its KAP intent group.
At this point, we can inspect the environment and establish that this is not simulated policy enforcement in an application wrapper. The Actor is actually executing under the KAP-enabled guest kernel, and the objective’s authority has been installed at the kernel boundary. Only then does the workload run. The distinction is important:
The Actor does not declare its own authority. It enters execution under authority established outside itself.
Then we let the agent do something legitimate
The first execution is deliberately boring. The Actor performs an operation included in its committed authority. KAP sees the operation, matches it against the installed predicates, and allows it. Nothing unusual happens.
That is precisely what we want. Security systems become unusable very quickly if legitimate agent execution turns into a ceremony. Once the objective has been committed and installed, normal execution should remain normal. The interesting part comes with the next action.
The agent tries something outside the objective
Now the Actor attempts an execution that is not part of its installed authority. The model may believe the command is useful. The agent framework may happily request it. The process is legitimate. The Actor is legitimate. The sandbox itself may permit the binary to exist.
KAP still denies the execution. The result is EACCES from the kernel. That distinction is the heart of KAP.
We are not asking the model whether the operation is appropriate. We are not putting another natural-language instruction into the context telling the agent not to perform it. And we are not waiting for an audit system to discover the violation afterward.
The probabilistic system proposes an action. The deterministic boundary decides whether that action can become an effect.
Now put the agent to sleep
Next we suspend the Actor.
Agent workloads make this particularly interesting because suspension may be normal rather than exceptional. An agent can spend significant time waiting for another Actor, a user, an external event, or some future continuation.
The Kata microVM is checkpointed. Later, we resume it. Because the guest kernel state was part of the checkpoint, the Actor’s KAP intent group and lineage survive. The Actor returns to execution and the same authority boundary remains active.
We repeat the allowed operation. It succeeds. We repeat the disallowed operation. It remains denied. The Actor moved through time without losing its connection to the objective.
Then we revoke the objective
Now we change the world outside the Actor. The objective is revoked. This is where objective-level authority becomes different from sandbox configuration. We do not need to rebuild the Actor’s container image. We do not need to change its identity. We do not need to convince the model that it should stop.
The current authority associated with the objective changes. An operation that was previously valid is attempted again. This time, it fails. Same Actor. Same process lineage. Same execution environment. Different objective authority. That is the property we care about.
Finally, we try to bring yesterday back
The final step is the one that motivated Part 3 of this series. We take a snapshot created before revocation. At the time that snapshot was created, its authority was valid. Its kernel state reflects that fact. After the objective is revoked, the runtime is asked to restore it. A conventional restore mechanism would have every reason to accept the snapshot. It is authentic execution state created by the platform.
Today, the refusal happens in the restore path itself. The guest records its authority epoch to durable shared storage. After the restored volumes are available but before the VM starts, the host compares that saved epoch with current Intent Container authority. If the snapshot says epoch 1 while the objective says epoch 2, the restore is refused before the Actor becomes active. Because the check sits on the restore path, a direct wake through kubectl or Agent Substrate reaches the same boundary.
The snapshot is valid. The authority is not.
What the demo actually proves
It would be easy to describe this as a KAP demo because the denied syscall is visually satisfying. But that undersells what we are trying to show. KAP is one enforcement option and our reference backend for this demo. The current demo proves continuity through a normal suspend and resume, and it shows that a pre-revocation snapshot is refused at restore when its saved epoch is stale. The same objective survives several transformations:
Objective
↓
Committed intent
↓
Intent Container
↓
Actor
↓
Kernel execution
↓
Checkpoint
↓
Restore
Across the lifecycle, execution remains accountable to the current objective. The restore path now reconciles saved execution state with current authority before the Actor becomes active. That is what makes the Intent Container more than simply an agent sandbox with another security policy attached.
A sandbox answers:
Where may this Actor execute?
The Intent Container answers:
Why is this Actor executing, and what is it still authorized to do?
Agent Substrate is our first reference runtime
Another part of the demo that may be less visually obvious is equally important architecturally. We are not trying to replace Google’s Agent Substrate. The first intentd implementation is intentionally layered on top of it as a reference adapter, not as an architectural dependency.
Agent Substrate already gives us the Actor abstraction and lifecycle machinery. Kata and Cloud Hypervisor give us the microVM execution environment. The KAP-enabled guest kernel can enter through Kata’s existing kernel configuration rather than requiring Agent Substrate to understand a special ArmorIQ kernel.
The remaining integration surface can therefore stay small and generic. The substrate needs a way to carry opaque enforcement material into an Actor and a lifecycle point where enforcement can be established before activation. Restore needs to be able to reconcile saved execution state with current authority. In the current reference path, that check runs after the restored volumes are available but before the VM starts: the host compares the durable saved epoch with current authority and refuses a mismatch before execution resumes. Other runtimes need the equivalent lifecycle point.
ArmorIQ-specific intent semantics can remain outside the core. That is important because the Intent Container should survive changes in the underlying runtime. Google Agent Substrate is first, but the same adapter pattern can work with AWS AgentCore, Microsoft agent runtimes, Kubernetes or Lynx, SaaS services, and local execution without baking intentd into any one framework.
This is still the beginning
The demo proves a narrow version of the Intent Container. There is much more we want the abstraction to carry.
An objective can have a budget shared across many Actors and model calls. It can have data boundaries that follow execution across MCP servers. Delegated Actors can receive narrower authority derived from their sub-objectives. Model restrictions can belong to the objective rather than individual API calls. Revoking an objective can eventually terminate an entire distributed execution tree.
And there are deeper enforcement questions still ahead. The current prototype establishes the lineage before execution and carries it into the kernel. There is more work to do around richer delegation, distributed objective state, stronger cryptographic verification deeper in the enforcement path, performance characterization, and integration with the broader agent-runtime ecosystem. We will cover those pieces separately rather than turning this series into one giant architecture document.
From a demo to an infrastructure primitive
The first post in this series started with a question: What exactly are we trying to contain?
Four posts later, our answer is becoming more concrete. The Actor needs a sandbox. But the Actor is only one temporary realization of something longer-lived. The objective may create several Actors. It may cross models and tools. It may sleep and resume. Its execution environment may disappear completely and later return.
The objective is the thing that persists. That is why we think it deserves its own runtime boundary. The sandbox contains the Actor. The Intent Container contains why the Actor exists.
intentd gives that objective a lifecycle.
IAP gives it verifiable lineage. KAP gives its authority a reference OS-level enforcement point when intent finally becomes execution. Other policy enforcement points and runtimes can enforce the same Intent Container authority at their own boundaries. And the demo above is our first step toward making that abstraction real.
We are building intentd in the open and would like to work with others thinking about agent runtimes, Agent Substrate, Kata, Linux security, workload identity, delegation, and autonomous infrastructure.
Watch the demo. Break the abstraction. Tell us what is missing. Better yet, help us build the next version.
