When people talk about AI safety, the conversation almost always gravitates toward model inputs and outputs. We build prompt filters, jailbreak detectors, toxicity classifiers, output moderation systems, and increasingly sophisticated guardrails designed to intercept unsafe behavior before it reaches the user. On the other end of the pipeline, we invest heavily in observability. We collect logs, audit tool calls, trace workflows, and reconstruct execution after the fact.
Both approaches are valuable. Neither addresses where the most important decisions are actually made.
That observation did not come from reading papers. It came from watching agents operate. Again and again, we found ourselves investigating actions that looked perfectly reasonable once they appeared in a log. The API call was authorized. The database query was valid. The tool invocation followed policy. Nothing in the execution looked obviously dangerous.
And yet everyone in the room agreed that the agent had done the wrong thing. The uncomfortable realization was that the important decision had already happened. By the time the behavior reached the model’s output, or eventually an audit log, the system had already decided what the task meant. It had already determined which information was relevant, which tools were appropriate, and what it believed success looked like. The action was simply the visible consequence of a much longer chain of reasoning. The mistake was not in execution. The mistake was in refinement.
We kept investigating the wrong end of the problem
One of the first things we noticed while studying autonomous agents was how often investigations started at the end of the story. A database query appeared in the logs, so we inspected the query. A shell command executed, so we reviewed the command. An API call reached a production service, so we examined the request.
This is exactly how traditional security investigations work because, for traditional software, behavior is largely determined before execution begins. The workflow already exists. The software simply carries it out.
Agents quietly invalidate that assumption.
When an agent queries a database, the interesting question is rarely whether the query was allowed. Identity and access management already answer that. The more interesting question is why the system concluded that this particular database belonged inside the task in the first place.
That decision never appears in the audit log. The log records the consequence. It does not record the moment the agent decided what the task meant. This is why many forms of task drift, prompt injection, and authority expansion appear almost invisible to security systems. By the time an action becomes observable, the reasoning that justified it has already disappeared. The dangerous decision never reached the log.
Why guardrails struggle
The industry’s natural response has been to strengthen guardrails. If the model can be prevented from producing dangerous outputs, perhaps the problem is solved. Guardrails are undeniably useful. They prevent obvious jailbreaks, filter unsafe responses, and reduce a wide range of undesirable behavior. We should continue building them.
The difficulty is that guardrails operate on the same surface as model interaction. They inspect prompts. They inspect completions. They inspect what the model says. The failures frequently occur before the model ever produces something worth filtering.
Imagine asking an agent to prepare material for a board meeting. Nothing about that request is dangerous. As the agent begins working, however, it discovers additional documents, alternative information sources, related systems, and increasingly sophisticated ways of accomplishing the task. Each refinement appears reasonable. Each decision makes the plan more complete.
Somewhere during that process the agent quietly expands its authority. No malicious prompt appears. No dangerous output is generated. Nothing trips a traditional guardrail because the system never crossed the boundary those guardrails were designed to observe. The dangerous decision happened earlier. Long before the model produced its final answer.
The place where behavior is actually created
For a while, we believed the plan itself was the answer. After all, actions emerge from plans. If we could inspect the plan before execution, perhaps we had found the right control point. Then we encountered plans that were perfectly coherent and still wrong. The plans were internally consistent. They were technically valid. They solved exactly the problem the agent believed it had been asked to solve.
The difficulty was that the agent had quietly reinterpreted the objective while constructing the plan. The plan was not where the failure originated. The failure originated while the plan was still being created. That realization changed the way we thought about AI control.
Human beings rarely communicate in executable workflows. They communicate intentions, objectives, and outcomes. Everything between that initial purpose and the final plan is a continuous process of refinement. The agent resolves ambiguity, fills in missing details, discovers alternatives, and gradually transforms an incomplete human request into an executable workflow. That process is where the most consequential decisions are made. It is also the place where existing security architectures have almost no visibility.
Why we built the Purpose Assurance Plane
The more we investigated autonomous systems, the more often we found ourselves returning to the same observation. The interesting failures did not originate during execution. They originated while execution was still being invented. That realization eventually became the foundation of the Purpose Assurance Plane.
Rather than asking whether an action is allowed, PAP asks whether every refinement remains a faithful realization of the purpose that originally justified it. Instead of trying to perfectly infer human intent, it constrains the refinement process itself. As uncertainty decreases, the system becomes more specific about how it intends to solve the problem, but it never gains authority that was not already implied by the original objective.
The distinction matters. Plans are allowed to evolve. Workflows are allowed to adapt. The system is encouraged to become more intelligent as it gathers information. What is not allowed to evolve is the authority surface surrounding the task. That invariant turns refinement into something that can be governed deterministically rather than probabilistically.
Watch the refinement happen
The accompanying demonstration illustrates this idea in a way that is difficult to appreciate through diagrams alone.The agent begins with a high-level objective and gradually refines that objective into an executable workflow. As the task evolves, the system evaluates alternative plans, narrows the authority surface through progressive disclosure, and continuously validates that each refinement remains inside the cone defined by the original purpose. The resulting workflow reaches the same destination as a traditional planning system, but it does so while exposing dramatically less authority and maintaining a continuous chain of accountability.
🎥 Demo: Purpose Assurance Plane
The interesting part of the demonstration is not what gets blocked. It is what never becomes possible. Because the most dangerous AI decisions never reach model I/O. They never reach your audit logs. They happen while an agent is still deciding what your request actually means. That is the surface we built PAP to govern.
