Where does an agent actually touch the world?
In our previous blog, we argued that AI is creating a new generation of control principals. Purpose, intent, plans, delegation chains, and execution lineage increasingly determine what systems are allowed to become. The natural follow-up question is where those principals actually live.
At first glance, the answer seems obvious.
Agents interact with the world through tools. They query databases, invoke APIs, execute commands, access MCP servers, retrieve documents, and update records. Most of the industry’s security and governance efforts begin at exactly this point because these are the places where behavior becomes visible. Something changes in a database. A file is modified. A command executes. An API receives a request. These actions are concrete, observable, and measurable.
For decades, that visibility made them the natural place to establish control. The deeper we looked at agent systems, however, the less convincing that explanation became.
Imagine watching an agent submit a query to a database. By the time that query appears in a log, the system has already performed a remarkable amount of work. It has interpreted the user’s request. It has decided what information is relevant. It has explored possible approaches. It has selected one path over another. It has determined that a database query is necessary in the first place. The action that appears in the audit trail is often the final consequence of a much longer chain of decisions.
This is what makes agent systems fundamentally different from the software architectures most enterprise control systems were designed to govern.
Traditional software typically begins with a workflow. Someone defines the process, specifies the sequence of steps, and encodes the logic. The software’s responsibility is to execute that workflow reliably. Agents invert the relationship. They begin with an objective and construct the workflow as they operate. The plan emerges. The sequence of actions emerges. Even the interpretation of the task itself can evolve as the system encounters new information.
Once you view agent behavior through that lens, an uncomfortable realization begins to emerge. The places where actions become visible are not necessarily the places where behavior is created.
Behavior often begins much earlier.
It begins when the model reasons about a request. It continues while that reasoning is refined into a plan. It evolves as the plan encounters new information and adapts. Only then does it finally reach tools, databases, APIs, operating systems, and the external world.
The implication is subtle but important. If we only govern the places where behavior becomes visible, we are often governing the last step of a process rather than the process itself. By the time an action reaches a tool, most of the decisions that shaped that action have already happened.
That realization changed how we thought about control.
Agents do not interact with the world through a single surface. They touch multiple surfaces, each responsible for transforming uncertainty into increasingly concrete forms of behavior. Every one of those transformations introduces a different class of risk. Every one introduces a different opportunity for drift. And every one ultimately requires a different deterministic control primitive.
The ArmorIQ control stack emerged from that observation. Not because we set out to build four control planes. Because we kept discovering four fundamentally different places where agent behavior is created.
The first surface is reasoning
The first place an agent touches the world is not a tool. It is not a database. It is not an API. It is a thought.
That statement sounds abstract until you consider how much of an agent’s behavior is determined before a plan exists. Long before a tool is selected, the model is already making decisions. It is deciding which interpretations of a request seem plausible. It is deciding what information appears relevant. It is deciding which directions deserve exploration and which can be safely ignored. Every subsequent action emerges from those judgments.
This creates an unusual challenge.
Most control systems operate on things that have already become concrete. Permissions can be inspected because they are explicit. Actions can be verified because they are observable. Plans can be reviewed because they have structure. Reasoning exists before any of those things. It is the place where uncertainty is at its highest and structure is at its lowest.
The industry’s first instinct has been to govern reasoning with more reasoning. One model evaluates another. One agent supervises another. A reasoning process critiques a different reasoning process. The idea is appealing because it allows the control layer to evolve at the same pace as the workload.
The problem is that uncertainty does not disappear simply because another model has been inserted into the loop. A stochastic controller remains stochastic.
If the behavior we are trying to govern emerges from probabilistic reasoning, then another probabilistic system can help us observe that reasoning, classify that reasoning, or critique that reasoning. What it cannot do is transform uncertainty into determinism. The uncertainty remains inside the control loop.
This is not a criticism of AI. It is a property of control.
Throughout the history of computing, durable control planes emerged only when they stood outside the thing they were governing. We do not ask applications to define operating-system boundaries. We do not ask workloads to establish cloud isolation. Eventually the controller and the controlled separate.
Reasoning follows the same pattern.
The challenge is not making models deterministic. The challenge is creating deterministic constraints around reasoning itself. Before a plan exists, before authority is exercised, and before actions become visible, we need a way to determine whether the system is moving toward a state that remains consistent with the objectives and constraints that govern it.
This realization became the foundation of the Model Assurance Plane.
The goal is not to eliminate uncertainty from reasoning. Uncertainty is what makes these systems flexible and useful. The goal is to ensure that reasoning remains observable, classifiable, and bounded before it turns into plans and actions that affect the world.
Because once reasoning becomes behavior, it is already too late to ask where it came from.
The second surface is refinement
Suppose for a moment that we solve the reasoning problem. Suppose we can observe how a model is thinking. Suppose we can classify patterns of reasoning, detect undesirable behaviors, and establish boundaries around the kinds of conclusions the system is allowed to reach.
We still have a problem. Human beings do not communicate in executable plans. A manager does not wake up and tell an agent:
Query these three systems.
Analyze these five datasets.
Generate this report.
Schedule these meetings.
Instead they say:
Prepare me for the board review.
Or:
Help me understand why churn is increasing.
Or:
Investigate this incident.
What enters the system is not a plan. It is a purpose.
Somewhere between that purpose and an executable sequence of actions, an enormous amount of transformation occurs. The system interprets the request, resolves ambiguity, fills in missing details, constructs hypotheses, chooses approaches, and gradually turns a vague human objective into something operational.
This process is refinement. And refinement is where many of the most interesting failures in agent systems originate. Consider a request to investigate customer churn.
The objective sounds simple enough. The agent begins gathering information, identifying patterns, and constructing a plan. Along the way it discovers additional datasets, new tools, and alternative approaches that might improve the quality of its analysis. Every decision appears reasonable in isolation. In fact, many of the decisions are exactly the sort of initiative we want intelligent systems to demonstrate.
The problem is that intelligence and authority are not the same thing.
A system can become more certain about how to accomplish a task while simultaneously expanding the scope of what it believes it should be allowed to do. That is where task drift begins. It is also where many prompt-injection attacks succeed.
The attack is rarely a direct attempt to force an action. More often it is an attempt to influence refinement itself. The attacker gradually changes how the system interprets the task until new tools, new data, or new capabilities begin to appear justified. By the time the final action occurs, the plan may look internally coherent even though it has drifted far from the original objective.
This is what makes refinement such a difficult surface to govern.
The obvious solution would be to perfectly understand human intent and compare every refinement step against that understanding. Unfortunately, human intent is rarely complete enough for that approach to work. Objectives are ambiguous. Context is incomplete. Requirements evolve. Any attempt to fully infer intent simply creates another probabilistic problem.
The challenge therefore is not eliminating uncertainty. The challenge is constraining authority. At ArmorIQ, this observation eventually became the foundation of the Purpose Assurance Plane.
Rather than asking whether a system perfectly understands what a human meant, we ask a different question. As uncertainty decreases, what happens to authority? The answer should be simple. Authority should never expand.
A system may become more precise. It may become more certain. It may refine a vague objective into a detailed plan. But the process of refinement should not introduce new capabilities, new interfaces, or new authority that were not already justified by the original purpose.
This creates something surprisingly powerful. We do not need to fully solve human intent in order to govern refinement. We only need to ensure that the system becomes more specific without becoming more powerful.
That single constraint turns refinement from an unconstrained generative process into something that can be governed deterministically. And once refinement is bounded, we can finally ask a different question. Suppose the plan is valid.
How do we know the actions that follow actually belong to it?
The third surface is tools
Suppose we have successfully constrained refinement. The system begins with a purpose. It transforms that purpose into a plan. The plan remains bounded. Authority does not expand unexpectedly. The workflow remains consistent with the original objective.
At this point, it is tempting to think the difficult part is over. In reality, we have only arrived at the place where most existing security architectures begin. The plan eventually reaches tools.
A database query is executed. An API is invoked. A file is read. A command is run. A workflow touches the outside world. This is the point where behavior becomes visible.
It is also the point where most organizations feel comfortable because they already have decades of experience governing these interactions. Identity systems determine who is allowed to access a resource. Access-control systems determine whether a request should be permitted. Policy engines evaluate conditions and produce decisions. Audit systems record what happened afterward.
These controls remain essential. The challenge is that they answer a different question. Identity answers: Who is acting? Authorization answers: What are they allowed to access? Neither answers:
Why is this action happening right now?
That distinction seems subtle until you examine how agent systems actually fail. Consider an agent with access to a customer database. The credentials are valid. The query is authorized. The database policy allows the request. Every traditional control evaluates the action and concludes that it is acceptable.
And yet the query may still have no legitimate connection to the task the agent was originally asked to perform. The credentials are correct. The purpose is not. This is the intent-validity gap.
It appears whenever an action is authorized but no longer aligned with the objective that justified it. Prompt injection often lands here. Tool misuse often lands here. Task drift frequently becomes visible here. The system remains technically compliant while gradually moving away from the purpose that originally authorized the workflow.
The obvious response is to capture the plan and store it somewhere. Unfortunately, recording intent is easy. Enforcing intent is hard.
A stored plan does not constrain execution. A logged objective does not prevent drift. Observability alone cannot establish control. The difficult problem is creating a deterministic relationship between the plan and the actions that follow from it.
That realization became the foundation of the Intent Assurance Plane. The central question is surprisingly simple: Can every action prove that it belongs to the plan that authorized it?
If the answer is no, then the action should not execute.
This sounds straightforward until you consider the complexity involved. Plans evolve. Work is delegated. Subtasks emerge. New context appears. The relationship between a plan and an action must survive all of those transformations while remaining verifiable in real time.
This is why the Intent Assurance Plane relies on cryptographic structures rather than probabilistic judgments. Plans become structured execution graphs. Intent is committed cryptographically. Delegated work remains connected to its parent authority chain. Every action carries evidence that it belongs to the reasoning path that produced it.
The objective is not merely to observe execution. It is to make execution accountable to the plan itself. And once actions become accountable to plans, a new question emerges. Suppose the action belongs to the plan. Suppose the plan belongs to the purpose. What happens when execution reaches the operating system itself?
The fourth surface is execution
At this point, it feels as though the problem should be solved. The reasoning is bounded. The refinement process remains constrained. Every action can prove that it belongs to the plan that authorized it. The chain from purpose to execution remains intact.
What more is left to govern?
The answer becomes obvious the moment an agent reaches a real machine. Sooner or later, every agent leaves the world of plans and enters the world of execution. A database query becomes a process. A file operation becomes a system call. A network request becomes a socket. An action that looked abstract a moment ago becomes something the operating system must ultimately execute.
This is where the history of computing becomes surprisingly relevant. Every major generation of software eventually discovers the same lesson: applications cannot reliably enforce their own boundaries.
For decades, security architectures repeatedly converged on the same conclusion. User-space software could express intent, but the operating system ultimately determined what was possible. Filesystem permissions, process isolation, memory protection, namespaces, containers, SELinux, AppArmor, seccomp, cgroups, and countless other mechanisms all emerged from a simple observation.
The final enforcement boundary lives in the kernel. The AI industry is beginning to rediscover that lesson.An agent may have a valid purpose. Its plan may be consistent with that purpose. Every action may be properly connected to the plan that authorized it. And yet execution can still escape if the operating system has no understanding of the authority chain that produced the action.
Imagine an agent whose plan authorizes reading a configuration file. At the planning layer, everything appears correct. But by the time execution reaches the operating system, that intent has been translated into file descriptors, processes, network connections, and system calls. The kernel sees execution. It does not see purpose.
That gap matters. Because purpose exists at one layer of abstraction while operating systems execute at another.
Historically, we solved this problem by assuming the application was responsible for remaining within its own boundaries. Experience repeatedly showed that assumption was insufficient. The operating system eventually became the place where those boundaries were enforced.
Agents are forcing the same transition. The challenge is no longer determining whether a plan is valid. The challenge is ensuring that execution remains bounded by the authority chain that produced the plan. A valid workflow should not suddenly gain access to new files. A delegated task should not acquire capabilities that were never delegated. A process should not be able to escape the scope of the purpose that originally justified its existence.
This is the motivation behind the Kernel Assurance Plane. KAP exists because execution is not simply another tool. Execution is the point where behavior becomes reality.
At that layer, probabilistic supervision is no longer enough. The operating system must be able to enforce deterministic constraints that remain connected to the purpose, intent, and plans that came before it. The authority chain cannot end at the tool layer. It has to survive all the way down to the machine itself.
The interesting thing about KAP is that it completes a pattern that appears throughout the history of computing. Every important control boundary eventually moves downward until it reaches a place that cannot be bypassed. For agents, that place is the kernel. And once execution itself becomes governable, a larger picture finally comes into focus.
The four surfaces we have discussed are not independent solutions to independent problems.They are four deterministic control planes surrounding a fundamentally stochastic system.
Why one control plane is not enough
At first glance, the existence of four separate control planes can feel excessive.
After all, the industry has spent decades building systems that consolidate control. Identity became a centralized service. Policy became centralized. Governance became centralized. We naturally expect the same pattern to apply here. Why not build a single AI governance layer? Why not use a sufficiently advanced model to supervise plans, actions, execution, and behavior all at once?
The deeper we explored agent systems, the less convincing that approach became. The reason has very little to do with AI and everything to do with control. Each surface we have discussed introduces a different kind of uncertainty. Reasoning uncertainty is different from refinement uncertainty. Refinement uncertainty is different from execution uncertainty. Execution uncertainty is different from operating-system uncertainty. They appear at different layers, operate on different artifacts, and fail in different ways.
A plan can be perfectly valid while the reasoning that produced it is flawed. A tool invocation can be perfectly consistent with a plan that should never have existed. Execution can remain faithful to a valid action while still escaping the authority boundaries that originally justified it.
These are not variations of the same problem. They are different problems that happen to appear in the same system. The industry’s first instinct has been to solve these problems using more AI. A model evaluates another model. An agent supervises another agent. A reasoning system critiques another reasoning system. The idea is attractive because it promises a single adaptive layer that can evolve alongside the workload it governs.
The difficulty is that uncertainty does not disappear simply because another stochastic system has been inserted into the loop. If a system has a probability less than one of making the correct decision, and the controller is also a system with a probability less than one of making the correct decision, the resulting system does not magically become deterministic. The uncertainty remains inside the control loop. In many situations, it compounds.
The exact numbers are less important than the intuition. A stochastic controller remains stochastic. This is not a criticism of AI. It is a lesson that computing has learned repeatedly. Applications do not define operating-system security. Workloads do not establish cloud isolation. User code does not determine the security boundary. Every durable control plane in computing emerged when the controller became independent of the thing being controlled.
AI is following the same pattern. The conclusion is not that models are unreliable. The conclusion is that control must become deterministic even when the workload remains probabilistic. That realization is what ultimately shaped the ArmorIQ stack.
MAP constrains reasoning before it becomes plans.
PAP constrains refinement before it becomes authority.
IAP constrains actions before they become execution.
KAP constrains execution before it becomes effect.
Each plane exists because a different kind of uncertainty appears at a different surface. Together, they form something larger than a governance framework. They form a deterministic control fabric around a fundamentally stochastic system. And that distinction may ultimately define the next generation of AI infrastructure.
The control plane that AI makes inevitable
When people look at the ArmorIQ stack for the first time, they sometimes assume it represents four separate solutions to four separate problems. That isn’t really what is happening. The stack exists because agents force us to confront a reality that previous generations of software largely avoided.
Behavior is no longer created in one place.
A traditional application might contain millions of lines of code, but the important decisions were still largely embedded inside the software before execution began. The challenge was making sure execution remained correct. Agents change that relationship. Behavior emerges gradually as objectives become interpretations, interpretations become plans, plans become actions, and actions become effects. By the time the outcome appears in the world, the system has already passed through multiple layers of uncertainty.
The reason ArmorIQ contains multiple control planes is that uncertainty itself changes shape as it moves through the system. At the reasoning layer, uncertainty appears as competing interpretations of a request. At the refinement layer, uncertainty appears as ambiguity about how an objective should be transformed into an executable plan. At the action layer, uncertainty appears as questions about whether a tool invocation truly belongs to the workflow that authorized it. At the execution layer, uncertainty appears as the possibility that behavior escapes the authority chain that originally justified it.
Each layer introduces a different opportunity for drift because each layer transforms behavior in a different way. That observation leads to a conclusion that feels increasingly difficult to avoid.
The future of AI will not be defined solely by models.
Models will continue to improve. Context windows will expand. Reasoning capabilities will advance. Agents will become more capable, more autonomous, and more deeply integrated into the systems around us. None of those developments eliminate the control problem.
In many ways, they amplify it.
The more capable an agent becomes, the more important it becomes to understand not just what it is doing, but how it arrived there. The more authority we delegate to autonomous systems, the more important it becomes to ensure that authority remains bounded as the system interprets objectives, constructs plans, and interacts with the world.
This is why we believe AI is forcing the emergence of a new generation of infrastructure. Not infrastructure built around models. Not infrastructure built around prompts. Infrastructure built around control.
The history of computing is full of moments where a new abstraction becomes important enough that an entirely new control plane emerges around it. Identity created identity infrastructure. Cloud computing created orchestration infrastructure. Distributed systems created service meshes and workload identity.
Agents are creating the next such moment.
The new control principals are purpose, intent, plans, delegation chains, and execution lineage. The new challenge is maintaining deterministic control over systems whose behavior emerges from probabilistic reasoning. And the new infrastructure will be built by the organizations that learn how to govern that transformation from beginning to end.
That is the problem ArmorIQ was created to solve. Not by making agents less intelligent. Not by making them less flexible. But by ensuring that as behavior emerges, evolves, and eventually reaches the real world, control remains present at every surface the agent touches.
