This is the handbook’s evaluation tool, its Appendix D: built to be linked, pasted into an RFP, and asked in a vendor call. 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 3 is a shared parent token, there is no delegation claim. 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 | When the agent fans out or delegates, what guarantees the child’s authority is strictly narrower? | Narrow-only delegation | “Sub-agents reuse the parent’s token” |
| 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. One failing answer has an acceptable floor form: token expiry alone fails, but state-gated issuance against a live task record with a published staleness bound is the category’s own coarse end, the Baseline level honestly claimed. The differentiator is the state gate and the record, never the lifetime.
The test is conjunctive for the action-time defense claim, and it splits where the family’s own conformance splits. Questions 1, 2, 3, and 5 are the substrate bar: fail one and the product is not mission-based at all, just a different product wearing the category’s name. Questions 4 and 6 are what the defense claim adds: pass the substrate four without them and the honest claim is Baseline Issuance, governance rather than defense. Either way the missing property tells you what you are looking at: no task object is a policy engine, no runtime enforcement is a governance dashboard, no revocation reach is a token issuer with labels, and no narrowing is a shared service account with extra steps.
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 |
| Narrowing | Delegated and derived authority is computed as a strict subset of the parent’s: a child task, sub-agent, or downstream token only narrows, and widening requires a fresh approval |
| 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, joined by the mission identifier and integrity signal every token and decision carries |
And ask for the demonstration, because it is the cleanest proof that the Mission is enforced rather than decorative:
Show me one denied action where the token was valid but the Mission’s state, bounds, parameters, or delegation chain made the action impermissible.
A system that cannot produce a valid-token denial is validating credentials, not enforcing a task.
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 level, 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 six 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.