This is the test of the publication’s fast path: the reusable evaluation tool. The essay makes the category case, the blueprint is the build order, and the Field Reference carries the definitions behind every question.
Agent auth today can prove who is acting and what credential they hold. It cannot prove the work is still authorized. So when a vendor says they support agent authorization, the evaluation is six questions. Each probes one property of the six-property litmus, and each has a recognizable failing answer.
The count is deliberate. The five laws are the invariants of delegated authority. These six questions are the vendor-verifiable surfaces that prove those invariants are actually implemented.
Use this as a hard gate, not a maturity survey. If question 1 does not produce an approved task object, the claim is not mission-based authorization. If question 4 is only token validation, there is no runtime-enforcement claim. If question 5 is token expiry, there is no revocation claim.
| # | Ask | What it probes | A failing answer sounds like |
|---|---|---|---|
| 1 | What is the approved task object, and where is it stored? | An approved task object | “The prompt”, “the session”, “the trace ID” |
| 2 | What derives the agent’s authority from that object? | Authority derived from the task | “Admins assign scopes at integration time” |
| 3 | How are tokens and decisions bound back to it? | Tokens and decisions bound to the task | “Tokens carry the user and client. Tasks live in our app layer” |
| 4 | What checks each consequential action against it at the moment of use? | Per-action runtime enforcement | “The token is validated on every call” |
| 5 | What happens, and how fast, when the task is revoked? | Observable lifecycle state | “Tokens expire within an hour” |
| 6 | Can an auditor pull one identifier and see the whole task? | Evidence joins on the task’s identity | “We have comprehensive logs” |
Notice what every failing answer has in common. Each one names a credential artifact, a runtime artifact, or a log where the question asked for a governed task object. That substitution is the whole category error, and hearing it is the point of the test.
The test is conjunctive. Five of six is not a partial pass. It is a different product wearing the category’s name, and the missing property tells you which one: no task object is a policy engine, no runtime enforcement is a governance dashboard, no revocation reach is a token issuer with labels.
A passing answer has a different sound:
| Property | A passing answer says |
|---|---|
| Approved task object | There is a durable Mission record with an identifier, issuer, approved purpose, actor binding, authority, constraints, lifecycle state, and evidence links |
| Derived authority | The agent’s usable authority is computed from the Mission, not only from an integration-time role, scope, or admin setting |
| Binding | Tokens and decisions carry a mission identifier and integrity signal that a verifier can join back to current Mission state |
| Runtime enforcement | A PEP checks each consequential action against action, parameters, actor, and current Mission state before the effect happens |
| Revocation | Revoking or expiring the Mission reaches enforcement within a named freshness bound and fails closed when freshness cannot be established |
| Evidence | An auditor can start with one Mission identifier and reconstruct approvals, derived authority, decisions, denials, lifecycle changes, and the consequential actions taken under it |
The bar is deliberately ordinary. These are the questions any finance team could answer about a corporate card program without preparation: the approved purpose, who derived the limits, what authorizes each swipe, what the freeze reaches, and what the statement joins. The corporate-card test is this same instrument in card language, and if the answers would be unacceptable for a card program, they are unacceptable for an agent that moves faster and can be talked into things by the documents it reads.
A vendor that passes all six should be able to write the honest deployment claim: the tier, the enforcement scope, the freshness bound, the evidence, and the exclusions, in writing. Two follow-ups keep the pass honest. A mission-bound token without runtime enforcement is governance metadata, not agent safety, so question 4 is the one a claim most often fails in practice. And the what-not-to-claim list names the five overclaims to listen for on the way out.
For an RFP or architecture review, the reusable clause is simple: describe the approved task object; identify where it is stored; show how authority, tokens, decisions, enforcement, revocation, and evidence join to it; name the enforcement scope and freshness bound; and list every path where the claim does not apply.
For the depth behind each question: the litmus test expands the six properties and names near misses, the implementation checklist is how you verify a claimed pass, and the competitive landscape covers the alternatives a failing answer is usually reaching for, row by row, with the law each one breaks.