Authorization Is the Other Half of Executable Intent

Publication date recorded in the source: 2026-06-10

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.

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.

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.

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.

Intent That Runs

Start with the half that already works, because it shows the move in its cleanest form.

Microsoft’s ASSERT, short for Adaptive Spec-driven Scoring for Evaluation and Regression Testing and released as part of its open trust stack at Build 2026, is a clean instance of the pattern. You write the behavior you expect. ASSERT derives behavior categories from it, generates single- and multi-turn test cases, runs them against your agent, and uses an LLM judge to score each conversation against your policy, tracing each verdict to the policy stance and the trace action behind it (Microsoft’s writeup). Written intent in, a reviewable test suite out, none of it hand-authored case by case.

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?

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

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.

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

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, 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.

Closing that gap is the mission shaping problem: taking the open-ended request and turning it, before the agent acts, into a structured and bounded statement of what the task is and is not. I have written about why open-world OAuth needs that shaping step rather than a static grant. Applied to the billing agent, the shaper’s proposal looks like this:

1
2
3
4
5
6
7

{
  "goal": "Resolve the customer's billing dispute",
  "objects": ["customer 1234's account", "their invoices", "support ticket 456"],
  "constraints": ["read-only except updating the ticket", "billing domain only", "this customer only"],
  "success_criteria": ["dispute resolved or escalated to a human", "ticket updated"],
  "expires_at": "2026-06-30T18:00:00Z"
}

That object is not yet authorization, and it is not yet trusted. Whatever does the shaping, a model here, produces only a proposal. A trusted authority validates it against policy, narrows it, derives the candidate authority, and records an approval before any of it binds; only an approved mission is active. Skip that and you are enforcing whatever the shaper asked for. What enforcement then checks, on every consequential call, is the authority that survived approval.

Materialization turns the whole approved mission into something a machine executes: the authority set along with the tenant and actor bounds, the capability bindings, and the policy version it was approved under. It takes the resource systems’ help, since only the billing systems know which resources and actions they actually expose. Simplified, the result is rules an enforcement point can check without interpreting any natural language:

1
2
3
4
5
6
7
8
9

{
  "allow": [
    { "action": "read",   "resource": "account", "where": { "customer": "1234" } },
    { "action": "read",   "resource": "invoice", "where": { "customer": "1234" } },
    { "action": "update", "resource": "ticket",  "where": { "id": "456" } }
  ],
  "default": "deny",
  "expires": "2026-06-30T18:00:00Z"
}

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 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.

For that record to be defensible, the mission has to carry more than a goal and some objects. It binds to the requester and the user it acts for, the approving authority, the resource context it was scoped against, the policy and derivation versions it was built under, and an expiry. Without those it is a blob of intent, not an authorization artifact anyone could stand behind in a review.

And when the task needs more than the mission anticipated, say the dispute hinges on a related order in another system, the answer is not a standing grant broad enough to have covered it. It is a governed expansion: a successor mission carrying the wider authority, the prior one completed, its record and lineage kept for audit. Scope tracks the task, not the org chart, and it moves by minting a new bounded mission, never by loosening an old one.

Intent Becomes the Unit of Authorization

Step back and the shift underneath this is bigger than one billing agent. Mainstream enterprise authorization, the role-based kind most companies actually run, ties what you may do to who you are: a role provisioned ahead of time that holds as long as you hold the job. Richer models exist, attribute-based, capability, and contextual policy all predate agents, but the static role is the dominant pattern, and it works when identities map to stable jobs.

Agents do not hold jobs. They take tasks. The same agent, under the same identity, resolves a billing dispute at ten o’clock and drafts a board summary at eleven, and the two tasks have almost nothing in common in what they should be allowed to touch. Give that model a single static role for “the agent” and it has to be the union of everything any task might ever need, broad enough that it is no longer least privilege for any one of them.

Identity still matters, for a narrower job: it establishes who is acting and for whom. The ceiling, the most the agent could ever touch, comes from what that identity is entitled to, plus client registration, delegation, and tenant and resource policy. A grant can never exceed it. But a ceiling is not a scope: it says what is possible, not what is needed now.

What is needed now is a different question, “what are you trying to do,” answered one task at a time, because the task is the only place the answer lives. A session is not a mission: a login that lasts all day is the wrong container for an intent that lasts twenty minutes and wants three specific things. So the mission does not replace identity; it narrows within it. The grant is the intersection: bounded above by that ceiling, bounded to the task by the mission, which adds what conventional deployments usually lack: a durable, approved, machine-readable statement of what this task is for, narrow enough to bound the work and fresh enough to fit it.

Mission Objects Are the Authorization Counterparts to Evals

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 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:

Evaluation Approved Mission
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

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 composes semantic assessments as additional restrictions, while runtime alignment governs whether work should continue.

The Hard Part Is the Same Hard Part

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:

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 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:

flowchart TB Goal([User goal]) --> Shape[Mission shaping] 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 -->|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

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.

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.

Version preserved before this revision · Exact diff · Revision source · Source hashes and provenance.

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.