Why Autonomous Systems Need Intent Verification

A category-definition paper for a new authority layer for autonomous agents, physical AI, and real-world machine action.

Intended White Paper · Public Draft Version 2.0 · June 2026

Authority infrastructure for autonomous systems.

Abstract. Every prior layer of enterprise control became infrastructure the moment an assumption it depended on stopped holding. Identity became infrastructure when systems could no longer assume a known actor. Authorization became infrastructure when access had to cross organizational boundaries. Observability became infrastructure when systems grew too complex to reason about by inspection. Each was, at first, a concept that skeptics dismissed as a feature of something else — until the underlying shift made it undeniable, and it acquired a name, a standard, and a market. Autonomous systems are now forcing the same reckoning with a capability that has never had its own layer: the verification that an action matches what was intended, before it executes. Identity establishes who is acting. Policy establishes what is permitted. Safety establishes whether an action is dangerous. Observability establishes what happened. None of them establishes whether a proposed action means what was intended in context, before it runs. That unanswered question is the Intent Gap. This paper argues that Intent Verification is a distinct infrastructure category — not a feature of identity, policy, safety, governance, or observability — that it is becoming mandatory rather than optional, and that Open Intent is the neutral vocabulary the category requires. Intended is the first implementation of that category. The category is the subject of this paper; the company is incidental to it.

Table of Contents

1. Executive Summary
2. Introduction — The Moment Software Started Acting
3. Why This Problem Appears Now
4. The Autonomous Action Explosion
5. The Largest Ungoverned Surface Area in Enterprise History
6. The Autonomous Refund — A Worked Example
7. Part I — The Assumption That Broke
8. Part II — The Existing Stack Fails
9. Part III — The Intent Gap
10. Part IV — Intent Verification as a Runtime Primitive
11. From Access Control to Action Control
12. Part V — Why Identity Is Not Intent, and Other Category Confusions
13. What Intent Verification Does Not Solve
14. Part VI — Physical AI Makes This Non-Optional
15. Part VII — Why Intent Requires a Shared Vocabulary
16. Why Open Intent Alone Is Not Enough
17. Part VIII — The Cost of Unintended Action
18. Why Enterprises Will Buy This
19. Part IX — The Three Layers: Vocabulary, Interpreter, Enforcement
20. Part X — Failure Modes and Design Principles
21. Part XI — Common Objections
22. Part XII — Implications for Autonomous Systems
23. Why Intent Verification Becomes Mandatory
24. Conclusion — Who Defines the Layer
25. Figures
26. Glossary

Executive Summary

For most of the history of computing, software did what it was told. A person or a deterministic program decided what should happen, and the machine carried out the instruction. The intent behind an action lived outside the system — in the operator, the workflow author, the engineer who wrote the code. Infrastructure could therefore make a quiet but load-bearing assumption: that whoever or whatever invoked an action had already decided it was the right action to take.

Autonomous systems break that assumption. An AI agent, a tool-using model, or a robotic system does not merely execute a predetermined instruction. It interprets a goal, considers options, selects tools, and initiates actions on its own. The intention is no longer supplied intact from outside the system. It is constructed inside it, at runtime, and then acted upon — often in milliseconds, often with no human in the path.

This shift creates a new control problem, and the existing control stack cannot solve it. Each established layer answers a necessary question. Identity answers who is acting. Authorization and policy answer whether an action is permitted. Safety answers whether an action is dangerous. Observability and audit answer what happened. These layers are essential, and nothing here proposes replacing them. But they share a blind spot, and the blind spot is structural rather than incidental: none of them verifies whether a proposed action matches what was intended in context, before that action executes.

A permitted action can still be the wrong action. An agent with valid credentials, acting inside policy, producing safe output, can still do something no one intended — because permission describes a boundary, not a purpose. Permission governs access; intent governs action. The space between what an autonomous system is permitted to do and what it was intended to do is the Intent Gap. As systems move from recommending actions to taking them, that gap stops being a theoretical concern and becomes an operational and financial liability.

We make four claims, in order of increasing consequence. First, autonomous systems create a genuinely new control problem, because they originate actions rather than execute supplied ones. Second, no existing layer closes it; the Intent Gap is not a weakness in any single control but the union of what each, by design, leaves out. Third, the problem deserves its own category — Intent Verification — defined as the runtime process of determining whether a proposed autonomous action matches the declared purpose, process, and operational context before execution. Fourth, the category requires a neutral shared vocabulary — Open Intent — so that actions can be named, compared, verified, and audited across vendors and domains.

In practice, Intent Verification is a stack of three layers, and the distinction among them is the spine of the architecture: Open Intent is the vocabulary, the Large Intent Model is the interpreter, and the Authority Runtime is the enforcement layer. Open Intent gives autonomous systems a common language; the Large Intent Model gives them a common understanding; the Authority Runtime turns that understanding into an enforced decision. A vocabulary names actions, but it cannot understand them — and authority requires understanding, not just a name. The interpreter is the layer where meaning becomes governable, and it is process-aware: it places each action within the business process it is meant to advance, because intent is meaningless without context, and business process is the context. None of the three layers substitutes for the others, and all three are required. Taken together, they constitute a category we name precisely for the analysts and architects who will have to classify it:

Intent Verification Infrastructure is the collection of vocabulary, interpretation, authority, enforcement, and evidence systems required to determine whether an autonomous action matches what was intended before execution.

One sentence captures the shift the category answers, and it is worth fixing in mind before the argument begins: autonomous systems made action programmable; Intent Verification makes action accountable.

Intent Verification produces a runtime decision about authority: the verified right for a specific action to execute in a specific context. Authority is not assumed. Authority is granted, after intent has been verified, and carried to the point of execution as a cryptographic Authority Token — single-use, scoped, time-bound, and independently verifiable. If intent verifies, authority is issued and the action proceeds. If not, execution is denied, escalated, or routed for approval, and the decision is preserved as tamper-evident evidence. The operating rule is simple: no token, no action.

Physical AI removes the option of ignoring the gap. In software, a permitted-but-unintended action produces a financial loss, an operational error, or a compliance exposure. In the physical world — a robot moving a pallet, a cobot reaching into a shared workspace, an autonomous vehicle initiating motion — the same class of mistake produces a safety event. Safety systems ask whether an action is dangerous. They do not ask whether the action should happen at all. A perfectly safe action can still be the wrong action, and the gap between "safe" and "intended" is precisely where authority must sit.

This is not a manifesto about a company. It is a category-definition document about a layer. The pattern is familiar: identity, authorization, observability, and safety each began as a contested idea and became mandatory infrastructure once the world shifted beneath them. Intent Verification is following the same path, on a shorter timeline, driven by the move from software that executes commands to software that originates actions. The next infrastructure challenge is not whether autonomous systems can act, but whether they can prove they acted as intended. Intent Verification is the layer that makes that proof possible. Intended is its first implementation.

Key Takeaways

• Autonomous systems originate actions rather than execute supplied ones, creating a control problem the existing stack was not built to solve.
• Identity, policy, safety, and observability are necessary but each, by design, leaves the match between action and intent unchecked — that union is the Intent Gap.
• A permitted action can still be the wrong action; in the physical world, the same gap becomes a safety event.
• Intent Verification is a distinct infrastructure category, and a stack of three required layers: Open Intent (vocabulary), the Large Intent Model (interpreter), and the Authority Runtime (enforcement). None substitutes for the others.
• Like identity and observability before it, Intent Verification is on the path from contested idea to mandatory layer; Intended is its first implementation.

Introduction — The Moment Software Started Acting

Every layer of modern infrastructure encodes an assumption about who is in control. Those assumptions are usually invisible, precisely because they have held for so long. Authentication assumes there is an actor whose identity can be established. Authorization assumes a defined set of permissions to check a request against. Application logic assumes the steps it executes were chosen in advance by a developer, or specified at the moment of use by a person. For decades these assumptions were not merely convenient. They were true.

In that world, the question of intent — what an action was meant to accomplish, and whether a given action actually accomplishes it — was answered outside the machine. A user clicked a button because they had decided to act. A workflow ran a sequence because an engineer had decided the sequence was correct. A scheduled job moved data because someone had determined the data should move. The software did not verify intent because the software did not originate intent. It inherited intent from a human or a deterministic specification and executed faithfully. Faithful execution was the whole job.

Autonomous systems change the origin of intent. An agent built on a large language model is given a goal, not a script; it decides which tools to call, in what order, with what arguments. A robotics system driven by a learned policy or an AI planner is given an objective and a perception of its environment, and it generates the motions to satisfy that objective. In both cases the specific action that reaches the world was not written down in advance by a person. It was produced by the system, at runtime, from a goal and a context. The action path is no longer entirely predetermined.

This is not a criticism of autonomy. Translating goals into actions is exactly what makes these systems valuable. It is, however, a structural change in where intent is formed — and therefore in where intent can be verified. When a human formed the intent, the human was the verifier: a person could decide, before acting, whether the action matched the objective, whether an exception applied, whether to proceed at all. When the system forms the intent, that verification step does not vanish because it is unnecessary. It vanishes because nothing in the existing stack was built to perform it.

Consider a set of ordinary actions an autonomous system can now initiate: approving an invoice, deploying a code change, issuing a refund, moving a pallet, flying a route, reaching into a shared workspace. Each can be entirely legitimate. Each can also be entirely wrong — not because the system was compromised, not because a policy was violated, not because the action was unsafe in isolation, but because the action did not match what was actually intended. The invoice was a duplicate. The deployment targeted the wrong environment. The customer asked for a replacement. The pallet was the wrong pallet. The route crossed a restricted zone. In every case, the system did something it was permitted to do, and in every case it did the wrong thing.

The thesis of this paper is a statement about division of labor. Identity verifies who is acting. Intent verifies what the action means. These are different questions requiring different machinery. The first has mature infrastructure — decades of work on authentication, federation, and identity governance. The second has almost none. As long as humans formed intent, the absence of intent infrastructure was unremarkable, because the human was the infrastructure. Once systems form intent and act on it directly, that absence becomes the defining gap in the stack. Once systems choose actions, control must move from static permission to verified intent.

Key Takeaways

• Infrastructure encodes the assumption that intent is supplied from outside the system; it held because humans formed intent and software executed it.
• Autonomous systems form intent at runtime, moving its origin inside the system and removing the human verification step.
• The same action can be legitimate or wrong depending on whether it matches the intended purpose — and existing controls do not check that.
• Identity verifies who is acting; intent verifies what the action means. The first has mature infrastructure; the second has almost none.

Why This Problem Appears Now

A reasonable skeptic will ask why, if the Intent Gap is real, it has not been a problem all along. The answer is that the conditions that create it are recent, and they are arriving together. The Intent Gap is not a latent flaw that was always present and merely overlooked. It is a new consequence of a specific change in how software operates — the change from software that executes commands to software that originates actions. That change is not a single event but a stack of converging trends, each of which widens the gap.

Tool use. The first shift was giving models the ability to act, not merely to generate text. Once a model can call a function — issue an API request, write to a system, trigger a workflow — its output stops being a recommendation a human reviews and becomes an action that executes. The moment a model's output is wired to a tool, the question of whether its proposed action matches intent becomes a runtime question, not a conversation.

Agentic systems. Tool use composes into agency. An agent does not take one action; it plans and executes a sequence, choosing each step from context. Every step is an opportunity for the Intent Gap to open, and the human who might once have checked each step is, by design, no longer in the loop for each step. Autonomy's value is precisely that it removes the per-step human — which is precisely what removes the per-step intent check.

Multi-agent systems. Agents increasingly invoke other agents. An action proposed by one agent may be triggered by the output of another, across tools and vendors, with no single point at which a human or a shared control evaluates whether the resulting action matches the originating intent. Meaning has to survive being passed between systems, and nothing in the current stack carries it.

Autonomous workflows. Enterprises are wiring agents into the operational core — finance, IT, support, supply chain — where actions have consequences measured in money, uptime, and obligation. These are not demos. They are production paths in which an unintended action is a real loss.

Physical AI and robotics. Foundation-model planners and learned policies are moving from chat into control of machines: cobots, drones, autonomous mobile robots, and industrial systems that act on AI-generated plans. Here an unintended action is not a recoverable error but a physical event.

Autonomous commerce and machine-to-machine transactions. As agents begin to transact — purchasing, settling, negotiating — on behalf of organizations, actions cross financial and contractual boundaries at machine speed, between counterparties who share no common control plane and no shared way to verify that an action matches what was authorized.

The through-line is a single sentence, and it is the most important sentence in this section: the world did not need Intent Verification when software executed commands; the world needs Intent Verification when software originates actions. When intent was supplied by a human and software executed faithfully, the verification of intent happened before the software ever ran, in the mind of the person who issued the command. Every layer of the existing stack was designed for that world and is correct for it. The shift to software that originates its own actions does not break those layers — it adds a question they were never responsible for answering, and it adds it at the busiest, fastest, least supervised point in the system: the moment of action.

This is why the problem appears now and not before, and why it will intensify rather than recede. Each trend above is accelerating, and each one widens the gap between what autonomous systems are permitted to do and what they were intended to do. The category does not depend on any single one of these trends. It depends on their direction, which is unambiguous: more action, less supervision, more boundaries crossed, higher consequence. A control problem that grows with every one of those vectors is not a passing concern. It is an emerging layer.

Key Takeaways

• The Intent Gap is new because its preconditions are new: tool use, agentic systems, multi-agent invocation, autonomous workflows, physical AI, and machine-to-machine commerce are arriving together.
• Each trend removes a human checkpoint and adds an autonomous action, widening the gap between permitted and intended.
• The world did not need Intent Verification when software executed commands; it needs it when software originates actions.
• The existing stack is not broken — it is being asked a question it was never built to answer, at the fastest and least supervised point in the system.
• Every relevant trend is accelerating, so the category intensifies rather than recedes.

The Autonomous Action Explosion

The Intent Gap would be a manageable problem if autonomous actions were rare, or if humans could review them. Neither will hold. The defining property of autonomous systems is that they multiply the number of consequential actions a single human decision sets in motion, and they remove the human from each of those actions. The result is an explosion in action volume that runs directly into the one resource that cannot be scaled to meet it: human attention.

Trace the trajectory. For most of computing history, the path from intent to action was short and human-bounded:

Human → software → action.

A person decided, and software executed one action per decision. The first wave of AI assistance kept the human in the loop, as a reviewer:

Human → agent → recommendation → human approval → action.

The agent proposed; a human approved; then the action ran. This is safe and it does not scale — the human approval step is a throughput ceiling. So the next step removes it:

Goal → agent → action.

A human sets a goal, and the agent takes actions to satisfy it without per-action approval. Then agents begin to invoke other agents, and the chain lengthens beyond any single point of human contact:

Agent → agent → agent → agent → transaction.

And finally the chain reaches into the physical world:

Agent → robot → physical action.

At each step the ratio of actions to human decisions rises by orders of magnitude, and the number of points at which a human could intervene falls toward zero. This is not a forecast that requires heroic assumptions. It is the visible direction of every trend in Part III's "Why This Problem Appears Now," compounded.

The conclusion is uncomfortable but simple. Human review does not fail because it is ineffective; a human reviewing an action is the gold standard of intent verification. Human review fails because it cannot scale. There is no number of reviewers that keeps pace with systems designed specifically to act without waiting for one. The future challenge is not thousands of autonomous actions. It is billions. Autonomous systems create more decisions than humans can supervise — by construction, because supervising each decision is the bottleneck autonomy exists to remove.

When the volume of autonomous action exceeds the capacity of human oversight — and it will, because the whole point of autonomy is to operate faster and more broadly than human oversight allows — governance has only one place left to live: in the runtime, applied automatically, before each action executes. That is what makes Intent Verification mandatory rather than merely useful. It is the only form of intent governance that scales with autonomous action, because it is the only one that does not depend on a human being present for each decision.

Key Takeaways

• The path from intent to action has lengthened from human → software → action to goal → agent → action to agent → agent → transaction to agent → robot → physical action.
• At each step the ratio of actions to human decisions rises by orders of magnitude and the points of possible human intervention fall toward zero.
• Human review does not fail because it is ineffective; it fails because it cannot scale. The challenge is not thousands of autonomous actions but billions.
• Autonomous systems create more decisions than humans can supervise — by construction.
• Intent governance can only scale if it lives in the runtime, applied automatically before each action; that is what makes Intent Verification mandatory.

The Largest Ungoverned Surface Area in Enterprise History

It helps to make the scale concrete, because the abstraction understates it. Consider a single autonomous agent in a single enterprise function — procurement — operating at a volume that is already ordinary for automated systems.

Suppose the agent takes one hundred thousand actions per day: classifying requests, matching invoices, approving payments, updating vendor records, releasing orders. Suppose it is very good — divergence from intent occurs in only one action in a thousand, a 0.1% rate that any vendor would be pleased to report. The arithmetic is unforgiving:

• One hundred thousand actions per day.
• At 0.1% divergence, one hundred unintended actions per day.
• Across a year, roughly thirty-six thousand five hundred unintended actions.

Now recall what every one of those actions looks like to the existing stack. Each is authenticated — a valid agent acting under valid credentials. Each is authorized — within policy, within limit. Each is compliant — conforming to the codified rules. Each is safe — producing no unsafe content and no hazardous state. By every control the enterprise currently operates, all one hundred thousand actions per day pass. And tens of thousands of them per year are wrong: permitted, authorized, compliant, safe, and not what anyone intended.

That is one agent, in one function, in one company. Multiply it across the functions an enterprise is automating — finance, IT, support, supply chain, HR — and across the agents within each, and the picture resolves into a single observation that ought to stop a reader cold. Autonomous systems are creating the largest ungoverned operational surface area enterprises have ever deployed. Not the largest attack surface — that is a different and well-funded discipline. The largest ungoverned surface: the set of consequential actions taken automatically, every one of which passes every existing control, and none of which is checked against whether it was the action that should have been taken. Enterprises have wired autonomous systems into the operational core faster than they have built any way to govern what those systems actually do. The Intent Gap is not a niche failure mode at the edge of that surface. It is the surface.

Key Takeaways

• A single procurement agent at 100,000 actions/day with a 0.1% divergence rate produces ~36,500 unintended actions per year.
• Every one of those actions is authenticated, authorized, compliant, and safe — and wrong.
• Multiplied across functions and agents, this is the largest ungoverned operational surface area enterprises have ever deployed.
• It is distinct from the attack surface: it is the set of consequential actions that pass every existing control and are checked against intent by none.
• Enterprises have automated the operational core faster than they have built any way to govern what the automation does.

The Autonomous Refund — A Worked Example

Abstractions persuade slowly. A single concrete sequence, followed end to end, tends to make the Intent Gap visible in a way that a taxonomy cannot. What follows is an ordinary case, deliberately undramatic, traced through the existing control stack one checkpoint at a time. There is no breach in it, no adversary, no defect in any individual system. Every component behaves exactly as designed. That is what makes it instructive.

A customer contacts a retailer's support channel about a product that arrived damaged. The message is unremarkable: the item is defective, and the customer would like a working one sent. An autonomous support agent — a tool-using model wired into the order-management, payments, and communications systems — picks up the case. Its goal, as configured, is to resolve customer issues quickly and within policy. It reads the message, classifies the situation as a defective-product complaint, and determines that the customer is entitled to remediation. It selects an action: issue a refund to the original payment method.

Watch the action move through the stack.

The goal is provided. No human wrote the command "issue a refund." A human wrote a goal — "resolve customer issues within policy" — months ago, when the agent was deployed. The specific action was synthesized just now, by the agent, from the message and its context. This is the new world of Part I in miniature: intent is not supplied with the action; it is constructed alongside it.

Identity passes. The agent presents valid credentials. It is a known, registered automation with a scoped service identity, operating in the environment it was provisioned for. Every identity check returns green. The system knows, with cryptographic certainty, exactly who is acting. It does not, and cannot, know whether the act is the right one.

Policy passes. The refund is well within the agent's authorized limit. Refunds are a permitted action for this agent, on this account type, for this product category. The authorization layer evaluates the request against its rules and finds nothing to object to. The action is, in the precise sense the word is used in every access-control system ever built, permitted.

Safety passes. There is nothing dangerous about a refund. No unsafe content is generated, no hazardous state entered, no protected resource touched. Whatever guardrails sit around the model's inputs and outputs see clean, well-formed, policy-compliant text. The safety layer, asked whether this action is dangerous, correctly answers no.

Audit passes. Every step is logged. The classification, the decision, the refund transaction, the confirmation to the customer — all of it is written to a durable, reviewable record. If anyone asks later what happened, the system can reconstruct the sequence in complete detail. Observability is flawless.

The wrong action proceeds. The refund executes. The money returns to the customer's card. The case is closed as resolved. Identity verified the actor, policy permitted the action, safety cleared it as harmless, and audit recorded it faithfully. Five controls, five green lights.

And it was the wrong action. The customer did not ask for a refund. The customer asked for a replacement — a working unit of the product they still want. The refund closes the case in the system but not for the customer, who now has no product, no replacement on the way, and a balance returned they did not request. The retailer has resolved a complaint by failing to meet it, lost the sale it could have kept, and degraded the relationship — silently, with a perfect audit trail showing that every control passed. Multiply this by the volume at which autonomous agents operate, and the individually trivial error becomes a measurable line on a financial statement.

Nothing in the existing stack flagged it, because nothing in the existing stack was evaluating the one thing that was wrong: the action did not match what was intended. Permitted ≠ Intended is not a slogan here. It is the literal, step-by-step outcome of running a permitted, authenticated, safe, audited action that happened to be the wrong one.

Now replay the same sequence with one addition.

The agent synthesizes the same action — issue a refund — and proposes it. Before the refund executes, the proposed action passes through an intent-verification step. The action is interpreted and named: financial reversal — refund to original payment method. It is compared against the declared purpose of the interaction, which the same system can read from the customer's message: the customer requested a replacement, a fulfillment action, not a financial reversal. The two do not match. The intended outcome and the proposed action diverge.

Authority is not granted. The refund does not execute. Depending on how the organization has configured the response, one of three things happens: the action is denied and the agent is prompted to reconsider, which leads it to propose the replacement the customer actually requested; or the case is escalated to a human, who resolves it in seconds with full context; or the action is routed for approval before any money moves. In every branch, the unintended action is stopped before it reaches the world — not explained afterward, not reversed at a cost, not discovered in a quarterly review of refund anomalies. Stopped, at the boundary, because it did not match intent.

That is the entire category in one sequence. Identity, policy, safety, and audit each did their job and each, by design, let the wrong action through, because none of them was responsible for intent. A single control that evaluates the match between the proposed action and the intended purpose — before execution — is the difference between a clean audit trail of a failure and a failure that never happened. The refund is small. The pattern is not. The same sequence, with the same five green lights and the same silent divergence, describes the wrong invoice approved, the wrong pallet moved, the wrong account credited, the wrong environment deployed, and the wrong objective pursued by a machine in a workspace shared with a person. The story is about a refund. The category is about everything that comes after.

Part I — The Assumption That Broke

Infrastructure is a record of assumptions durable enough to build on. The assumption beneath most enterprise control systems is that a reliable interpreter of intent already sits in the loop, and that the interpreter is a human or a deterministic program written by humans. Almost every mature control technology inherits this assumption, and almost every one works well precisely because the assumption used to hold.

In the conventional model, a person stands at the center of every consequential action, even when not visible at the moment of execution. The person decided what was meant when requirements were written, what mattered when the workflow was designed, which exception applied when an unusual case arose, and when not to proceed at all. When a system executed an action, a human had already adjudicated its appropriateness — sometimes seconds before, sometimes months before in the form of code or configuration, but adjudicated nonetheless. This is the quiet function humans performed: they were the runtime interpreters of intent, closing the loop between a goal and an action by asking, implicitly, "is this the right thing to do here?" Because the human carried that judgment, the software did not need to.

The control architecture of deterministic software can be drawn as a short, linear chain:

Human intent → software command → deterministic execution.

Intent enters at the left, fully formed; the system's job is fidelity. Controls layered onto this chain reflect its shape. Authentication guards the entry: it confirms the human who issued the command is who they claim to be. Authorization guards the boundary: it confirms this authenticated actor may issue this command. Safety guards the blast radius: it confirms the command will not enter a dangerous state. Logging guards the aftermath: it records what was executed. Each control assumes a fixed command whose intent is not in question — and each does its job well within that assumption.

Autonomous systems replace the short chain with a longer one:

Goal → model reasoning → tool selection → proposed action → real-world effect.

Here intent does not enter fully formed. A goal enters — often underspecified, often ambiguous — and the system constructs the path to an action through reasoning and tool selection. The proposed action that emerges was not written by a human; it was synthesized from the goal and the current context. The interpretation of intent that a human used to perform has moved inside the chain, and it now happens continuously, at machine speed.

The consequence is that the assumption underpinning the old controls no longer holds. Authentication can still confirm the agent is a known agent. Authorization can still confirm the agent may call a given tool. Safety can still confirm the resulting action is not hazardous. Observability can still record what the agent did. But none of these controls was ever responsible for confirming that the synthesized action matches the intended purpose, because in the old world that confirmation arrived for free, embedded in a human-issued command. In the new world there is no human-issued command at the point of action — only a system-issued one — and the confirmation that used to be free is now absent.

It is tempting to assume the Intent Gap can be closed by tightening existing controls: finer policies, more guardrails, richer audit. Each is worth doing; none closes the gap. Finer policy narrows the set of permitted actions, but the failure mode of autonomy is not a forbidden action — it is a permitted action taken in the wrong context, and the Intent Gap is exactly that mismatch. Stricter guardrails constrain prompts and outputs, but the failure mode is not unsafe content — it is a safe, well-formed action that does not match the workflow. Richer audit improves reconstruction, but reconstruction happens after execution, and the autonomous failure has already reached the world by the time the log is written. The old controls are correctly placed for the questions they answer. The question autonomy raises has no control placed for it at all. That assumption — that a trustworthy interpreter of intent already sits in the loop — is the one that broke.

Key Takeaways

• Enterprise controls assume a reliable human interpreter of intent already sits in the loop; the assumption held for decades because it was true.
• Old model — human intent → software command → deterministic execution — intent enters fully formed and the system executes faithfully.
• New model — goal → reasoning → tool selection → proposed action → effect — the system synthesizes the action and the human interpretation step is gone.
• Tightening existing controls does not help, because the gap is a missing control for a new question, not a weakness in existing ones.

Part II — The Existing Stack Fails

The claim that "no existing layer solves this" is easy to assert and easy to doubt. This section makes the claim the hard way, by examining the control stack one layer at a time. For each layer we state the problem it solves, why it matters, and why — structurally, not incidentally — it cannot verify intent. The argument is cumulative. Taken individually, each layer has a reasonable answer to "why not just extend this one?" Taken together, they converge on a single conclusion that the reader should reach before we state it: there is no layer responsible for intent.

Identity. Identity solves the problem of establishing who is acting. It matters because every downstream control depends on a trustworthy actor: you cannot authorize, audit, or attribute an action without knowing whose action it is. Identity cannot verify intent because knowing who is acting says nothing about whether the act is the right one. A correctly authenticated agent, with impeccable credentials, can propose an action that contradicts its purpose. Identity verifies the actor; intent concerns the act. Strengthening identity — stronger authentication, finer attribution — produces a more certain answer to a question intent never asks.

Authorization. Authorization solves the problem of deciding whether an actor may perform an action. It matters because it bounds what each actor can do, containing blast radius and enforcing least privilege. It cannot verify intent because authorization evaluates membership in a permitted set, and the failure mode of autonomy is a permitted action taken wrongly. Authorization can confirm that an agent is allowed to issue refunds; it cannot determine that this refund contradicts what the customer requested. Permission is a boundary; intent is a purpose within it.

Policy. Policy solves the problem of encoding rules about what should and should not happen. It matters because it turns judgment into something machine-enforceable and consistent. It cannot verify intent because policy is written in advance and evaluated against the action in isolation, while intent is contextual and depends on the relationship between the action and the specific situation. Policies define rules; they do not define intention. A policy fine-grained enough to encode every contextual purpose would have to anticipate every situation in advance — which is precisely what autonomy makes impossible, because the situations are generated at runtime.

Guardrails. Guardrails solve the problem of keeping model inputs and outputs within acceptable bounds — blocking unsafe prompts, filtering harmful or malformed outputs. They matter because they constrain the content an autonomous system produces. They cannot verify intent because they operate on text, not on the downstream action, and an acceptable output can drive an unintended action. A well-formed, policy-compliant, perfectly safe response can still trigger the wrong operation. Guardrails check the words; intent concerns the deed.

AI Safety. AI safety solves the problem of preventing harmful or dangerous behavior — actions that injure, damage, or cause unacceptable outcomes. It matters enormously, especially as systems touch the physical world. It cannot verify intent because safety asks whether an action is dangerous, while authority asks whether it should happen at all. A safe action can be the wrong action: moving the wrong pallet is not dangerous, and approving a duplicate invoice harms no one physically. Safety verifies the absence of danger; it does not verify the presence of intent. The two are orthogonal, and a system can pass every safety check while doing precisely what no one intended.

Observability. Observability solves the problem of understanding what a system did — traces, metrics, logs, the ability to reconstruct behavior. It matters because complex autonomous systems cannot be understood by inspection alone. It cannot verify intent because observability is retrospective by nature: it explains what happened, after it happened. Intent verification must be prospective; it determines whether an action should happen before it does. Perfect observability of an unintended action is a perfect record of a failure that already occurred.

Audit. Audit solves the problem of producing a durable, reviewable record for compliance and forensics. It matters because organizations must be able to demonstrate, after the fact, what occurred and why. It cannot verify intent because, like observability, it operates after execution; an audit trail is evidence about the past, not authority over the present. Audit answers "can we reconstruct what happened?" Intent verification answers "should this happen, now?" The richest audit trail in the world cannot un-execute an action.

Risk. Risk scoring solves the problem of quantifying the likelihood and impact of adverse outcomes, so attention and controls can be allocated proportionally. It matters because not all actions deserve the same scrutiny. It cannot verify intent because a risk score is a probability over outcomes, not a determination of whether a specific action matches a specific purpose. A low-risk action can be entirely unintended, and a high-risk action can be exactly what was intended. Risk informs how carefully to look; it does not look.

Compliance. Compliance solves the problem of conforming to external rules — regulations, standards, contractual obligations. It matters because operating in regulated domains requires demonstrable conformance. It cannot verify intent because compliance checks conformance to codified rules, and an action can be fully compliant and still not be the action that was intended. Compliance is a property measured against external requirements; intent is a property measured against the operational purpose of the moment.

Governance. Governance solves the problem of establishing who may set policy, how decisions are made, and how authority is delegated across an organization. It matters because control needs structure and accountability. It cannot verify intent because governance operates at the level of process and authority structure, not at the level of the individual runtime action. Governance decides who gets to define the rules and who answers for them; it does not, and cannot, stand in the path of each autonomous action and check it against intent. Governance is organizational; intent verification is operational, per-action, and at machine speed.

Read the failures together and a single shape emerges. Identity is upstream of the act. Authorization and policy bound the act statically. Guardrails check the content around the act. Safety checks the danger of the act. Observability and audit follow the act. Risk scores the act. Compliance and governance sit beside and above the act. Every layer touches the action — and not one of them stands in front of it, at runtime, to verify that it matches what was intended. The conclusion is not that any layer is weak. Each is strong at what it does. The conclusion is that the stack, taken as a whole, has no layer responsible for intent. That vacancy is not an oversight to be patched. It is a missing category.

Key Takeaways

• Each control layer — identity, authorization, policy, guardrails, safety, observability, audit, risk, compliance, governance — solves a real problem and is strong at it.
• Each fails to verify intent for a structural reason, not an incidental one: it answers a different question, at a different point in the flow.
• Identity is upstream; authorization and policy bound statically; guardrails check content; safety checks danger; observability and audit follow; risk scores; compliance and governance sit beside and above.
• Not one of them stands in front of the action, at runtime, to verify it matches what was intended.
• The stack has no layer responsible for intent — a vacancy that is a missing category, not a patchable oversight.

Part III — The Intent Gap

We can now define the central concept of this paper with precision.

The Intent Gap is the space between what an autonomous system is permitted to do and what it was actually intended to do.

The gap exists because permission and intent are different properties of an action. Permission is a static boundary, defined in advance: a set of actions an actor may take. Intent is a contextual purpose, defined in the moment: the specific outcome an action is meant to achieve, here, now, given this goal and this situation. An action can fall squarely inside the permitted boundary and still fail to match the intended purpose. When that happens, every permission-based control reports success, and the wrong action executes with a clean record.

The Intent Gap is not the fault of any single control. As Part II showed, it is a structural property of a stack whose layers each answer an adjacent question. Setting the layers side by side makes the Intent Gap visible: each is necessary, each is well-designed, and each misses the same thing.

Read down the right-hand column and the shape of the Intent Gap emerges. Every layer is doing its job. The gap is the union of what they each, by design, leave out.

Permitted ≠ Intended: the pattern across industries

The Intent Gap is not a thought experiment. It is a pattern that already recurs wherever autonomous systems take action, and it has the same shape in every domain: an action that is authorized, permitted, and safe, but not what was intended. The phrase to carry away from this section is short and exact: Permitted ≠ Intended. The following cases span enterprise software, healthcare, supply chain, manufacturing, robotics, financial services, and physical AI. In each, read the controls as passing and the intent as failing.

Enterprise — refund instead of replacement. A customer requests a replacement for a defective product. The support agent issues a refund. Identity, policy, and safety all pass; refunds are permitted and the agent is authorized. The customer asked for a replacement. Permitted ≠ Intended.

Enterprise — the wrong invoice approved. A finance agent approves an invoice for payment. The approval is within limit and within policy. The invoice is a duplicate of one already paid. Nothing was forbidden; the second payment was never intended. Permitted ≠ Intended.

Enterprise — the wrong vendor paid. A procurement agent settles a legitimate payable to a supplier whose record was recently updated. The payment is authorized and within budget. The funds go to the wrong account on file. Every control passes; the destination was not the one intended. Permitted ≠ Intended.

Enterprise — the wrong customer account modified. A support agent applies a permitted account change — a credit, a plan change, a data update — to an account that matches the request loosely but is not the customer in question. The action is authorized and safe. It was applied to the wrong account. Permitted ≠ Intended.

Enterprise — the wrong environment deployed. A DevOps agent promotes a build. Deployment is permitted; the pipeline is healthy; the change is safe. The promotion targets production when staging was intended. No policy was violated; the environment was wrong. Permitted ≠ Intended.

Healthcare — the correct medication, the wrong patient. A clinical workflow agent dispatches a medication order that is itself correct, appropriate, and within formulary. It is associated with the wrong patient record. The drug is safe and authorized; the recipient was not the one intended. Permitted ≠ Intended.

Supply chain — the correct movement, the wrong pallet. A warehouse system directs an autonomous mover to relocate inventory. The movement is valid, safe, and within the system's authority. It moves the wrong pallet. The motion broke no rule; the object was not the one intended. Permitted ≠ Intended.

Manufacturing — the correct process, the wrong work order. A production agent runs a process that is exactly correct as a process — the right sequence, within safety limits — against the wrong work order. The machine did nothing unsafe and nothing unauthorized. It executed the right procedure on the wrong job. Permitted ≠ Intended.

Robotics — the safe movement, the wrong destination. A mobile robot navigates a path that is collision-free and within its operating envelope. It delivers to the wrong location. Every safety check passes; the destination was not the one intended. Permitted ≠ Intended.

Financial services — the authorized trade, the wrong account. A trading agent executes a trade that is fully authorized and within risk limits. It books the position to the wrong account. The trade itself broke no rule; the booking was not what was intended. Permitted ≠ Intended.

Physical AI — the safe motion, the wrong objective. An embodied system performs a motion that is physically safe by every measure and accomplishes an objective — just not the objective specified for the task. Nothing dangerous occurred. The system did the wrong thing safely. Permitted ≠ Intended.

Eleven cases, seven industries, one Intent Gap. None involves a breach, an adversary, an unsafe payload, or a policy violation. That is the point. The Intent Gap is not primarily a classical security problem about keeping out attackers or forbidden actions. It is a correctness problem about authorized actors taking permitted, safe actions that nonetheless were not intended. A board member grasps it in ten seconds: the agent was allowed to do it, so it did — but it was the wrong thing, so it should not have. The simplicity is the argument. If the most ordinary cases already escape every control, the controls are not merely imperfect; they are aimed at a different target.

Two distinctions are worth stating directly, because they are the ones most often collapsed. Identity verifies who is acting. Intent verifies what the action means. A correctly authenticated agent with valid, narrowly scoped credentials can still initiate an action that contradicts its purpose; an impeccable answer to "who is acting?" tells you nothing about whether the act is right. And observability explains what happened, while intent verification determines whether it should happen before it does. These are not two implementations of one capability at different times. Observability is a sensing function whose value is understanding; it is intrinsically retrospective. Intent verification is a control function whose value is prevention; it is intrinsically prospective.

The Intent Gap, then, is the predictable result of building a control stack on the assumption that intent arrives pre-verified. Remove the human interpreter, and the assumption fails silently — silently because every remaining control still reports success on exactly the actions that go wrong. A permitted action can still be the wrong action, and in a world of autonomous systems, "permitted but unintended" is not an edge case. It is the characteristic failure.

Key Takeaways

• The Intent Gap is the space between what an autonomous system is permitted to do and what it was actually intended to do.
• Across enterprise, healthcare, supply chain, manufacturing, robotics, finance, and physical AI, the gap has one shape: authorized, permitted, safe — but not intended. Permitted ≠ Intended.
• None of the cases involves a breach or a policy violation; the Intent Gap is a correctness problem, not a classical security one.
• Identity verifies who is acting; intent verifies what the action means. Observability explains what happened; intent verification determines whether it should happen before it does.
• "Permitted but unintended" is the characteristic failure of autonomous systems, not an edge case.

Part IV — Intent Verification as a Runtime Primitive

A primitive is a capability that cannot be reduced to the others without losing something essential. Identity is a primitive: you cannot reconstruct it from policy or logging. Authorization is a primitive: it is not a special case of authentication. Intent Verification is a primitive in the same sense — a capability the existing layers cannot supply as a side effect, occupying a position in the control flow that none of them occupies.

The cleanest way to see this is to line up the questions each control answers and observe that they do not collapse into one another:

Identity verifies who. Policy verifies whether permitted. Safety verifies danger. Intent verifies meaning.

These are four different predicates over the same proposed action, ranging over different information. The fourth consults what the others never do: the declared goal, the operational context, the business process the action is meant to advance, and the relationship between the proposed action and that process. No refinement of the first three produces the fourth. Verification has to happen before execution, or the rest is theater.

Three questions are easy to conflate and important to separate, because each corresponds to a different decision at a different moment:

Permission asks: May this action occur? Intent asks: Is this the action that should occur? Authority asks: Has this action earned the right to execute in this context?

Permission is answered in advance and statically. Intent is answered in the moment and contextually. Authority is the synthesis: the runtime decision, made at the moment of action, that combines permission, verified intent, process conformance, risk, and context into a single verdict. This is why authority cannot be a static grant. In the deterministic world, "authorized" could be durable — a role, a scope reused across requests. In the autonomous world, the same actor with the same permissions proposes a stream of different actions whose appropriateness depends on context that did not exist when any static grant was issued. Authority has to be evaluated per action, against the intent of that action, at the time it is proposed. Authority is not assumed. Authority is granted. The distinction compresses to a line worth keeping: permission governs access; intent governs action.

Intent Verification is performed as a loop that sits before execution, not alongside it and not after it:

1. Interpret the proposed action into a structured representation of what it is attempting.
2. Map it to a canonical intent in a shared vocabulary, so it can be compared independently of the system that produced it.
3. Compare it to the declared workflow, business process, and context.
4. Decide whether authority should be granted, escalated, denied, or routed for approval.
5. Issue authority if verified, as a portable cryptographic proof.
6. Enforce before execution, requiring that proof at the point of action.
7. Preserve evidence of the decision and its basis.

The order matters as much as the steps. Enforcement precedes — and gates — execution. The verification is prospective by construction: not a report on an action that has occurred, but a precondition on one about to. This is the structural difference between intent verification and observability, expressed as control flow. Observability reads the action after it crosses the boundary; intent verification stands at the boundary and decides whether it crosses at all.

A verified decision has to reach the point of execution to mean anything. How it is carried is an implementation question, not a category question: in practice it travels as a portable, cryptographically verifiable grant — an Authority Token — that is specific to one action, scoped, time-bound, and independently checkable at the boundary, leaving an auditable record. The mechanics belong in technical documentation. What matters at the level of the category is the property the carrier enforces: because the grant is verifiable where the action would run, the decision can be made centrally — where intent can be interpreted and compared against process — while enforcement happens locally, at each boundary, before the action proceeds. That separation of decision from enforcement is what lets intent verification function as infrastructure rather than as a feature of one application. The rule it produces is the one constant worth remembering: no token, no action.

There is a structural reason intent verification should be performed by a layer independent of the system that proposed the action. The agent is the author of the proposed action; asking the author to also be the final authority on whether its own action matches intent collapses the separation that makes verification meaningful. This is not a claim that any vendor is incapable; it is an observation about position. A reasoning model should not be the sole authority verifying its own intended action, for the same reason that, in well-designed systems, the party that requests an action and the party that approves it are kept distinct. Intent verification benefits from independence from the model that proposed the action — of implementation, of incentives, and of failure modes. That independence is part of what makes the primitive trustworthy.

Key Takeaways

• Intent Verification is a primitive: it cannot be reduced to identity, policy, safety, or observability, because it ranges over goal, context, and process the others never consult.
• Permission asks may this occur; intent asks is this the action that should occur; authority asks has this earned the right to execute here. Authority is not assumed; authority is granted.
• The loop — interpret, map, compare, decide, issue, enforce, preserve evidence — is prospective and gates execution rather than reporting on it.
• A verified decision is enforced at the boundary before the action runs; how that grant is carried is an implementation detail of the category, not its definition. No token, no action.
• Verification benefits from independence from the system that proposed the action; the author of an action should not be the sole authority on its own intent.

From Access Control to Action Control

It is worth stepping back from the mechanics of authority to place it in a longer arc, because the shape of that arc is what reveals Authority as infrastructure rather than as a feature. Computing has spent four decades making access programmable. It is now beginning to make action programmable, and the two are not the same problem.

The evolution of access control runs in a straight line. It began with the username — a claim of identity, unverified. It became identity — a verified claim, backed by authentication. It became delegated and federated through OAuth, so that access could be granted across organizational boundaries without sharing credentials. The currency of that delegation is the access token — a portable, scoped, time-bound proof that a client may reach a resource. Each step made access more granular, more portable, and more programmable. By the end of it, "who may touch what" had become a runtime decision carried by a verifiable token, and an entire industry was built on that primitive.

Autonomous action extends the same arc one step further. The next link is Intent Verification, and its currency is the Authority Token — a portable, scoped, time-bound proof not that a client may reach a resource, but that a specific action has been verified as matching intent and may execute. The progression is exact:

username → identity → OAuth → access token → Intent Verification → Authority Token

The distinction between the two tokens is the distinction between the two eras. OAuth secured access. Authority Tokens secure action. An access token answers "may this client reach this resource?" — a question about the door. An Authority Token answers "may this action execute, here, now, given what it means?" — a question about what is done once through the door. The first governs the boundary; the second governs the act. Access became programmable over the last two decades, and a vast amount of infrastructure was built to carry it. Authority becomes programmable now, on the same model: a verifiable, scoped, time-bound grant, issued per action, checked at the point of execution. The mechanics are deliberately familiar, because the familiarity is the point — the industry already knows how to build on a primitive of this shape. What is new is what the primitive carries: not access, but authority over an action; and the rule that governs it is the one constant of this paper. No token, no action.

Seen this way, the Authority Token is not an implementation detail of one product. It is the runtime primitive of a new layer, occupying the same structural position in the era of autonomous action that the access token occupies in the era of access control.

Key Takeaways

• Computing spent four decades making access programmable; it is now making action programmable, and they are different problems.
• The arc runs username → identity → OAuth → access token → Intent Verification → Authority Token.
• OAuth secured access; Authority Tokens secure action. Access became programmable; authority becomes programmable.
• An access token governs the boundary ("may this client reach this resource?"); an Authority Token governs the act ("may this action execute, given what it means?").
• The Authority Token is the runtime primitive of the new layer, not an implementation detail. No token, no action.

Part V — Why Identity Is Not Intent, and Other Category Confusions

A new category is defined as much by what it is not as by what it is. Left unaddressed, a reader — especially an analyst whose job is taxonomy — will reach for the nearest familiar box and file Intent Verification inside it. This section closes those boxes one at a time. The format is deliberate: a claim of equivalence, and the structural reason it fails. We compare categories, not companies; where a specific product is named, it stands for a class.

Why identity is not intent. Identity establishes the actor. Intent concerns the act. The strongest possible identity — perfect authentication, perfect attribution — tells you with certainty who proposed an action and nothing about whether the action matches its purpose. Identity is a precondition for intent verification (you must know whose action you are evaluating) and not a substitute for it.

Why policy is not intent. Policy encodes rules in advance and checks the action against them in isolation. Intent is contextual and depends on the relationship between the action and the situation. A policy expressive enough to capture every contextual purpose would have to enumerate every situation ahead of time — impossible when situations are generated at runtime. Policy bounds the space of allowed actions; intent selects, within that space, whether this action is the right one.

Why safety is not intent. Safety asks whether an action is dangerous. Authority asks whether it should happen at all. These are orthogonal: a safe action can be entirely unintended, and the safety layer, doing its job correctly, will permit it. Safety is indispensable and remains in place; it simply answers a different question.

Why governance is not intent. Governance defines who may set policy, how authority is delegated, and who is accountable. It operates at the level of organizational structure and process, not at the level of the individual runtime action. Governance decides who writes the rules; intent verification stands in front of each action and checks it. One is organizational; the other is operational, per-action, and at machine speed.

Why observability is not intent. Observability explains what happened, after it happened. Intent verification determines whether something should happen, before it does. The most complete trace of an unintended action is a complete record of a failure that already reached the world. Observability is a sensing function; intent verification is a control function. They are complementary, not interchangeable.

Why agent frameworks are not intent. Agent frameworks orchestrate reasoning, tool calls, memory, and control flow; they are how autonomous systems are built. But a framework is the thing that proposes the action. Asking the framework to also be the independent authority on whether its own proposed action matches intent collapses the separation between proposer and verifier. Frameworks can integrate an intent-verification layer; they are not, by themselves, that layer, for the same structural reason a system should not certify its own requests.

Why model providers are not intent. A model provider supplies the reasoning that generates a proposed action. For the verification to be trustworthy, it should be independent of the model that produced the action — independent in implementation, incentives, and failure modes. A reasoning model verifying its own intended action is marking its own homework. Model providers are the proposers; intent verification is the independent check, and independence is the property that gives it value.

Why OAuth is not intent. OAuth solved delegated authorization: it lets a user grant a service scoped access on their behalf. It is foundational, and intent verification borrows its spirit of scoped, verifiable grants. But an OAuth token authorizes access to a resource; it does not verify that a specific action taken with that access matches what was intended. OAuth answers "may this client act on this resource?" Intent verification answers "is this particular action the one that should occur?" The first is a durable grant of access; the second is a per-action grant of authority.

Why RBAC is not intent. Role-based access control assigns permissions to roles and roles to actors. It is an efficient way to manage permission at scale. It is still permission: it defines the boundary of what a role may do, not whether a particular action within that boundary is the intended one. An agent in the correct role, acting within its permissions, can still take an action no one intended. RBAC scales the boundary; intent verifies the act inside it.

Why Zero Trust is not intent. Zero Trust replaced implicit network trust with continuous verification of identity and device posture for every request — a profound and correct shift. Intent Verification extends the same instinct, "never trust, always verify," to a dimension Zero Trust does not cover: not just who and what device, but whether the action means what was intended. Zero Trust verifies the actor and the connection on every request; it does not verify the purpose of the action. Intent Verification is the natural completion of the Zero Trust logic for a world where the actor is autonomous and the action is synthesized.

Why existing AI governance platforms are not intent. AI governance platforms catalog models, track usage, enforce policies, and document compliance — important work as enterprises adopt AI. But governance platforms largely operate around the model and after the action: inventory, policy attestation, monitoring, reporting. They tend not to sit in the execution path of each autonomous action and grant or deny authority before it runs. Governance frames and records; intent verification gates. A platform that tells you which models exist and whether their use is documented is not the same as a runtime that stops an unintended action before it executes.

Set the eleven side by side and the conclusion is the same as in Part II, now stated against the categories most likely to be confused with intent. Each is real, each is valuable, and each answers a question adjacent to intent rather than intent itself. The repeated structure — "X concerns the actor, the boundary, the danger, the record, or the organization; intent concerns whether the act matches its purpose, before it runs" — is not rhetorical insistence. It is the same structural fact seen from eleven angles. Permission governs access; intent governs action. Intent Verification is not a refinement of any of these. It is the missing one.

Key Takeaways

• A category is defined by what it is not; without this, analysts will misfile Intent Verification inside an adjacent box.
• Identity (actor), policy and RBAC (boundary), safety (danger), governance (organization), observability and audit (record), OAuth (resource access) each answer an adjacent question — not intent.
• Agent frameworks and model providers are proposers; the verifier should be independent of the system that proposed the action.
• Zero Trust's "never trust, always verify" extends naturally to intent — verifying not just who and what device, but whether the action means what was intended.
• Existing AI governance platforms frame and record; intent verification gates in the execution path, before the action runs.

What Intent Verification Does Not Solve

A category argument that answers every objection by reinforcing itself eventually reads as advocacy rather than analysis. The honest way to establish the boundary of a new layer is to state plainly what it does not do. Intent Verification is a new layer, not a replacement layer, and not a universal one. Its scope is narrow by design, and the precision of that scope is part of what makes it a category rather than a claim.

Intent Verification does not eliminate hallucinations. A model that misreads a situation or fabricates a justification is a problem of model behavior; intent verification operates on the proposed action, not on the reasoning that produced it. It can catch a hallucinated action that diverges from the declared purpose, but it does not make the underlying model more truthful.

It does not replace safety systems. Safety asks whether an action is dangerous; intent verification asks whether it should happen at all. The two are orthogonal and both are required. A robot still needs its functional-safety controllers, its interlocks, and its emergency stops, with or without intent verification above them.

It does not replace governance, identity, authorization, observability, or audit. It consumes their outputs and depends on them. Identity tells it whose action it is evaluating. Authorization tells it what is permitted. Governance tells it whose rules apply. Observability and audit record what it decided. Remove any of these and intent verification is weaker, not stronger. It is the missing layer in the stack, not a substitute for the stack.

It does not guarantee outcomes, and it does not guarantee correctness. Verifying that an action matches the declared intent is not the same as guaranteeing that the intent itself was wise, or that the world will cooperate once the action executes. Intent verification reduces the rate of actions that diverge from their declared purpose; it does not promise that every authorized action succeeds.

It does not eliminate human accountability. A control that decides whether autonomous actions may proceed does not absorb responsibility for them. Accountability for an autonomous system's behavior remains with the people and organizations that deploy it. Intent verification gives them a place to enforce and to prove their intent; it does not relieve them of having to form it.

And it does not eliminate operational risk. Autonomous systems will still fail in the ordinary ways complex systems fail — outages, integration errors, edge cases, degraded inputs. Intent verification removes one specific and currently unaddressed failure mode: the permitted-but-unintended action. It does not remove the others, and it does not claim to.

Stated together, these boundaries describe a layer that is necessary and bounded rather than total. The strongest argument for a new category is not that it solves everything. It is that it solves one thing nothing else does, and that the one thing is structural, recurring, and consequential. Intent Verification closes the Intent Gap. It leaves every other problem to the layers that own it — which is exactly what a well-defined infrastructure layer should do.

Key Takeaways

• Intent Verification is a new layer, not a replacement layer; defining its boundary is a matter of credibility, not modesty.
• It does not eliminate hallucinations, guarantee outcomes or correctness, eliminate human accountability, or remove general operational risk.
• It does not replace safety, identity, authorization, governance, observability, or audit — it consumes their outputs and depends on them.
• It removes one specific, currently unowned failure mode: the permitted-but-unintended action.
• A well-defined layer solves one structural problem and leaves the rest to the layers that own them.

Part VI — Physical AI Makes This Non-Optional

Autonomous systems made action programmable. Intent Verification makes action accountable.

Software agents are the first widely visible case of autonomous action, and most of this paper's examples are drawn from software because they are familiar. But software is not where the argument is most forcing. Physical AI is. When an autonomous system acts in the physical world, the cost of a permitted-but-unintended action changes in kind, not merely in degree, and the need for intent verification stops being good engineering and becomes a matter of consequence.

The primitive is indifferent to whether the action is digital or physical. The same loop — verify the intent, grant authority, enforce before execution — applies without modification to an agent approving an invoice, an agent deploying code, a robot moving a pallet, a drone taking off, an autonomous mobile robot navigating an aisle, a cobot reaching into a shared workspace, a system opening a door, a machine dispensing a measured dose, or a vehicle initiating motion. In each case an autonomous system proposes an action, and in each case the question is the same: does this action match what was intended in this context, and has it earned the authority to execute? That the answer is enforced before a database write in one case and before a motor command in another does not change the structure of the question. This is the deepest reason intent verification is infrastructure rather than an application feature: a single primitive spans the digital and the physical, because the gap it closes is the same gap in both.

What changes between the two worlds is the consequence of getting it wrong. A digital mistake — a permitted action that was not intended — typically produces a financial loss, an operational error, or a compliance exposure. These are serious, and generally recoverable: a payment can be reversed, a deployment rolled back, a record corrected. A physical mistake produces a different class of outcome. A robot performing a permitted-but-unintended action can cause a safety event, an injury, property damage, regulatory liability, or machine downtime — outcomes frequently not recoverable the way a database write is. A pallet dropped on a person cannot be rolled back. The asymmetry between digital and physical consequence is exactly what makes intent verification non-optional in physical settings: the margin for an unintended action narrows toward zero.

Physical systems already have safety infrastructure, and it is essential. Functional-safety controllers, emergency stops, protective interlocks, and certified safety logic exist to keep machines from entering dangerous states. Nothing here proposes replacing them; intent verification sits above the safety layer, not in its place. The reason a safety layer does not close the Intent Gap is that it answers a different question. Safety asks whether an action is dangerous. Authority asks whether it should happen at all. A safety system evaluates whether a motion will collide, crush, or exceed a force limit; it is designed to prevent harm. It is not designed to evaluate whether a physically harmless motion is the correct motion given the work order, the process, and the intended outcome. Those are orthogonal properties.

Two examples make the orthogonality concrete. Moving a pallet may be physically safe; moving the wrong pallet is still unauthorized — it violates no safety rule and accomplishes the wrong objective. Starting a machine may be physically safe; starting it outside the intended workflow, at the wrong time, on the wrong unit, against the wrong work order, is still wrong, and no interlock will catch it, because nothing dangerous is occurring. This is the digital refund example transposed into the physical world and made starker by the stakes. A perfectly safe action can still be the wrong action. Safety verifies the absence of danger; it does not verify the presence of intent.

Physical AI is the forcing function for three structural reasons. First, autonomous machines are moving from controlled demonstrations into production, where AI planners — not scripted sequences — generate the actions that reach the world. Second, the safety stacks beneath those machines were designed around deterministic operators and programmed motion; they have no representation of an AI-issued command and therefore no native place to verify its intent. Third, the regulatory environment for embodied AI is forming now, and the question regulators are positioned to ask — can you prove the autonomous system was authorized to do what it did? — is exactly the question intent verification answers. Physical AI does not create the Intent Gap. It removes the option of ignoring it. And because the largest platform and compute companies are orienting their next decade around physical AI, the layer that authorizes physical action is not a niche concern at the edge of the market. It is positioned at the center of where autonomous systems are heading.

This is the relationship between the two waves, stated plainly. Software agents created the category; physical AI makes it mandatory. The first decade of autonomous systems is software — agents acting on digital systems, where an unintended action is a recoverable loss. The second decade is physical — machines acting on the world, where an unintended action is a safety event. The primitive does not change between the two; only the stakes do. And in the physical world the requirement reduces to something no operator can wave away: every autonomous machine ultimately requires authority before motion. Before a motor turns, before a load lifts, before a vehicle moves, something has to have verified that the motion is the intended one and granted it the authority to proceed. That is the same primitive this paper has described throughout, arriving where it can no longer be deferred. It is also why the category survives every turn of the AI cycle: whatever models, architectures, or platforms come and go, autonomous systems will still take actions, and those actions will still need to be verified against intent before they execute. Autonomous systems made action programmable. Intent Verification makes action accountable — and in the physical world, accountability before motion is not optional.

Key Takeaways

• The intent-verification primitive is identical for digital and physical action; only the enforcement point differs — a data write versus a motor command.
• A digital permitted-but-unintended action tends to cause recoverable loss; a physical one can cause a safety event, injury, or damage that cannot be rolled back.
• Safety asks whether an action is dangerous; authority asks whether it should happen at all. A perfectly safe action can still be the wrong action.
• Physical AI is the forcing function: production deployment, safety stacks blind to AI-issued commands, and forming regulation make the missing layer impossible to ignore.
• As the industry's largest bets concentrate on physical AI, the layer that authorizes physical action sits at the center of the market, not its edge.

Part VII — Why Intent Requires a Shared Vocabulary

Intent verification presumes that a proposed action can be named — mapped to a canonical representation that can be compared against process and context. That presumption raises a question that determines whether intent verification can become infrastructure at all: in what vocabulary is the action named, and who defines it?

Autonomous systems do not exist in isolation. A realistic deployment spans many vendors' models, many tool ecosystems, many workflow engines, many physical systems, and many enterprise domains. An action initiated by one vendor's agent may need to be authorized against a process defined in another vendor's system and audited by a third party that trusts neither. If each system names actions in its own private scheme, an action's meaning cannot travel. It cannot be compared across systems, verified against a process owned elsewhere, audited by an outside party, or governed consistently across a heterogeneous estate. Naming is only useful if the names are shared. A vocabulary that one system understands and others do not is, for cross-system verification, no vocabulary at all.

This is not a novel predicament. It is the same fragmentation that every foundational layer of computing eventually had to resolve, and the resolution has always taken the same form: convergence on a neutral, shared standard owned by no single participant.

Why Shared Vocabularies Always Win

The history of computing is, in large part, a history of fragmented systems converging on a common language. The convergence is not an accident of any single era; it is a recurring structural outcome, because interoperability has more value than ownership at the layer where systems must understand one another.

• TCP/IP gave heterogeneous networks a shared protocol, so machines from different vendors could interconnect. No single vendor owned it; that is why everyone could build on it.
• DNS gave the internet a shared, hierarchical naming system, so any resource could be named and resolved consistently across the entire network. A world in which each provider invented its own naming scheme would not be one network; it would be many disconnected ones. Naming had to be shared for the network to function as a whole.
• HTTP gave the web a shared request model, so any client could talk to any server. Its neutrality is what let the web become a substrate rather than a set of walled gardens.
• OAuth and OpenID gave identity a shared model for delegated authorization and authentication, so access could cross organizational boundaries without bilateral integration.
• OpenAPI gave APIs a shared description model, so interfaces could be understood and consumed across tools regardless of who built them.

The pattern is consistent enough to state as a rule: at any layer where independent systems must interpret one another, a shared, neutral vocabulary eventually wins, because the value of interoperability compounds with each adopter while the value of a proprietary alternative does not. Vendors compete on implementation — faster routers, better browsers, stronger identity providers — but they converge on the vocabulary, because no one benefits from a private dialect that nothing else speaks. A shared vocabulary is not supporting infrastructure for these layers. It is the foundation on which the layer becomes a layer at all. Without TCP/IP there is no internet to build on; without DNS there is no coherent way to name what is on it; without HTTP there is no web. The vocabulary is the thing that turns a collection of systems into an ecosystem.

Autonomous action is approaching this threshold now, and the analogy is exact: just as the network needed a shared way to address packets and the web needed a shared way to request resources, autonomous systems need a shared way to name actions. In each prior case the value came not from any single implementation but from convergence. Once enough participants named things the same way, the shared vocabulary became more valuable than any proprietary alternative, and it became the substrate the rest of the ecosystem built on. The implementations competed; the vocabulary was common. This is the pattern autonomous action is approaching, and the analogy is exact: just as the network needed a shared way to address packets and the web needed a shared way to request resources, autonomous systems need a shared way to name actions. Open Intent is the TCP/IP-layer question for autonomous action — the shared vocabulary without which actions cannot be addressed, compared, or verified across the systems that produce them. The moment autonomous systems must coordinate actions across vendors, domains, and physical environments, a shared vocabulary for those actions becomes unavoidable — not as an ideal, but as a practical precondition for verifying, comparing, and auditing what those systems do.

Open Intent is intended to be that vocabulary: a neutral, open way of naming autonomous actions across systems, vendors, and domains, so an action can be named, compared, verified, audited, and governed consistently regardless of where it originated. It is designed to span both digital and physical action, because the primitive spans both. It is open by design so any vendor can adopt and contribute to it, and neutral by design so adopting it does not mean adopting any one vendor's control plane.

We are deliberately disciplined about the claim. Open Intent is intended to become a neutral vocabulary for autonomous action; it is positioned to serve as shared infrastructure for naming and verifying actions across systems. It has not, on the strength of this paper, already become an industry standard, and we do not claim that it has. The argument is about why a vocabulary of this kind is structurally necessary and why a neutral one tends to win — not an assertion that adoption is complete.

A natural objection is that a large model vendor could define its own vocabulary and propagate it. The objection underestimates why neutrality matters, and the reasons are structural rather than rhetorical. Competitors will not adopt a rival's vocabulary, because autonomous systems are inherently cross-vendor and no vendor will name its actions in a scheme controlled by a direct competitor. Enterprises resist lock-in at the control layer, because the layer that decides whether actions may execute is exactly the one they least want to outsource to a single supplier of the models being governed. Regulators prefer auditable, neutral standards, because a vocabulary used to prove that actions were authorized has to be open and independent to be trusted as evidence. And the verifier should be independent of the proposer. These pressures push consistently toward a vocabulary owned by no single participant and adoptable by all. That is what "neutral" means here, and it is why neutrality is a load-bearing property of Open Intent rather than a branding choice.

This sets up the division of labor between the open vocabulary and the commercial runtime, which is deliberate. The standard drives adoption. The runtime captures value. Open Intent is the shared language in which autonomous actions are named; it is meant to be free, neutral, and widely adopted, because its usefulness grows with adoption and its neutrality depends on not being a profit center. The runtime that interprets actions, verifies intent against process, issues authority, enforces it at the boundary, and preserves evidence is the product. A standard without a runtime is a document; a runtime without a standard is a silo. The combination is infrastructure.

Key Takeaways

• Intent verification presumes actions can be named in a vocabulary that travels; private per-vendor naming cannot be compared, verified, or audited across boundaries.
• Every foundational layer — TCP/IP, HTTP, OAuth/OpenID, OpenAPI — converged on a neutral shared standard owned by no one; implementations competed, the vocabulary was common.
• Open Intent is the TCP/IP-layer question for autonomous action: the shared way to name actions, without which they cannot be addressed, compared, or verified across systems.
• Open Intent is intended to become that neutral vocabulary; we claim structural necessity and a tendency toward neutral standards, not completed adoption.
• Neutrality is structural — competitors, enterprises, regulators, and the proposer/verifier separation all push toward it. The standard drives adoption; the runtime captures value.

Why Open Intent Alone Is Not Enough

The argument for a neutral vocabulary invites an immediate and reasonable objection. If Open Intent is open, can't anyone simply take the taxonomy and use it? The answer is yes — and it is also the moment the deepest misunderstanding of the category surfaces. Anyone can use the vocabulary. A vocabulary is not an interpretation system, and interpretation, not naming, is the hard problem.

Naming actions is the easy part. The difficulty is determining which name applies to what an autonomous system is actually attempting, in context, when the surface form of an action underdetermines its meaning. Consider a single instruction: move funds to an account. Named in isolation, it is "a payment." But the same action may be a payment approval, an invoice settlement, a vendor-onboarding disbursement, or a procurement execution — and which of these it is depends on context, the stage of the process, the actions that preceded it, the state of the workflow, and the organization's policy. The vocabulary can express all four meanings. It cannot, by itself, tell you which one is occurring. A taxonomy hands you the words. It does not hand you the understanding.

This is why an open vocabulary, on its own, has no authority value. Authority requires a verified intent, and verification requires interpretation — a determination of what the action means here, now, in this process, with enough structure and confidence to act on. Without an interpreter, Open Intent is a dictionary in a language no one is reading: complete, neutral, and inert. The interpreter is what turns the vocabulary from a reference into a runtime capability.

Why Interpretation Is Harder Than Naming

The difficulty becomes obvious once you notice that the mapping between actions and intent runs in both directions, and is many-to-many in each.

The same action can carry entirely different intent. "Issue payment" may be payroll, procurement, settlement, reimbursement, or vendor onboarding. The surface action is identical; the intent — and therefore the right authority decision, the right process, the right conformance check — is different in each case. A vocabulary can express all five meanings; it cannot tell you which one is occurring. Only interpretation can.

And the same intent can require entirely different actions. "Resolve the customer complaint" may call for a refund, a replacement, a credit, or an escalation, depending on what the customer asked for and what the situation warrants. The intent is identical; the correct action is not. A system that cannot tell which action a given intent demands will authorize the wrong one while believing it is serving the right purpose — which is precisely the refund-versus-replacement failure, viewed from the other side.

Naming is easy. Understanding is hard. Producing a vocabulary of intents is a finite, tractable task; determining which intent is actually present in a fuzzy, contextual, sequence-dependent stream of autonomous behavior is the hard, open problem, and it is where the durable work lives. Open Intent provides the vocabulary. The Large Intent Model provides the understanding. This is also why the strategic structure of the category divides the way it does: the vocabulary is open, because a shared language only works if everyone can adopt it; the interpretation is proprietary, because turning ambiguous behavior into verified, process-aware intent is the difficult capability that creates technical advantage. The openness of the vocabulary and the defensibility of the interpreter are not in tension. They are the two halves of why the layer works.

The compiler analogy

The relationship among the three layers is easiest to hold with a familiar mental model from computing itself.

Open Intent is the programming language. The Large Intent Model is the compiler. The Authority Runtime is the operating system.

A programming language defines a vocabulary and a grammar — a way to express intent precisely. But source code does nothing on its own; it has to be compiled into something a machine can act on, and the compiler is where the hard work of interpretation happens — resolving meaning, checking consistency, turning expression into executable structure. The operating system is what actually runs the result, mediating access to resources and enforcing what is and is not permitted to execute.

Map that onto autonomous action and the pipeline is direct:

Natural-language or tool-call action ↓ Large Intent Model (interpretation) ↓ Open Intent (canonical representation) ↓ Authority Runtime (authority decision) ↓ Execution

The action enters as raw behavior. The Large Intent Model interprets it — the compiler step — into a structured, process-aware intent. That intent is named in Open Intent, the canonical representation that makes it portable. The Authority Runtime evaluates it and decides whether it may execute, the way an operating system decides whether a program may touch a resource. Only then does the action run.

The analogy carries the strategic point precisely. No one believes the language specification is the whole of a computing platform; the compiler and the operating system are where a language becomes usable and governable. Likewise, the taxonomy is not the moat. The interpretation layer — the compiler step, where meaning is resolved well enough to be governed — is where an open vocabulary becomes an enforceable control. Open Intent explains the language. The Large Intent Model explains the meaning. The Authority Runtime enforces the decision. The vocabulary can be open precisely because the interpretation and enforcement layers are where the difficult, durable work lives.

Key Takeaways

• Anyone can use an open vocabulary; a vocabulary is not an interpretation system, and interpretation — not naming — is the hard problem.
• The same surface action (e.g., a payment) can be an approval, a settlement, an onboarding disbursement, or a procurement execution depending on context and process state; the vocabulary expresses all four but cannot disambiguate them.
• Without interpretation, an open vocabulary has no authority value — authority requires verified intent, and verification requires interpretation.
• Open Intent is the language, the Large Intent Model is the compiler, the Authority Runtime is the operating system: action → interpretation → representation → authority → execution.
• The taxonomy is not the moat; the interpretation layer is where an open vocabulary becomes a governable control.

Part VIII — The Cost of Unintended Action

The argument so far is technical and architectural. For the executive who must fund a control layer, it has to also be financial. The case is straightforward: an unintended autonomous action is not a hypothetical edge case but a cost, and as autonomous systems scale, the expected cost of the Intent Gap scales with them. Intent Verification is not only a technical improvement. It is a financial control. This section names the categories of cost, without inventing figures the reader cannot verify; the magnitudes are specific to each organization, but the categories are general.

Direct enterprise loss. A permitted-but-unintended action that moves money, modifies records, or commits resources produces a direct loss: the duplicate payment, the wrong refund, the misdirected transfer, the erroneous commitment. Each instance may be individually recoverable, but recovery has a cost of its own — investigation, reversal, reconciliation — and at the volumes autonomous systems operate, individually small errors aggregate into material loss. The relevant figure for a board is not the cost of one mistake but the cost of the error rate multiplied by the action volume, and autonomy raises both.

Compliance exposure. In regulated domains, an unintended action is not merely a loss; it can be a reportable event. An action that modifies the wrong account, mishandles regulated data, or violates a control objective creates exposure independent of the direct loss — remediation, disclosure, and the diversion of scarce compliance resources. The cost of proving, after the fact, that an action was not authorized is far higher than the cost of having denied it before it ran.

Operational failure. Unintended actions degrade systems and processes: the wrong deployment causes an outage, the wrong inventory move disrupts fulfillment, the wrong configuration change cascades. These costs are measured in downtime, in the engineering hours spent diagnosing a failure that a pre-execution control would have prevented, and in the erosion of trust that slows further adoption of the very automation that was supposed to create leverage.

Physical risk and liability. In physical settings the cost category changes entirely, as Part VI argued. An unintended action can cause injury, property damage, or a safety event, with the attendant human cost and the legal and regulatory liability that follows. The expected cost here is not dominated by frequency but by severity: rare events with consequences large enough that organizations cannot price them as routine.

Regulatory liability. Beyond specific compliance events, operating autonomous systems without the ability to prove authority creates a standing liability. As regulation of agentic and embodied AI matures, the burden of proof shifts toward operators: the question becomes not only "did you comply?" but "can you demonstrate that each autonomous action was authorized?" An organization that cannot answer carries a liability that grows with its degree of automation.

Autonomous fraud and abuse. The Intent Gap is also an attack surface. An adversary who cannot break identity or violate policy may still be able to induce an authorized agent to take a permitted action that serves the adversary's purpose rather than the organization's — a manipulated input that produces a technically authorized, contextually wrong action. Controls that check identity and permission do not catch this, because nothing forbidden occurs. A layer that verifies intent against the declared process is the control positioned to catch it.

Unauthorized automation and scope creep. As teams wire agents into more systems, the set of actions an organization's automation can take expands faster than the set anyone has deliberately reviewed. Without a control that verifies each action against intent, automation accretes capability silently, and the cost surfaces only when an unintended action does. Intent verification makes the boundary explicit and enforced rather than implicit and discovered.

The compounding cost of AI error. Finally, the cost of unintended action is not static. It compounds with adoption. Every additional agent, every additional integration, every step from recommending toward acting multiplies the number of actions taken without a human checkpoint. The expected cost of the Intent Gap is the product of three quantities, all of which autonomy increases: the number of autonomous actions, the fraction that diverge from intent, and the consequence of each. A control that bends any of those terms — and intent verification bends all three, by catching divergence before consequence — is not a discretionary technical upgrade. For an organization deploying autonomous systems at scale, it is a financial necessity.

Key Takeaways

• An unintended autonomous action is a cost, and the expected cost of the Intent Gap scales with the number of autonomous actions, the divergence rate, and the consequence of each.
• The categories are general even where the figures are organization-specific: direct loss, compliance exposure, operational failure, physical risk, regulatory liability, fraud, and scope creep.
• Proving after the fact that an action was not authorized costs far more than denying it before it ran.
• The Intent Gap is also an attack surface: an adversary can induce a permitted, contextually wrong action that identity and policy do not catch.
• Intent Verification is not a technical improvement but a financial control, and its value compounds with the degree of automation.

Why Enterprises Will Buy This

A new control problem becomes a new infrastructure category only when budget forms around it. The argument so far establishes that the Intent Gap is real and costly; this section explains why organizations will fund a layer to close it, drawing on the most reliable evidence available — how every comparable control layer before it became a line item.

Enterprises already spend at significant scale on control layers that, a generation ago, did not have their own budgets. Identity and access management is now a board-level expenditure with dedicated teams, named vendors, and its own analyst coverage. Privileged access management is its own discipline. Governance, risk, and compliance tooling is a category with established suites and recurring spend. Observability, once a euphemism for logging, is now a major infrastructure budget with platforms valued in the billions. Security operations, audit tooling, and functional safety each command real, sustained investment. None of these was always a category. Each began as a capability handled informally — until the cost of operating without it exceeded the cost of implementing it, at which point it acquired the full apparatus of a category: owners, budgets, vendors, standards, and governance.

That sequence is not coincidental; it is the mechanism by which control layers come into being. A control layer emerges when three conditions hold at once. First, a shift in how systems operate creates a new failure mode that existing controls do not catch. Second, the cumulative cost of that failure mode — in loss, exposure, liability, and remediation — becomes large enough to notice on a financial statement. Third, a control that addresses the failure mode becomes available and enforceable. When all three are true, the budget forms, not because anyone is persuaded by a manifesto, but because the arithmetic changes: the expected cost of operating without the control now exceeds the cost of operating with it. A new control layer emerges when the cost of operating without it exceeds the cost of implementing it. Identity crossed that line. Observability crossed it. Compliance tooling crossed it.

Intent Verification is approaching the same line on the same logic. The shift — software that originates actions — is well underway. The failure mode — the permitted-but-unintended action — is unaddressed by any existing control, as Part II established. And the cost, as Part VIII argued, scales with the number of autonomous actions, the rate at which they diverge from intent, and the consequence of each, all of which rise as organizations automate. As autonomous systems move from pilots into production paths that move money, modify records, and actuate machines, the expected cost of the Intent Gap moves from negligible to material. At that point, funding a layer to close it stops being a discretionary technical decision and becomes the same kind of decision an organization already makes about identity, audit, and safety.

The budget for Intent Verification will not have to be invented from nothing. It will form where adjacent budgets already exist — in security, in platform engineering, in governance and risk, in the operational owners of autonomous systems — because those are the functions that own the cost of an unintended action today and will be asked to account for it tomorrow. The question for an enterprise is not whether to create a new spending category from scratch. It is whether the layer that prevents unintended autonomous action belongs in the same portfolio as the layers that already verify identity, enforce policy, ensure safety, and prove compliance. Stated that way, the answer follows the pattern of every control layer that came before it.

Key Takeaways

• A new control problem becomes a category only when budget forms around it; the reliable guide is how prior control layers became line items.
• Identity, PAM, GRC, observability, security operations, and safety each began as informal capabilities and acquired owners, budgets, vendors, and standards once their absence became costly.
• A control layer emerges when the cost of operating without it exceeds the cost of implementing it; Intent Verification is approaching that line on the same logic.
• The shift (software that acts), the unaddressed failure mode (permitted-but-unintended action), and the rising cost together make the budget form.
• The spend forms where adjacent budgets already exist — security, platform, governance, and the operational owners of autonomous systems.

Part IX — The Three Layers: Vocabulary, Interpreter, Enforcement

Intent Verification is not a single component. It is a stack of three distinct layers, each answering a different requirement, none of which can substitute for the others. A reader who takes away only one structural idea from this paper should take this one:

Open Intent is the vocabulary. The Large Intent Model is the interpreter. The Authority Runtime is the enforcement layer.

These are three layers, not three names for one thing. Open Intent gives autonomous systems a common language; the Large Intent Model gives them a common understanding; the Authority Runtime turns that understanding into an enforced decision. Open Intent names actions. The Large Intent Model interprets actions. The Authority Runtime decides actions. Remove any one and the category does not function: a vocabulary with no interpreter is a glossary; an interpreter with no vocabulary cannot make its output portable; either of them with no runtime produces opinions, not enforcement. Intended is the first implementation of all three. This section describes them in that order, and explains why the middle layer — the one most easily mistaken for an implementation detail — is in fact where intent becomes governable.

Layer 1 — Open Intent: the vocabulary

Open Intent, established in Part VII, is the neutral, shared vocabulary in which autonomous actions are named. Its role in the stack is to make meaning portable: an action named in Open Intent can be compared, verified, and audited consistently regardless of the system that produced it or the system that will enforce against it. It is the strategic layer — the one with network effects and a standards trajectory — and it is necessary. It is also, by itself, not sufficient, for the reason the previous section gives: a vocabulary names actions; it does not understand them.

Layer 2 — The Large Intent Model: the interpreter

Between an autonomous system's raw behavior and a name in the vocabulary sits the hard problem: interpretation. The Large Intent Model is the layer that performs it. It is the interpretation infrastructure that converts fuzzy, contextual, sequence-dependent autonomous behavior into a structured, machine-checkable intent that can be named in Open Intent and evaluated for authority. Without it, Open Intent is a taxonomy with nothing to populate it, intent verification reverts to manual review, authority becomes subjective, and the two capabilities that make intent verification more than classification — process mapping and conformance — are not possible at all. The Large Intent Model is not a supporting detail of the runtime. It is the layer where meaning becomes governable.

Three properties make it infrastructure rather than a feature.

It maps actions to business processes, not just to categories. Most systems that touch autonomous actions classify them — they assign a label and stop. The Large Intent Model goes further: it maps a proposed action to a step in the organization's actual business process. The same surface action can carry entirely different intent depending on where it falls in a process. A single payment instruction may represent a payment approval, an invoice settlement, a vendor-onboarding disbursement, or a procurement execution, depending on context, process stage, prior actions, workflow state, and policy. Classification cannot tell these apart; only an interpretation that is aware of the process can. This is why the mapping matters, and it is worth stating as a principle: intent without process is meaningless. Intent is meaningless without context, and business process is the context — an instruction acquires its real significance only from the workflow it sits inside. Business process provides operational meaning. Enterprises already run their operations as named processes — Procure-to-Pay, Order-to-Cash, Hire-to-Retire, Claims Processing, Supply Chain Execution, Manufacturing Operations, Customer Service Resolution. The Large Intent Model converts autonomous action into process-aware intent, positioning each action within the workflow it is meant to advance. Most systems that touch autonomous behavior classify; the Large Intent Model maps to process, and that difference — classification versus process mapping — is one of the strongest lines between intent verification and everything adjacent to it. An action that is correct in isolation but wrong for its place in the process is exactly the failure Part III described, and process mapping is what makes that failure detectable.

Conformance Scoring

Process awareness enables a capability that single-action evaluation cannot provide. Conformance Scoring is the continuous measurement of how closely a stream of autonomous actions aligns with the declared workflow or operational process. Most controls evaluate one action at a time, in isolation. Conformance evaluates the sequence: the order of actions, the coverage of required steps, the progression through a workflow, and the deviations from it. A single action can look correct while the sequence it belongs to has drifted — steps skipped, performed out of order, or substituted — and that drift is invisible to any control that examines actions one at a time.

The distinction from audit is the point. Audit is retrospective: it reconstructs what a sequence of actions was, after the fact. Conformance is continuous: it scores the unfolding sequence as it happens and feeds that score into the authority decision, so that an action which would push a workflow out of conformance can be escalated or denied before it executes. Drift should be detected before outcomes occur, not reconstructed after them. Audit tells you, later, that the process went wrong. Conformance tells you, now, that the next action would take it there. It is the difference between a record and a control — and it is why Intent Verification is process-aware rather than event-based, evaluating action streams, workflow progression, process alignment, and operational drift rather than isolated events. Conformance may, in time, become a category of its own; for now it is the capability that makes intent verification continuous.

Why the Large Intent Model is not "just an LLM"

A reader who hears "model" will reasonably assume "another foundation model," and conclude the category rises and falls with one company's model quality. That assumption is wrong, and correcting it matters for the durability of the category. The Large Intent Model is not a foundation model, not a competitor to one, and not dependent on any single model. It is a runtime interpretation architecture — model-agnostic, backend-agnostic, and implementation-agnostic. Its interpretation can be driven by a deterministic rules engine, an external LLM API, a local model, or a domain-specific model, behind a stable contract. The choice of backend is an engineering decision that can change as models improve; the architecture — process-aware interpretation that produces ranked, confidence-scored, machine-checkable intent — is what endures. This is the sense in which the category outlives any particular model: the interpretation layer is required infrastructure, even as the model backend inside it is replaceable. Intent Verification depends on having an interpreter; it does not depend on which model the interpreter currently uses.

Layer 3 — The Authority Runtime: the enforcement layer

The third layer turns interpreted, named intent into an enforced decision. The Authority Engine combines verified intent, policy, conformance, risk, and operational context into a verdict — grant, escalate, deny, or route for approval. A granted decision is carried to the point of execution as a verifiable grant and enforced there by connectors, which check it independently at the boundary before the payment posts, the deployment proceeds, or the motor turns. An Evidence Chain preserves a tamper-evident, independently verifiable record of every interpretation, decision, and enforcement. This is the commercial layer — deployment, integrations, enforcement, and evidence — and its defining property is position: it sits before execution. Observability and audit attach to the action stream and describe it; the Authority Runtime stands in the path and gates it, doing what neither observation nor audit can — preventing an unintended action rather than explaining it afterward.

Three layers, three moats

Because the three layers answer different requirements, they also create different and compounding forms of defensibility:

• Strategic moat — Open Intent. The shared vocabulary, its network effects, interoperability, and standards position. The durable, category-defining layer.
• Technical moat — the Large Intent Model. Process-aware interpretation, process mapping, conformance scoring, and fail-closed behavior. The capability that turns a vocabulary into governable meaning.
• Commercial moat — the Authority Runtime. Deployment, integrations, enforcement at the boundary, and provable evidence. The layer where value is captured.

A single-moat narrative — "the vocabulary is the moat," or "the model is the moat" — understates the structure. The strength is in the stack: a neutral vocabulary that everyone can adopt, an interpretation layer that makes the vocabulary mean something, and a runtime that enforces the result and proves it. Open Intent drives adoption; the Large Intent Model creates differentiation; the Authority Runtime captures value. Each is necessary; together they are the Intent Verification Infrastructure stack.

Key Takeaways

• Intent Verification is three layers: Open Intent is the vocabulary, the Large Intent Model is the interpreter, the Authority Runtime is the enforcement layer. None substitutes for the others.
• Open Intent names actions; the Large Intent Model interprets them; the Authority Runtime decides them. Open Intent gives a common language; the Large Intent Model gives a common understanding.
• The Large Intent Model maps actions to business processes (Procure-to-Pay, Order-to-Cash, and the like), not just to categories — intent is meaningless without context, and business process is the context.
• Conformance Scoring continuously measures whether a sequence of actions aligns with the declared workflow; audit is retrospective, conformance is continuous and prospective.
• The Large Intent Model is a model-agnostic interpretation architecture, not a foundation model; the interpretation layer is required even as the model backend is replaceable. The three layers form a layered moat — strategic, technical, commercial.

Part X — Failure Modes and Design Principles

A control layer is defined as much by how it behaves when something goes wrong as by how it behaves when everything is correct. An intent-verification runtime sits in the path of every autonomous action; its failure behavior is a central design commitment, not a peripheral concern.

Intended is built on four principles. We use authority rather than consent throughout, to avoid any implication of human legal consent; the term denotes machine authority — the verified right for an action to execute.

1. Nothing autonomous acts without authority. No autonomous action executes unless authority for that specific action has been issued. There is no default-allow path that lets an action proceed simply because it was not explicitly denied.
2. Every authority decision is cryptographic. Authority is carried as a cryptographic proof, not as a flag, a configuration value, or a trusted assertion from the agent. The right to act can be presented and checked, not merely claimed.
3. Every authority decision is auditable. Each grant, escalation, denial, and enforcement is recorded as evidence, so the basis for every decision can be reconstructed.
4. Every audit is independently provable. The evidence can be verified without trusting Intended — by a connector, an auditor, or a regulator — so the record stands on its own.

These principles imply a posture: when in doubt, deny. A system that verifies intent before execution must default to withholding authority whenever it cannot establish that an action should proceed. The failure modes follow directly. A missing token denies — an action that arrives without authority does not execute. An expired token denies — aged-out authority is no longer authority. A reused token denies — single-use authority that has been spent cannot authorize a second action. A malformed token denies — authority that cannot be validated is treated as absent. Low confidence escalates — when the interpreter cannot confidently establish what an action means, the decision is escalated rather than guessed. Missing context routes for approval — when the context needed to verify intent is unavailable, the action goes to a human rather than proceeding by default. And if the audit chain is unavailable, the runtime stops issuing authority, because an unrecorded authority is one the system cannot stand behind.

This posture rests on a principle worth stating on its own, because it is where intent verification most sharply departs from how autonomous systems usually behave: ambiguity should never become authority. Most AI systems, confronted with uncertainty, resolve it by inference — they guess, and they proceed on the guess. That behavior is acceptable, even desirable, when the output is a suggestion a human will review. It is unacceptable when the output is an action that will execute. An intent-verification layer must do the opposite of guessing. When the interpreter's confidence falls below threshold, the system does not quietly infer what was probably meant and grant authority on that inference. It escalates, blocks, requests approval, or requests the missing context — but it never converts an unresolved ambiguity into a silent grant. The interpreter is built to refuse to guess: low confidence is not a gap to be smoothed over but a signal to withhold authority and ask. Ambiguity should never become authority, because authority granted on a guess is exactly the permitted-but-unintended action the entire layer exists to prevent.

The unifying commitment is a single negative requirement: there should be no silent allow path. Every route through the system that ends in an executed action must pass through an explicit, recorded grant of authority. An action must never execute merely because a check was skipped, a service was unavailable, or an ambiguity went unresolved. Fail-open and fail-closed are not symmetric choices weighed on convenience. In a layer whose purpose is to prevent unintended actions, failing open would defeat the purpose precisely in the moments the layer exists for — the uncertain, the ambiguous, the degraded. A verification layer that allows actions when it cannot verify them is not a verification layer. Fail-closed imposes a real cost: some legitimate actions will be escalated or delayed when the system is uncertain. That is the correct cost to pay, because the alternative is to let exactly the least-understood actions through unchecked. The discipline that makes intent verification trustworthy is its willingness to say "no" when it cannot confidently say "yes."

Key Takeaways

• Four principles: nothing autonomous acts without authority; every authority decision is cryptographic; every authority decision is auditable; every audit is independently provable.
• The system is fail-closed: missing, expired, reused, or malformed tokens deny; low confidence escalates; missing context routes for approval; an unavailable audit chain halts issuance.
• There should be no silent allow path — no action executes because a check was skipped or a service degraded.
• Ambiguity should never become authority: most AI systems guess under uncertainty; the interpreter is built to refuse to guess and to withhold authority instead.
• Fail-closed is the only defensible default; failing open would let exactly the least-understood actions through unchecked.

Part XI — Common Objections

A category-defining argument earns its standing by surviving the objections a skeptical reader will raise. We state each in its strongest form and answer it directly. The pattern of the answers is consistent, because the underlying distinction is consistent: each objection equates intent verification with an adjacent capability that answers a different question.

"This is just policy." Policy is written in advance and evaluated against the action in isolation; it defines a boundary of permitted actions. Intent is contextual and evaluated in the moment; it concerns whether a permitted action is the correct one given the situation. A policy expressive enough to encode every contextual purpose would need to anticipate every runtime situation in advance — which autonomy makes impossible. Intent verification consumes policy as one input and adds the dimension policy cannot capture: the match between the action and the intended purpose, now. Policy bounds; intent selects within the bound.

"This is just AI safety." Safety asks whether an action is dangerous; authority asks whether it should happen at all. These are orthogonal. A safe action can be entirely unintended, and a safety system, working correctly, will permit it — moving the wrong pallet trips no interlock. Safety is necessary and remains in place. Intent verification is the layer above it that asks whether the safe action is the intended one.

"This is just governance." Governance establishes who sets policy, how authority is delegated, and who is accountable; it operates on organizational structure and process. Intent verification operates on the individual runtime action, at machine speed, in the execution path. Governance decides who writes the rules; intent verification stands in front of each action and checks it against them. One is organizational; the other is operational and per-action. A governance program does not stop an unintended action at the moment it is about to execute.

"This is just observability." Observability explains what happened, after it happened; intent verification determines whether something should happen, before it does. The most complete trace of an unintended action is a complete record of a failure that already reached the world. Observability is a sensing function; intent verification is a control function. An organization with perfect observability and no intent verification sees every unintended action clearly — and prevents none of them.

"OpenAI can do this themselves." A reasoning provider can certainly build intent checks, but a model verifying its own proposed action is marking its own homework. The value of verification comes from independence — of implementation, incentives, and failure modes — between the system that proposes an action and the system that authorizes it. Beyond independence, there is neutrality: autonomous systems are cross-vendor, and an enterprise governing actions across multiple model providers will not route its authority layer through one of those providers. The structural point is not that a particular company cannot build a verifier; it is that a verifier owned by a proposer is weaker than an independent one, and a vocabulary owned by one vendor will not be adopted by its competitors.

"Anthropic can do this themselves." The same answer applies, and it applies to every reasoning provider symmetrically. That symmetry is the argument. If each model provider builds its own intent layer in its own vocabulary, no action's meaning can travel across providers, and the multi-vendor reality of autonomous systems goes ungoverned at exactly the boundaries that matter. The independence that makes verification trustworthy and the neutrality that makes a vocabulary adoptable both point away from any single provider owning the layer — including the strongest ones.

"OAuth already solved this." OAuth solved delegated authorization: it lets a principal grant a client scoped access to a resource. It is foundational, and intent verification borrows its spirit of scoped, verifiable grants. But an OAuth token authorizes access to a resource; it does not verify that a specific action taken with that access matches what was intended. OAuth answers "may this client act on this resource?" Intent verification answers "is this particular action the one that should occur?" An agent with a perfectly valid OAuth token can still issue the refund the customer never asked for. Access is necessary and not sufficient; the gap is downstream of the grant.

"Why can't agent frameworks solve this?" Agent frameworks orchestrate reasoning, tools, memory, and control flow — they are how autonomous systems are built, and they are the natural place to integrate intent verification. But the framework is the thing that proposes the action. Asking it to be the independent authority on whether its own proposed action matches intent collapses the separation between proposer and verifier. A framework can call an intent-verification layer the way an application calls an identity provider; it is not, by itself, that layer, for the same reason a system should not be the sole authority on its own requests. The framework builds the action; the verification has to be able to stand apart from it.

The objections share a single root, and so do the answers. Each names a real, valuable capability and assumes intent verification must be a feature of it. In every case the capability answers a question adjacent to intent — the actor, the boundary, the danger, the record, the organization, the resource, the orchestration — and in every case the Intent Gap remains — intent verification answers the one question none of them answers: does this specific action, proposed now, match what was intended, before it runs? That question is not a feature of the others. It is the definition of a new layer.

Key Takeaways

• "Just policy," "just safety," "just governance," "just observability" each equate intent verification with an adjacent capability that answers a different question.
• A model provider building its own verifier marks its own homework; independence and neutrality both point away from any single provider owning the layer.
• OAuth authorizes access to a resource; it does not verify that an action taken with that access matches intent — the gap is downstream of the grant.
• Agent frameworks are the place to integrate intent verification, not to be it; the proposer should not be the sole verifier.
• Every objection shares one root — treating intent as a feature of an adjacent layer — and intent verification answers the one question none of them does.

Part XII — Implications for Autonomous Systems

If intent verification is a missing layer, its absence is already shaping the decisions of those who build, operate, regulate, and invest in autonomous systems. The claims here are about needs autonomous action creates, not mandates it imposes.

Enterprises will likely require enforceable controls that act before execution, not only after it. As agents move from drafting to doing, the gap between "we can see what the agent did" and "we can stop the agent from doing the wrong thing" becomes a governance problem with operational and financial consequences. Observability remains essential; it needs to be complemented by a pre-execution control that can deny or escalate an unintended action while it is still preventable.

Regulators are positioned to ask not only whether an autonomous action complied with a rule, but whether the operator can prove the action was authorized — why it happened, on what basis, verifiably. An evidence trail that records intent decisions and can be checked independently is well-suited to that question. The ability to prove authority, rather than assert good behavior, is likely to become part of what compliance means in this domain.

Developers need a simple authority contract: a clear, uniform way to ask "may this action execute?" and to enforce the answer, without re-implementing intent verification inside every agent and tool. Intent verification is most useful as infrastructure with a small, stable interface — a single contract many systems adopt — rather than bespoke logic rebuilt per application.

Robotics operators need a layer above their safety controls that verifies purpose, not only danger. Their functional-safety systems are necessary and remain in place; what they lack is a control that asks whether a physically safe motion is the intended motion given the work order and the process — an authority layer that sits above the safety stack and integrates with it.

AI platforms face a structural question about independence. Verification benefits from being independent of the system that proposed the action; self-certification is weaker than independent verification. Platforms are likely to need, or integrate with, intent verification they do not wholly own — for the same reasons identity and audit are typically not owned by the systems they govern.

Standards bodies have a role in the neutral vocabulary intent verification requires. A shared, auditable way to name autonomous actions across vendors and domains benefits from open governance and eventual standardization. Open Intent, or a vocabulary like it, is a candidate for the standards process rather than something a single vendor should define unilaterally; neutral involvement strengthens the goal rather than competing with it.

Key Takeaways

• Enterprises will likely need pre-execution controls that deny or escalate an unintended action while it is still preventable.
• Regulators are positioned to require provable authority — why an action happened and on what basis, verifiable independently.
• Developers need a simple, uniform authority contract; robotics operators need a purpose-verifying layer above and integrated with safety controls.
• AI platforms benefit from independent verification over self-certification; standards bodies have a role in governing a neutral vocabulary.

Why Intent Verification Becomes Mandatory

There is a difference between a control that is useful and a control that is mandatory, and the history of infrastructure is a history of controls crossing from the first to the second. The crossing is not driven by persuasion. It is driven by scale: each control became mandatory at the moment systems could no longer scale safely without it.

Identity became mandatory because systems could not scale without proving who acted. When there were few actors and a trusted perimeter, identity could be assumed; once systems opened to many actors across many boundaries, an unprovable actor was an unacceptable risk, and identity became non-negotiable. Authorization became mandatory because systems could not scale without controlling access; ad hoc permission worked at small scale and collapsed as the number of actors and resources grew, so access control became a layer no serious system operates without. Observability became mandatory because systems could not scale without understanding what happened; a system simple enough to debug by inspection does not need it, and no system at modern scale is that simple, so observability became infrastructure with its own budgets and standards. In each case the same mechanism: the control was optional until scale made its absence untenable, and then it was mandatory, everywhere, by default.

Intent Verification is on the same trajectory, driven by the same mechanism, and the prior section named the scale that drives it. Autonomous systems cannot scale without proving actions were intended. While autonomous actions were few and human-reviewed, intent verification could be left implicit, carried by the human in the loop. As autonomous action explodes past the capacity of human oversight — as the volume moves from thousands to billions, and the human is removed from each decision by the very design of autonomy — the absence of an automatic, pre-execution intent check becomes exactly the kind of untenable risk that made identity, authorization, and observability mandatory before it. An enterprise running tens of thousands of unintended-but-permitted actions a year, with no layer that catches them, is in the position of an early network with no identity layer or an early platform with no observability: operating at a scale its controls were not built for, accumulating risk that compounds with growth.

This is why the category is inevitable rather than merely plausible. It does not depend on any company's execution, any model's capability, or any forecast about adoption curves. It depends on a structural fact: autonomous systems are designed to act faster and more broadly than human oversight can follow, and a system that acts beyond the reach of human oversight must carry its governance in the runtime or carry none at all. The control that verifies intent before execution is the only form of intent governance that scales with autonomous action. Mandatory controls are the ones systems cannot scale safely without. By that definition, Intent Verification is becoming one.

Key Takeaways

• Controls become mandatory not through persuasion but through scale: each prior control crossed from optional to required when systems could no longer scale safely without it.
• Identity, authorization, and observability each became mandatory at the point their absence became an untenable risk at scale.
• Autonomous systems cannot scale without proving actions were intended; as autonomous action outruns human oversight, the absence of a pre-execution intent check becomes the same kind of untenable risk.
• The inevitability is structural, not commercial: a system that acts beyond the reach of human oversight must carry its governance in the runtime or carry none.
• Mandatory controls are the ones systems cannot scale safely without — and by that definition Intent Verification is becoming one.

Conclusion — Who Defines the Layer

The history of computing infrastructure is a history of capabilities that were once handled informally — or assumed — becoming explicit layers once the world changed enough to make the old arrangement fail.

Identity was once an assumption: systems trusted the network, the machine, the session. Then the actor could no longer be assumed, and identity became infrastructure — authenticated, federated, standardized, and bought. Authorization was once a matter of local configuration. Then access had to cross organizational boundaries, and authorization became infrastructure, with its own protocols and its own market. Observability was once ad hoc logging. Then systems grew too complex to understand by inspection, and observability became infrastructure, with standards, platforms, and budgets of its own. Safety was once an afterthought bolted onto machines. Then machines became powerful and autonomous enough that safety became infrastructure — certified, regulated, and non-negotiable. In each case the same arc: a capability that had been implicit became a named, standardized, mandatory layer, because a shift in how systems worked made its absence intolerable.

Intent Verification is on that arc now. For decades, whether an action matched what was intended was answered by a human in the loop, and infrastructure could take the answer for granted. Autonomous systems remove the human from the moment of action and construct intent inside the machine, at runtime. The assumption that someone has already decided the action is the right one no longer holds, and nothing in the existing stack was built to replace it. Identity tells us who acted. Policy tells us what was permitted. Safety tells us whether it was dangerous. Observability tells us what happened. None of them tells us whether the action matched what was meant. That unanswered question is the Intent Gap, and it widens with every system that moves from recommending to acting.

The next decade of autonomous systems will not only ask whether these systems can act. They plainly can, and increasingly do. It will ask whether they can prove they acted as intended — with money, with infrastructure, with motion in the physical world. The next infrastructure challenge is not whether autonomous systems can act, but whether they can prove they acted as intended. Intent Verification is the layer that makes that proof possible, and the pattern of the past tells us where it is heading.

Identity became infrastructure. Authorization became infrastructure. Observability became infrastructure. Safety became infrastructure. Intent Verification will become infrastructure. The question is not whether it happens. The shift from software that executes commands to software that originates actions guarantees that it does. The only open question is who defines the layer — whose vocabulary names the actions (Open Intent, or something like it), whose runtime issues the authority, and whether that layer is neutral, independent, and provable, or captured, proprietary, and opaque.

It is worth being precise about the scope of this claim, because it is larger than any company. The layer described in this paper is going to exist whether or not any particular vendor builds it — including the one that authored this document. The forces that create it are structural, not commercial: software has begun to originate its own actions, the existing stack has no place to verify those actions against intent, and the cost of that vacancy rises with every system that crosses from recommending to acting. Those forces do not depend on a product. They describe a gap in the architecture of autonomous systems, and gaps of that kind get filled, because the cost of leaving them open eventually exceeds the cost of closing them. The open questions are which vocabulary names the actions, whose runtime issues the authority, and whether the result is neutral and provable or captured and opaque. The existence of the layer is not in question. Only its shape is.

Two sentences capture the shift at the scale it actually operates. Autonomous systems made action programmable. Intent Verification makes action accountable. The first sentence describes the last few years; the second describes the next several. The capability to turn goals into actions is now widely distributed and improving quickly. The capability to hold those actions accountable — to verify, before they run, that they match what was intended, and to prove afterward that they did — barely exists, and it is the capability the next phase of autonomous systems will be organized around. The next decade will not be defined by systems that can act. It will be defined by systems that can prove they were authorized to act.

The layer, fully stated, is three layers. Open Intent is intended to give the industry a neutral language in which autonomous actions can be named; an interpretation layer — the Large Intent Model — is what turns that language into understanding, by reading what an action means within the process it belongs to; and a runtime is what turns understanding into enforcement. Open Intent names actions. The Large Intent Model interprets them. The Authority Runtime decides them. Without the vocabulary there is no shared language; without the interpreter there is no reliable understanding; without the runtime there is no enforcement. Intended is the first implementation of all three, and the category is larger than any implementation of it. The work that matters now is not winning a product comparison. It is establishing that the layer exists, that it must be neutral and independent, and that it will carry the proof autonomous systems will be required to provide. That work proceeds whether one observes it as a participant or as an analyst documenting an emerging layer; the conclusion is the same from either chair.

The argument reduces to four lines, and we end on them.

Autonomous systems made action programmable. In the span of a few years, the ability to turn a goal into a sequence of consequential, real-world actions has become widely available and is improving faster than any control built around it.

Intent Verification makes action accountable. It is the layer that asks, before each action runs, whether that action matches what was intended — and proves, afterward, that it did.

Autonomous systems cannot scale without proving actions were intended. As autonomous action outruns human oversight, that proof can no longer be supplied by a person in the loop. It has to be produced in the runtime, automatically, before execution — which is why this layer is not optional at scale, but mandatory.

And so the conclusion is not that a company is interesting, or that an architecture is elegant. It is that this layer is going to exist, because the systems it governs cannot scale safely without it. The only questions left are whose vocabulary names the actions, whose interpreter understands them, whose runtime enforces them, and whether the result is open, neutral, and provable. The layer is inevitable. Its shape is still being decided.

Only what's intended gets executed.

Key Takeaways

• Identity, authorization, observability, and safety each followed the same arc — from implicit assumption to named, mandatory infrastructure — when a shift made their absence intolerable.
• Autonomous systems are forcing the same arc for Intent Verification, on a shorter timeline.
• The defining question of the next decade is not whether autonomous systems can act, but whether they can prove they acted as intended.
• Intent Verification will become infrastructure; the open question is not whether, but who defines the layer — and whether it is neutral, independent, and provable.
• The layer is structural, not commercial: it will exist whether or not any particular vendor builds it. Only its shape is in question.
• Autonomous systems made action programmable; Intent Verification makes action accountable. The next decade will be defined by systems that can prove they were authorized to act.
• Only what's intended gets executed.

Figures

The following figures are specified as placeholders. They describe the intended visual rather than providing final artwork.

Figure 0 — The Intent Stack. The keystone image: a single vertical stack of the control layers of an autonomous system, top to bottom, with one layer visibly inserted where nothing exists today.

Identity ↓ Authorization ↓ Policy ↓ Safety ↓ Intent Verification ← (highlighted; previously empty) ↓ Authority ↓ Execution ↓ Observability

Callout, set beside the highlighted layer: "Every layer existed. Intent was missing." Caption: the autonomous control stack already had a layer for who is acting, what is permitted, what is dangerous, what executed, and what happened — but no layer for whether the action matched what was intended. Intent Verification is that layer, inserted before execution. This is the diagram intended for keynote, analyst, investor, and web use; every other figure supports it.

Figure 1 — The Old Assumption. A single linear flow: Human intent → software command → deterministic execution. Caption: intent enters fully formed from a human; the system's job is faithful execution.

Figure 2 — The Autonomous Action Chain. A longer linear flow: Goal → model reasoning → tool selection → proposed action → execution / real-world effect. Caption: intent is no longer supplied; the system synthesizes the action from a goal and context. Contrast directly with Figure 1.

Figure 3 — The Existing Stack Fails. A vertical stack of the control layers — Identity, Authorization, Policy, Guardrails, Safety, Observability, Audit, Risk, Compliance, Governance — each annotated with the question it answers, surrounding a central column labeled "the action," with a visibly empty slot directly in front of the action labeled "Intent — no owner." Caption: every layer touches the action; none stands in front of it to verify intent.

Figure 4 — The Intent Gap. A central node labeled "Proposed Action" surrounded by four boxes — Identity, Policy, Safety, Observability — none overlapping the center; the shaded center, untouched, is labeled "Intent." Caption: existing controls surround the action but none covers whether it matched what was intended.

Figure 5 — Permitted ≠ Intended. A two-column ledger: left column "Controls" showing Identity PASS, Policy PASS, Safety PASS; right column "Intent" showing FAIL, with rotating real-world rows (refund vs. replacement; correct medication, wrong patient; safe movement, wrong destination). Caption: the same shape across every industry — authorized, permitted, safe, but not intended.

Figure 6 — The Runtime Loop. A directed pipeline: Interpret → Map → Compare → Authorize → Enforce → Evidence, with "Authorize" branching to Grant / Escalate / Deny / Route for Approval, and a marker that "Enforce" precedes and gates "Execution." Caption: verification is prospective; it gates execution rather than reporting on it.

Figure 7 — Digital and Physical Action Share the Same Primitive. Two parallel rows converging on one shared box. Top: "Agent approves invoice." Bottom: "Robot moves pallet." Both pass through a single box labeled "Authority Layer — verify intent · grant authority · enforce," then continue to "Execution." Caption: one primitive spans the digital and the physical.

Figure 8 — Open Intent as Shared Vocabulary. Several heterogeneous source systems on the left — Model Vendor A agent, Model Vendor B agent, RPA workflow, robotics planner — each mapping into a central vocabulary labeled "Open Intent," which feeds verification and audit. Caption: a neutral vocabulary lets actions from many systems be named, compared, and verified consistently. Beside it, a row of precedents — TCP/IP, HTTP, OAuth/OpenID, OpenAPI, Open Intent — each labeled "the shared layer everyone converged on."

Figure 9 — The Infrastructure Arc. A timeline of layers that became infrastructure — Identity, Authorization, Observability, Safety — each marked "implicit → mandatory," with Intent Verification placed next on the line, marked "now." Caption: the same arc, on a shorter timeline.

Figure 10 — The Intended Runtime Stack. A vertical stack: Intent Layer (Large Intent Model) → Open Intent mapping → Authority Engine → Authority Token → Connectors (enforcement) → Evidence Chain, with a side annotation marking the position "before execution." Caption: the first implementation of the category.

Figure 11 — The Intent Verification Stack. The most important architectural diagram in the paper. Four stacked layers, top to bottom, each with a one-line role and a downward arrow between them:

• Layer 1 — Open Intent. Shared vocabulary. (Vocabulary)
• Layer 2 — Large Intent Model. Interpretation layer — process-aware understanding, conformance. (Understanding)
• Layer 3 — Authority Runtime. Enforcement layer — decision, token, connectors, evidence. (Authority)
• Layer 4 — Execution Systems. APIs, agents, robots, enterprise systems. (Action)

A vertical flow label runs down the right edge: Vocabulary → Understanding → Authority → Action. Caption: Intent Verification is three layers above the systems that act — a vocabulary to name actions, an interpreter to understand them, and a runtime to authorize them. Open Intent names; the Large Intent Model interprets; the Authority Runtime decides; only then does execution proceed.

Glossary

Autonomous System. A software or physical system capable of selecting and initiating actions without direct human execution at every step. Includes AI agents, tool-using LLM workflows, autonomous DevOps agents, finance and support agents, and physical systems such as robots, drones, cobots, and autonomous mobile robots (AMRs).

Intent. The intended meaning, purpose, or desired outcome of an action in a specific operational context. Not the same as prompt text, user instruction, API call, policy permission, model reasoning trace, output safety, or authentication.

Intent Verification. The runtime process of determining whether a proposed autonomous action matches the declared purpose, process, and operational context before execution.

Intent Gap. The space between what an autonomous system is permitted to do and what it was actually intended to do.

Authority. The verified right for a specific action to execute in a specific context. Authority is not assumed; it is granted after intent verification.

Authority Token. A cryptographic proof that a specific action has been verified and authorized for execution under specific scope, time, and context constraints. Single-use, scoped, time-bound, independently verifiable, and evidence-producing.

Open Intent. A neutral, open vocabulary for naming autonomous actions across systems, vendors, and domains, so actions can be named, compared, verified, and audited consistently.

Large Intent Model. The interpretation layer of the Intent Verification stack: a model-agnostic runtime architecture (not a foundation model) that converts fuzzy natural-language or tool-call behavior into process-aware, machine-checkable intent — ranked hypotheses, confidence scores, rationale, assumed context, missing-field disclosure, and structured intent objects — independently of the model that proposed the action. Its interpretation may be driven by a rules engine, an external LLM API, a local model, or a domain-specific model behind a stable contract; the architecture endures even as the backend changes.

Process Mapping. The capability, performed by the Large Intent Model, of placing a proposed action within the organization's actual business process (for example, Procure-to-Pay or Order-to-Cash), so that intent is evaluated with the context that gives it meaning. Distinct from classification, which labels an action without locating it in a process.

Conformance Scoring. The continuous measurement of how closely a stream of autonomous actions aligns with the declared workflow or operational process — evaluating sequence, order, coverage, and deviation rather than single actions. Continuous and prospective, in contrast to audit, which is retrospective.

Authority Engine. The component that combines verified intent with policy, process conformance, risk, and context to produce an authority decision: grant, escalate, deny, or route for approval.

Connector. An enforcement point at a target system that verifies an Authority Token at the execution boundary, independently, before an action runs.

Evidence Chain. A tamper-evident record of interpretation, authority decisions, and enforcement, designed to be verified independently of Intended.

Fail-Closed. A design posture in which the absence of a positive, verified authority resolves to denial, escalation, or routing for approval — never to a silent allow.

Runtime Boundary. The point at which an action would actually execute (for example, a database write or a motor command), where authority is enforced before the action proceeds.

Physical AI. Autonomous systems that take action in the physical world — robots, cobots, drones, AMRs, and similar machines driven by AI planners or learned policies — where an unintended action can become a safety event rather than a recoverable error.

Permitted ≠ Intended. The shorthand for the Intent Gap: an action can be authorized, permitted, and safe, and still not be the action that was intended.

Intended · Authority infrastructure for autonomous systems · Open Intent · Verify intent. Grant authority. Execute. · Only what's intended gets executed.