---
title: "The Mission-Based Authorization Vendor Test"
date: "2026-07-22T09:40:00-07:00"
lastmod: "2026-07-22T09:40:00-07:00"
description: "The public evaluation tool for agent authorization claims: six questions that separate mission-based authorization from scopes, sessions, task IDs, token validation, and logs. Built for architecture reviews, vendor calls, and RFPs."
summary: "When a vendor says they support agent authorization, ask six questions: what is the approved task object, what derives authority from it, what keeps authority strictly narrower as work fans out, what checks each action at the moment of use, what happens when it is revoked, and can an auditor pull one identifier and see the whole task. The test is intentionally unforgiving: no approved task object means no category claim, token validation is not runtime enforcement, token expiry is not revocation, and logs are not task evidence. A vendor that passes can write the honest deployment claim with level, enforcement scope, freshness, evidence, and exclusions."
slug: "mission-based-authorization-vendor-test"
tags:
  - "Agentic Identity"
  - "Authorization"
  - "Mission-Bound Authorization"
  - "IAM"
  - "Security Architecture"
---


> This is the [handbook's](/mission-handbook/) evaluation tool, its
> Appendix D: built to be linked, pasted into an RFP, and asked in a
> vendor call. The
> [blueprint](/notes/adopting-mission-bound-authorization/#walk-the-runtime-enforced-level) is
> the build order, and the
> [Field Reference](/notes/mission-based-authorization-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](/notes/mission-based-authorization-field-reference/#what-counts-the-litmus-test),
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](/series/what-the-corporate-card-already-solved/#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](/notes/mission-based-authorization-field-reference/#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](/notes/mission-based-authorization-field-reference/#what-not-to-claim)
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](/notes/mission-based-authorization-field-reference/#what-counts-the-litmus-test)
expands the six properties and names near misses, the
[implementation checklist](/notes/mission-based-authorization-field-reference/#the-implementation-checklist)
is how you verify a claimed pass, and the
[competitive landscape](/notes/mission-based-authorization-field-reference/#competitive-landscape)
covers the alternatives a failing answer is usually reaching
for, row by row, with the law each one breaks.