--- before.md +++ after.md @@ -1,11 +1,12 @@ --- date: '2026-06-10T09:00:00-07:00' +lastmod: '2026-09-16T22:20:00-07:00' draft: false title: "Authorization Is the Other Half of Executable Intent" subtitle: "Evals Made Intent Executable for Verification. A Mission Makes It Executable for Authorization." slug: "authorization-is-the-other-half-of-executable-intent" -description: "Evaluations made human intent executable for verification: did the agent behave? Authorization needs the same move for the other question, what the agent should be allowed to do. A shaped, validated, and approved mission turns an open-ended request into a bounded authority enforced at runtime, the preventive twin of an eval." -summary: "Microsoft's ASSERT compiles written behavior requirements into executable evaluations: intent made executable for verification. That answers what the agent did, not what it was allowed to do: an eval produces a verdict, not a binding authorization decision, and for irreversible actions that is the whole difference. The mission is the preventive counterpart: a shaper proposes the request as a bounded, machine-readable object, a trusted authority validates and narrows it, an approver signs off, and enforcement checks every consequential action against it. Same lineage from natural-language intent, a higher bar, and teeth an eval does not have. One approved mission then drives both the runtime boundary and the behavioral eval, while a separate shaping-quality check asks whether the boundary matched the user's intent in the first place." +description: "Evaluations make intent executable for verification and can gate actions at runtime. A shaped, validated, and approved mission makes intent executable for authorization: the bounded authority within which those judgments operate." +summary: "Microsoft's ASSERT compiles written behavior requirements into executable evaluations. Runtime evaluators can also block proposed actions, request evidence, or trigger escalation. A favorable judgment still cannot independently establish or expand an agent's authority. The mission supplies that task boundary: a shaper proposes, a trusted authority validates and narrows, an approver signs off, and enforcement checks each consequential action against current authority. One approved mission can drive authorization rules, runtime behavioral checks, and retrospective evaluation, while a separate shaping-quality check asks whether the boundary matched the user's intent in the first place." tags: - Agentic Identity - Authorization @@ -15,11 +16,13 @@ - Standards --- +> **Revision — September 16, 2026.** The earlier version described evaluations too broadly as retrospective controls. Runtime evaluators can also block actions before execution. This revision updates the comparison table and guardrail discussion to distinguish behavioral judgment from authorization. The central claim remains: a favorable judgment cannot independently establish or expand an agent's authority. [Revision history](#revision-history). + You can hand a framework a written description of how your agent should behave and get back a suite of tests that catch it misbehaving. Not by hand-authoring every assertion: you describe the behavior, declare the dimensions that matter, and a model compiles the rest into tests that run. The capability is new, and the pattern behind it is about to be everywhere. It is half of a control. -Tests tell you, after a run, whether the agent behaved. They say nothing about what the agent was allowed to do before it started. For a stateless chatbot answering over non-sensitive data, that gap barely mattered; the worst case was a bad answer you could throw away. For an agent that files expenses, moves tickets, queries financial systems, and sends mail, it is the whole game. These things act across systems their authors do not control, and some of what they do does not undo. +Evaluations test whether behavior meets a specification. They can run before deployment, inspect completed work, or participate in execution by checking a proposed action before it happens. That last form can prevent harm. It still leaves a separate question: what authority does this agent hold for this task? For an agent that files expenses, queries financial systems, or sends mail, both questions matter. A proposed action can look useful and well supported while reaching a resource the user never authorized. The question is no longer only whether the agent behaved, but what it was allowed to do in the first place. The industry is meeting that second question with the instinct it brought to the first: stop leaving intent in prose only a human can act on, and compile it into something a machine can execute. That showed up first in testing. It belongs just as much in authorization, where, even as the enforcement standards keep shipping, the step that compiles intent into them has barely begun. @@ -31,23 +34,25 @@ Strip away the specifics and the move is general: take intent expressed in language, compile it into a structured artifact, and let that artifact do the work the prose never could. ASSERT makes intent executable for verification, answering, at far less cost, the question teams used to answer one test at a time: did the agent behave the way we said it should? -It says nothing about a different question, one that comes earlier in time and matters more for anything that cannot be undone: what should the agent have been allowed to do at all? - -# Verification Is Not Enforcement +That assessment does not itself establish what the agent should have been allowed to do. For actions that cannot be undone, both behavioral judgment and authority must be considered before the effect. + +# Judgment and Authority {#verification-is-not-enforcement} Those two questions sound like neighbors. They are different controls, and the difference is not academic. Picture the billing agent. You hand it a task that sounds routine: resolve a customer's billing dispute. To do that it pulls up the account, reads the invoices, checks payment history, updates the support ticket. Somewhere in the middle, a support note it ingests nudges its reasoning, or it simply generalizes "look at the customer's records" a little too far, and it queries a second customer's account to compare. Nothing in its instructions forbade it. It was holding a credential that worked. -In an eval-only world, here is how that plays out. The release-gating suite passed before any of this shipped: this run, with this injected note and this data, was never one of the cases it generated. The agent runs in production, the second customer's data is read, already in context, possibly summarized into an output you cannot recall, and nothing flags it in the moment. You learn about it later, from a log or an incident. A post-hoc eval over the trace could score it after the fact, but after the fact is exactly the problem. A clean release report sits comfortably beside a real breach. - -That is the difference, and it is not really about timing. An eval, even one wired to run inline, produces a verdict, not a binding entitlement decision; an authorization system makes the decision and refuses at the moment of the call. The release-gating and post-hoc evals here also run too late to matter. An agent that reads private data, takes in untrusted content, and can act on the outside world, the combination Simon Willison named the lethal trifecta, does things that do not reverse. You cannot un-send a payment, un-email a list, or un-leak a contract. The usual advice for the trifecta is to break it by removing a leg; an eval removes none. It watches an agent that still has all three, and detection does not give the data back. - -A camera is not a lock. Monitoring records the break-in; the lock prevents it. Agents got cameras first because grading is easy: you can score behavior without touching the runtime, while enforcement means deciding, live, inside the path of every call, what the agent may reach. The easier half shipped first. It is not the half that stops anything. +With only release-gating and post-hoc evaluations, here is how that plays out. The release-gating suite passed before any of this shipped: this run, with this injected note and this data, was never one of the cases it generated. The agent runs in production, the second customer's data is read, already in context, possibly summarized into an output you cannot recall, and nothing flags it in the moment. You learn about it later, from a log or an incident. A post-hoc eval over the trace could score it after the fact, but after the fact is exactly the problem. A clean release report sits comfortably beside a real breach. + +An inline evaluator could catch the proposed cross-customer read and stop it. That is a preventive control, and it belongs in the architecture. But if the evaluator approves the read, the system still needs to establish whether this principal, acting for this user on this task, may access that customer's account. + +The distinction is what makes the decision legitimate. A behavioral judgment assesses an action against criteria. Authorization checks it against approved authority, current Mission state, delegation, and resource policy. A favorable judgment cannot override a denial from those checks. Conversely, passing the authorization checks does not establish that the action is sensible or faithful to the user's purpose. + +Both controls need an enforcement point capable of stopping the action before its effect. Neither helps prevent a disclosure if its verdict arrives after the data has moved. # The Missing Step -So put a lock on it. We are not short on locks. Fine-grained authorization, policy engines, runtime decision points, scoped tokens: the machinery to refuse a call at the moment it is made exists and keeps improving. The same Build 2026 trust stack that shipped ASSERT also shipped the [Agent Control Specification](https://devblogs.microsoft.com/foundry/build-2026-open-trust-stack-ai-agents/), a portable standard for deterministic controls at checkpoints across an agent's workflow. But ACS, like every lock on that list, assumes the controls already exist, authored separately. None of them turns a goal into the controls it should carry. The trouble is upstream. The instruction you started with does not describe a boundary for any of that machinery to enforce. +The machinery to refuse a call at the moment it is made exists and keeps improving: fine-grained authorization, policy engines, runtime decision points, scoped tokens. The same Build 2026 trust stack that shipped ASSERT also shipped the [Agent Control Specification](https://devblogs.microsoft.com/foundry/build-2026-open-trust-stack-ai-agents/), a portable standard for deterministic controls at checkpoints across an agent's workflow. Those enforcement mechanisms still need controls to apply. The upstream problem is turning a goal into the task boundary they should enforce. The instruction you started with does not describe that boundary. "Resolve the customer's billing dispute" is a goal. It names an outcome, not a boundary. To pursue it the agent legitimately needs the customer's account, their invoices, and the open ticket. It almost certainly does not need payroll, the source repository, HR records, or any other customer. But none of that is written anywhere. The user said what they wanted accomplished and nothing about scope, because to a human the scope goes without saying. To an agent, nothing goes without saying. @@ -81,7 +86,7 @@ This is the executable authorization: the mission compiled into a boundary a policy engine evaluates on every consequential call. Read account 1234 and the request matches an allow rule and clears. Reach for account 5678, the customer the agent drifted to in the breach, and nothing matches, the default denies, and the call returns nothing. Not data plus a note for a reviewer next week. Nothing. And notice what is not happening: no model is deciding whether to grant. A model may still contribute a signal, a risk score or a content classification, but it cannot hold the authority or widen it. The authority was fixed and approved before the agent started, and the call is evaluated fresh against it: current mission state (a revoked or expired mission fails closed), the resource's own policy, the actor, and the parameters. The model can advise; the approved authority caps what may be permitted, and the PDP decides within that cap. -A fixed, pre-approved boundary does not make the trifecta safe. An injected agent can still combine the private reads the mission permits with the outbound actions it permits, and exfiltrate within scope. What the boundary buys is a bounded blast radius: the injection cannot widen what the agent may reach, so exposure is capped at the task's authority instead of the agent's whole credential. Capping is not closing. Closing is the rest of the work: private-read, untrusted-input, and external-action authority separately typed, each consequential action evaluated as it happens with its parameters bound in, egress behind the same control, step-up approval on the highest-stakes steps. A mission does not dissolve the trifecta. It makes it governable, which is the most any boundary can honestly claim. +A fixed, pre-approved boundary does not make the lethal trifecta safe: an agent may still combine private-data access, untrusted-content ingestion, and external actions. An injected agent can still combine the private reads the mission permits with the outbound actions it permits, and exfiltrate within scope. What the boundary buys is a bounded blast radius: the injection cannot widen what the agent may reach, so exposure is capped at the task's authority instead of the agent's whole credential. Capping is not closing. Closing is the rest of the work: private-read, untrusted-input, and external-action authority separately typed, each consequential action evaluated as it happens with its parameters bound in, egress behind the same control, step-up approval on the highest-stakes steps. A mission does not dissolve the trifecta. It makes it governable, which is the most any boundary can honestly claim. The mission and the rules it produces are worth keeping straight. The mission is the artifact you stand behind: human-readable, the record of what the task was for and why these objects and not others, signed off by its approver and readable later by an auditor. The executable authorization is that mission in force: literal, machine-facing rules an enforcement point runs throughout the task, meaningless on their own without the mission that explains them. The mission is approved once; the enforcement point runs its rules a thousand times. It is the relationship an eval has to a test run: you stand behind the artifact, the machine executes it. @@ -103,49 +108,43 @@ If you have written an eval, you have already done this once. You took intent in language and compiled it into an artifact a machine acts on. You did it for the verification side. The mission is the authorization counterpart, built with the same compilation pattern, and most teams that have the first do not yet have the second. -Both begin with intent in plain language. Both compile that language into a structured artifact, often with a model, though a rules engine, a form, or a workflow can do the shaping too. Both exist so that something a human meant can be acted on by a machine that would otherwise see only tokens. ASSERT compiles intent into a test that asks, after the run, did the agent behave? On the authorization side, the same kind of intent is shaped into a proposal, validated and narrowed, derived into a candidate authority, then approved and activated as the boundary that asks, before the run, what may the agent do? +Both begin with intent in plain language. Both compile that language into a structured artifact, often with a model, though a rules engine, a form, or a workflow can do the shaping too. Both exist so that something a human meant can be acted on by a machine that would otherwise see only tokens. ASSERT compiles intent into tests of observed behavior. Runtime evaluators can also check proposed work before it proceeds. On the authorization side, intent is shaped into a proposal, validated and narrowed, derived into candidate authority, then approved and activated as the boundary checked at each consequential action. If you understand why generated evals are a good idea, you already understand why generated authorization boundaries are. The reason to compile rather than hand-author is the same on both sides: the inputs are open-ended. You stopped hand-writing test suites because you could not enumerate every behavior worth checking; you cannot hand-write a scope for every task a user might dream up either. A goal no one anticipated still needs a boundary, and something has to turn the task into one. The symmetry is what makes the analogy useful. The asymmetry is what makes it matter: -| | Eval (e.g. ASSERT) | Mission object | +| | Evaluation | Approved Mission | | --- | --- | --- | -| Derived from | written intent | written intent | -| Produced by | a model, reviewed by a human | proposed by a shaper, validated by a state authority, approved by a principal or policy | -| Binds | nothing; produces a non-binding verdict | each consequential action, through the PDP that enforces it | -| Role | detective: did it behave? | preventive: what may it do? | -| Lifecycle | a durable suite, reused across runs | per task, short-lived, tied to one goal | -| Authority | none; it observes and scores | governs the authority set a PDP permits and denies against | -| Cost of being wrong | a false pass greenlights a vulnerable release | this execution is wrongly authorized | - -Read the bottom rows together. An eval carries no authority; it produces evidence. A wrong eval is not harmless, a false pass can greenlight a vulnerable release, but it does its damage indirectly, by feeding a deployment decision a human still owns. A mission governs authority directly. It is not advice a later decision weighs; it commits to an authority set that every runtime check is made against, so a wrong mission is wrong at the moment of each action it governs. That is why a mission cannot be an eval turned around. The same construction, once it confers authority rather than evidence, needs what an eval never had: an approval path, a default that denies when intent is unclear, and a lifecycle that ends. - -There is a sharper way to feel it. An eval is re-runnable: tune the suite, run it again, watch the score move, all before anything ships. An approved mission is not a rehearsal. You improve the shaping offline, on past tasks, with evals, but once a mission is active its authority is live, and the first action under it is the real thing. It can still be suspended or expired; what it cannot be is quietly re-run against the world the way a test is. - -# Why Not Just Judge Every Action? - -If a mission is so much more fraught than an eval, the obvious shortcut is to skip the artifact. Keep the model in the loop, point it at each action before the agent takes it, and let it decide. An LLM judge as the gate. People are already building this, under the name guardrails. - -It does not hold up as authorization, and seeing why is the clearest case for the mission. - -Run the judge after the fact and you are back to detection: the action happened, the score came late, the data already moved. So the judge has to run inline, before each call. The moment it does, three problems arrive together. - -It makes a security decision probabilistic, turning allow or deny on how a model reads a situation rather than on a rule that, for the same inputs and policy version, returns the same answer every time. And the model is injectable: give the judge enough context to make a real call and you have handed it the same untrusted content steering the agent, so the injection that fools the agent also gets a vote on allowing it. Starve it of that context and it can no longer judge much, collapsing toward a fixed rule, a conventional deterministic policy check with a model's latency bolted on, and none of a mission's task-specific authority at that. A grant should be the one thing untrusted input cannot argue with. A model in the decision path is the opposite. - -It answers the wrong question. An eval scores behavioral conformance: does this transcript look like the spec? Authorization is an entitlement check: may this principal, acting for this user, touch this resource right now, given delegation, tenant, and revocation? A model reading a conversation cannot know whether this customer's agent may read that customer's invoice; that fact lives in the identity and entitlement systems, not the transcript. Give the judge access to them and the authority has moved into them, where it belongs. The model can still help, classifying risk or reading context that the policy then weighs, but it is no longer the thing that decides. That is the line: a model may inform an authorization decision; it must not be the authority that makes it, and it must not be able to widen access on its own. - -And it still needs something to judge against. A generic global rule, do not touch other customers, is not least privilege; it cannot say this task may read these three things and nothing else. The per-task specification the judge would check is the mission. Skip the artifact and you have not removed the mission, you have buried it in a prompt and made it non-deterministic and unauditable. - -The division of labor is not a turf fight. An eval observes. A guardrail filters. A mission authorizes. An inline judge is a fine extra guardrail and a poor authorization system, because what authorizes has to be deterministic, inspectable, bound to an identity, and fixed before execution, so the untrusted content the agent ingests as it runs cannot alter or widen it. That is the approved mission and the authority set it commits, not a model deciding live. +| Main question | Does the proposed or observed behavior meet the criteria? | What authority exists for this task? | +| Runtime role | Can inform continuation, retry, blocking, or escalation | Supplies task bounds for authorization checks | +| Authority | A favorable verdict does not independently confer access | Records approved task authority, subject to other applicable controls | +| Lifecycle | Versioned criteria used offline or during execution | Task-bound approval with expiry, suspension, and termination | +| Failure consequence | A false pass can admit harmful work; a false rejection can block legitimate work | Incorrect bounds can permit excess access or prevent necessary work | + +Both artifacts can affect a live execution. A runtime evaluator's false pass can let a harmful action proceed; its false rejection can stop legitimate work. An incorrectly shaped Mission can grant too much authority or too little. The distinction is what each artifact establishes: an assessment of behavior, or an approved task boundary that the authorization system enforces. A judgment used to control execution needs an explicit policy for how its result is handled. A grant additionally needs authority provenance, an approval path, and a lifecycle that ends. + +Offline evaluation allows rehearsal against recorded or simulated cases. Once an evaluator participates in live execution, its mistakes can have immediate consequences, just as mistakes in the Mission can. Both need validation before deployment and evidence from their use. + +# Where Runtime Judges Fit {#why-not-just-judge-every-action} + +A runtime judge can assess whether evidence supports a proposed action, whether an output serves the approved purpose, or whether the work appears complete. These are useful checks even when the action falls within the Mission's authority. + +In this architecture, the judge's assessment can restrict execution within that authority. It can cause the system to pause, request more evidence, or seek approval. It cannot authorize a resource outside the approved boundary, revive an expired Mission, or override a revoked delegation. Work requiring broader authority follows the governed expansion path. + +The assessment remains fallible. A judge can misread the task or be influenced by the content it evaluates. Deterministic code can enforce how its verdict is used, but cannot make that verdict semantically correct. Structural authorization must remain effective when the judge makes a mistake. + +The Mission also supplies a stable reference for judgment: the approved purpose, constraints, and success criteria. The runtime can ask whether an action serves that purpose without allowing the answer to rewrite the authority under which it acts. The [runtime-enforcement design](/notes/mission-bound-runtime-enforcement/#the-lethal-trifecta-at-execution-time) composes semantic assessments as additional restrictions, while [runtime alignment](/notes/mission-shaping-is-not-enough/#runtime-alignment-trust-scores-and-budgets) governs whether work should continue. # The Hard Part Is the Same Hard Part -Keeping the model out of the gate raises a fair follow-up. The shaper that produces the mission is often a language model too, the very thing whose judgment we are trying to contain. It does not have to be: a rules engine, a form, or a workflow can shape just as well, and there the question never arises. But take the hardest case, a model shaper: if an inline judge is too injectable to authorize, why is a model trustworthy enough to write the boundary? It sounds like handing the fox the keys. - -It would be, if the model's output were the grant. It is not, and that distinction is the whole design. The shaper proposes a mission intent; a state authority validates and narrows it, derives the candidate authority, and renders it for approval by a person or a policy precise enough to stand in for one; only on approval does the mission become active, and that approved mission, fixed and inspectable, is what gets enforced, not the model's live reasoning as it runs. The model drafts, something accountable disposes, and the approved artifact is what binds. - -The eval world already trusts model-generated artifacts this way: ASSERT writes its tests with a model and scores them with a judge, and the answer to "why trust that" is not faith but review and a measured judge-human agreement rate. The mission side needs the same discipline at a higher bar, and the reason the bar is higher is the point. Grading is allowed to be approximate: a judge whose agreement with human reviewers has been measured for the behaviors it scores can be good enough, though that agreement varies by model and by how fine the policy distinction is. Authorization cannot be approximate; a grant that is right most of the time is a breach the rest of the time. So a model can decide an eval, but on the authorization side it can only draft the artifact an accountable principal or governing policy approves and a deterministic check enforces. Same model, same intent, different tolerance for being wrong. +Keeping model judgment subordinate to approved authority raises a fair follow-up. The shaper that proposes the mission is often a language model too. Rules engines, forms, and workflows can shape proposals as well, but a model shaper makes the question especially clear: why trust its interpretation of intent to define the boundary? + +Treating the model's output as the grant would leave that question unanswered. The design requires a separate authorization step. The shaper proposes a mission intent; a state authority validates and narrows it, derives the candidate authority, and renders it for approval by a person or a policy precise enough to stand in for one; only on approval does the mission become active, and that approved mission, fixed and inspectable, is what gets enforced, not the model's live reasoning as it runs. The model drafts, something accountable disposes, and the approved artifact is what binds. + +Model-generated evaluations and model-generated Mission proposals both need review and validation. Judge agreement with independently reviewed examples matters wherever a judgment influences execution; the acceptable error depends on the consequence of being wrong. A live release gate can demand as much scrutiny as an authorization check. + +For the Mission, validation must also establish that the proposed authority comes from a legitimate source and stays within the principal's and resource owner's bounds. A deterministic check can enforce the approved artifact consistently. It cannot prove that the artifact faithfully captured human intent. That is why shaping quality remains a separate evaluation problem, and why containment is still necessary when the boundary is wrong. The difficulties that remain are the ones you would expect from making fuzzy human intent binding: @@ -153,15 +152,15 @@ - **Scope needs domain knowledge.** "Billing domain only" has to resolve to the resources and actions the billing systems actually expose. The shaper proposes the shape; the systems that own those resources confirm it is real and allowed. Intent does not get to invent capabilities that do not exist. - **Tight missions break tasks.** The price of any preventive control is false denials, and a mission drawn too tight strands the agent halfway through legitimate work. The answer is the governed widening from earlier, not drawing missions loose enough to never get in the way. -None of these is a reason to wait, but they are a reason to be honest about the size of it. This is a heavier build than an eval harness: shaping, derivation, enforcement, an approval path, a way to widen a mission mid-task. Evals had a head start because grading is cheap to build and its mistakes have a smaller direct blast radius. Authorization has neither advantage, which is exactly why irreversible actions cannot keep waiting for it. +The implementation has several obligations: shaping, derivation, enforcement, an approval path, and a way to widen a mission mid-task. Runtime evaluation adds its own obligations around calibration, failure handling, and intervention. Neither system gets a smaller assurance burden merely because it is called an eval or an authorization service; the consequences of its decisions determine that burden. # One Source, Many Artifacts Follow this far enough and a larger architecture appears. One approved mission need not feed only the enforcement rules. The same validated intent and authority set can drive the runtime constraints and the behavioral evals as well, each compiled from the artifact that was already approved, not from the raw prose. -Deriving them from that shared, approved source keeps things aligned. An approved mission carries both an authority set and a goal with constraints and success criteria, so it can generate two kinds of eval: one asking whether the agent stayed within its granted authority, and one, the behavioral eval ASSERT actually writes, asking whether it pursued the goal within those constraints and met the success criteria. - -On the authorization side, a flagged behavior means different things depending on what enforcement did. An out-of-bounds attempt the PDP denied is a misbehaving agent and a working control, worth correcting, not a breach. An out-of-bounds action that went through is an enforcement or materialization failure. An in-bounds action that still did harm points elsewhere: the mission was too broad, or the resource's policy was. And none of it says whether the mission captured the user's intent to begin with; that is a separate question for a shaping-quality eval or a human-labelled oracle scoring the mission against the original intent, not against itself. Conformance and faithfulness are different checks, and one artifact answers only the first. The loop closes: +Deriving them from that shared, approved source keeps their reference point aligned. An approved mission carries both an authority set and a goal with constraints and success criteria, so it can generate two kinds of eval: one asking whether the agent stayed within its granted authority, and one, the behavioral eval ASSERT actually writes, asking whether it pursued the goal within those constraints and met the success criteria. + +On the authorization side, a flagged behavior means different things depending on what enforcement did. An out-of-bounds attempt the PDP denied is a misbehaving agent and a working control, worth correcting, not a breach. An out-of-bounds action that went through is an enforcement or materialization failure. An in-bounds action that still did harm points elsewhere: the mission was too broad, or the resource's policy was. And none of it says whether the mission captured the user's intent to begin with; that is a separate question for a shaping-quality eval or a human-labelled oracle scoring the mission against the original intent, not against itself. Conformance and faithfulness are different checks, and one artifact answers only the first. Runtime checks use that same approved reference before an action proceeds, while retrospective evaluation checks the execution record. The loop closes: ```mermaid flowchart TB @@ -169,23 +168,43 @@ Shape -->|proposed intent| Auth[State authority
validate, narrow, derive] Auth -->|rendered for approval| Approve{Approver
principal or policy} Approve -->|approved| Mission[Mission + authority set] - Mission -->|audience-scoped projection| PDP[Per-call decision / PDP] - Ctx[Runtime context
mission state, actor, resource policy, parameters] --> PDP - PDP -->|permit| Exec[Agent execution] - Exec -->|each consequential action| PDP - Exec --> Eval[Evaluation, e.g. ASSERT] + Mission -->|authority bounds| PDP[Per-call decision / PDP] + Mission -->|purpose and criteria| Judge[Runtime behavioral checks] + Action[Proposed consequential action] --> Judge + Action --> PDP + Ctx[Current mission state, actor,
resource policy, parameters] --> PDP + Judge -->|additional restrictions only| PDP + PDP -->|permit| PEP[Enforcement point] + PEP --> Exec[Execute bound action] + PDP -->|deny or pause| Hold[Stop or governed recovery] + Exec -->|next proposed action| Action + Exec --> Eval[Retrospective evaluation] + Mission -->|approved reference| Eval Eval --> Verify([Behavior verification]) Verify -.->|findings refine the next mission| Shape ``` -The first half constrains the agent before it acts; the second checks what it did. The dotted edge is the part most people skip, but a finding does not name its own fix: read against the cases above, it points at a layer, the agent, enforcement, the mission, or the shaping behind it, and that is where the correction goes, not always into a sharper test. +Authorization and required runtime checks constrain execution before the effect; retrospective evaluation examines what happened. A favorable runtime judgment never supplies missing authority, and any revised action must be checked again before execution. The dotted edge is the part most people skip, but a finding does not name its own fix: read against the cases above, it points at a layer, the agent, enforcement, the mission, or the shaping behind it, and that is where the correction goes, not always into a sharper test. # The Chain Worth Building None of this is really about prompts, or policies, or evals as separate wins. It is about a chain. Intent enters as a sentence a person types, and today it dissolves almost immediately: the prompt runs, the agent fans out across tools, and the original goal survives, if at all, as a line in a log someone might grep after something goes wrong. The opportunity is to keep that intent intact and load-bearing the whole way through, from the goal, into the authority the agent is granted, through the actions it takes, into the verdict on whether it behaved. -The pieces are arriving. Executable evaluations are furthest along, because grading is the safest place to start. Executable authorization, with a mission object as its artifact, is arriving second but has to run first, because shipping agents with evals and nothing on the authorization side leaves you with detection on actions that do not undo. A camera pointed at a door with no lock. Worth having, and not the same as safe. +Executable evaluations and executable authorization belong in the same architecture. A system can stop work because the proposed behavior fails its criteria, because the action exceeds approved authority, or both. The Mission keeps that authority explicit and supplies the purpose against which behavior is judged. Runtime checks and later evaluation help identify where the work, the boundary, or the shaping itself needs correction. Both rest on the same conviction, and it is worth saying plainly: Human intent should not stay trapped in natural language. It should become something a machine can enforce and verify. And it should be the same intent on both sides. + +# Revision History + +**September 16, 2026 — Correction and substantive update.** + +- Corrected the characterization of evaluations as exclusively retrospective and their errors as only indirect. The opening, description, summary, comparison table, and conclusion now recognize preventive runtime evaluation. +- Replaced the camera/lock analogy and guardrail discussion with an explicit boundary: runtime judgments may restrict execution but cannot independently confer or expand authority. +- Updated the diagram to show runtime judgments as additional restrictions before execution, alongside retrospective evaluation. Preserved the existing links to renamed sections. +- Made validation requirements depend on the consequences of a decision, and distinguished deterministic enforcement from the semantic fidelity of the shaped Mission. + +[Version preserved before this revision](/revisions/authorization-is-the-other-half-of-executable-intent/2026-09-16/) · [Exact diff](/revisions/authorization-is-the-other-half-of-executable-intent/2026-09-16/changes.html) · [Revision source](/revisions/authorization-is-the-other-half-of-executable-intent/2026-09-16/after.md) · [Source hashes and provenance](/revisions/authorization-is-the-other-half-of-executable-intent/2026-09-16/manifest.json). + +The preserved version is the repository text immediately before this revision, not a claim about the original publication or its deployment date. Earlier editorial history is not reconstructed here.