---
title: "AgentPass and the Missing Mission Layer"
date: "2026-03-24T09:00:00-07:00"
lastmod: "2026-03-24T09:00:00-07:00"
description: "AgentPass is a concrete, well-structured proposal for governed agent delegation. It gets the Authority shape right. What it leaves open is the harder problem: turning natural-language task descriptions into bounded authority, and governing that authority across multi-step, multi-agent execution."
summary: "AgentPass introduces an Authority as a separate governance entity that approves and scopes agent access before credentials are issued. The architecture converges with Mission-Bound OAuth in important ways. But the Task description problem, the scope compilation gap, and the thin lifecycle model are precisely where the Mission and Mission Shaping work picks up."
tags:
  - "Agentic Identity"
  - "Delegated Authority"
  - "IAM"
  - "OAuth"
  - "Authorization"
  - "Security Architecture"
---


[AgentPass](https://agentpass.com/spec) is a new open specification for governed delegation of authority from users to software agents. It is worth mapping carefully against the Mission architecture work on this site, because the two bodies of work converge on several key ideas and diverge in ways that clarify exactly what each is trying to solve.

The short version: AgentPass is converging on the right infrastructure layer. It gets the Authority shape mostly right, it introduces task-level delegation, and it moves beyond token-expiry-only revocation toward active delegation checks. What it does not address is the harder problem underneath all of that: how a natural-language task description becomes bounded, machine-evaluable authority, and how that authority is governed across the full lifecycle of a multi-step execution.

That is exactly where the [Mission Shaping series](/series/mission-shaping/) and [Mission-Bound OAuth series](/series/mission-bound-oauth/) begin.

# What AgentPass Proposes

AgentPass defines three parties. A **Harness** is the execution environment: the agent, coding assistant, or automation that wants to act on a user's behalf. A **Service** is the application the agent needs to access. An **Authority** is the governance entity that approves the delegation and issues credentials.

The core flow is:

1. The Harness requests a delegated credential from the Authority, specifying a Task (a natural-language description plus a scope list) and the User on whose behalf it is acting.
2. The Authority may require approval from the User, a manager, or an automated policy system.
3. The Authority issues an AgentPass: an opaque, short-lived, single-use credential.
4. The Harness presents the AgentPass to the Service, which validates it against the Authority and receives the approved scope and an `authorization_id`.
5. The Service enforces the intersection of the requested scope and the Authority-approved scope.
6. During execution, the Service may poll the Authority with the `authorization_id` to check whether the delegation is still valid.

The spec supports three Authority trust modes: enterprise (domain-based, like enterprise SSO), federated (explicit trust relationships, like "Sign in with Google"), and service (operator-controlled, like email-verified self-service). Enterprise Authorities take precedence, which gives organizations policy control over which agents can act within their domain.

This is a serious, concrete proposal. The spec is clear about its current status: version 0.1 draft, not security-audited, not for production. That is an honest place to start.

# Where AgentPass and Mission-Bound OAuth Converge

The convergence between AgentPass and the Mission architecture is not superficial. Several core structural ideas are recognizably aligned, even if AgentPass stops short of the fuller Mission model developed elsewhere on this site.

## The Authority is the Mission Authority Service

AgentPass's Authority occupies roughly the same architectural position that [Mission-Bound OAuth Part 4](/notes/why-mission-bound-oauth-might-be-the-wrong-answer/) calls the Mission Authority Service (MAS).

Part 4's central argument is that Mission governance should not live inside the OAuth Authorization Server. The better architecture is a dedicated Mission Authority Service that owns durable authority state, approves delegations, and lets OAuth Authorization Servers and other enforcement points consume Mission state rather than owning it. AgentPass makes a structurally similar choice: the Authority is not the Service's own OAuth AS, it is a separate governance entity with its own issuance and validation endpoints.

The terminology differs, the protocols differ, and AgentPass's scope is currently narrower. But the architectural instinct is the same, and it is the right one.

## Continuous Authorization is Mission State Checking

AgentPass requires Services to perform periodic authorization checks via the `authorization_id` during an active delegation. If the Authority has revoked the delegation, the check returns a 404 and the Service must stop the session.

This is a concrete, albeit polling-based, implementation of one important part of what the [Power of Attorney series](/series/you-dont-give-agents-credentials-you-grant-them-power-of-attorney/) calls continuous authority evaluation: the question is not only "was this request permitted when the token was issued?" but "should this execution still be running now?"

Mission-Bound OAuth and the Mission Shaping work propose event-driven propagation via CAEP and Shared Signals rather than polling, which avoids the TTL-based window where a revoked delegation can still appear valid. That said, CAEP's existing event type vocabulary covers session and credential events; Mission lifecycle transitions such as suspension, forced termination, and scope change are not yet defined event types in the Shared Signals Framework. The upgrade from AgentPass polling to event-driven propagation requires standards work to define those event types, not just implementation work. AgentPass's `authorization_id` pattern is the right starting point, and polling is a reasonable baseline while that standards work matures.

## Holder Binding and Task Attestation

AgentPass optionally supports holder binding: the Harness generates an ephemeral key pair at request time and the AgentPass is cryptographically bound to that key, so only the Harness that requested it can redeem it. It also supports task attestation, which creates a non-repudiable record binding a specific Harness vendor and version to the task it claims to perform.

Both of these map to work on this site. Holder binding is the AgentPass equivalent of the `cnf`-based sender-constraining covered in the [act claim standardization post](/notes/standardize-act-claim-across-assertion-grants-and-jwt-access-tokens/): credentials bound to the key of the current presenter rather than bearer tokens that any party can present. Task attestation is the AgentPass equivalent of approval evidence in the Mission record: a verifiable, non-repudiable link between the claiming Harness identity and the task it said it would perform. Neither solves the compilation problem discussed below, but both are meaningful security properties that address credential theft and post-hoc repudiation.

## Protocol Agnosticism

AgentPass's Authority is not an OAuth Authorization Server. It defines its own issuance, validation, and authorization-check endpoints. The Harness-to-Service protocol does not depend on OAuth at all; Services validate AgentPass credentials by calling the Authority's endpoints directly.

This is architecturally more significant than it first appears. [Mission-Bound OAuth Part 4](/notes/why-mission-bound-oauth-might-be-the-wrong-answer/) concludes that the Mission Authority Service should survive protocol changes: if OAuth remains dominant, the MAS is the AS's upstream authority source; if AAuth or a successor becomes better suited, the MAS survives and the transport layer changes underneath it. AgentPass's Authority is precisely this kind of protocol-agnostic governance entity. It can sit above OAuth, above AAuth, or above any other credential transport. That is the right long-term architecture, and it is more aligned with the Mission model than an Authority that was simply another OAuth AS.

## Task-Level Delegation over Ambient Credential Possession

AgentPass issues credentials per task. The AgentPass credential itself is opaque, short-lived, and single-use: it is consumed when the Harness redeems it for a bearer token or browser session, and cannot be reused. The resulting bearer token persists for the task's duration across many API calls, but the delegation is anchored to the task that justified it. The Harness cannot accumulate an AgentPass from one task and present it to authorize a different one.

This is a meaningful improvement over ambient credential possession, but it only constrains one part of what the Power of Attorney series calls ghost execution: agents continuing to operate with valid credentials past the point where the purpose that justified those credentials has ended. Task-level issuance ties the initial delegation to a named task. It does not, by itself, define the lifecycle semantics of that task, govern stage transitions inside it, or prevent long-running bearer-token use from drifting past the point where the underlying Mission should have ended. That is why task-level delegation is directionally right but not sufficient on its own.

# The Task Description Problem

Here is where the two bodies of work diverge, and where the Mission Shaping work is most directly relevant.

AgentPass's Task object contains two fields: a Harness-assigned task ID and a natural-language description. The scope is a separate field: an array of permission strings, such as `["tickets:read", "tickets:write"]`, or the special value `"*"`, meaning all scopes the user has access to.

The specification does not address how the natural-language description relates to the scope array. That mapping is the Harness's responsibility. The Authority receives both and makes an approval decision, but the spec does not define how Authorities should evaluate whether the scope array faithfully represents the described task, or how Harnesses should derive a scope array from a task description in the first place.

This is the Mission shaping problem in concrete form.

[Mission Shaping Part 1](/notes/the-mission-shaping-problem/) makes the core argument: a human approves an objective, not the authority needed to execute it. The system still has to turn that approval into something a control plane can evaluate. That compilation step, from natural-language intent to a bounded, machine-evaluable authority representation, is not specified anywhere in AgentPass. It is left to the Harness and the Authority implementation.

In the newer vocabulary used across this site, the missing piece is not just better scope derivation. It is the boundary between a proposed task description, an approved Mission, and a machine-evaluable authority model derived from that approval. AgentPass defines the request and approval surface. It does not yet define that intermediate authority object with enough precision for interoperable governance.

The consequences are predictable.

A Harness that requests broad scope because it cannot reliably compute minimum-authority scope falls back to `"*"`. The spec explicitly allows this. That is exactly the over-scoping failure that Mission Shaping argues is the core governance problem. An agent with `"*"` scope and a natural-language task description has no meaningful authority boundary. The "approved" delegation in that case is an approval of the user's existence, not of the specific task.

A Harness that requests too narrow a scope will generate authorization failures mid-execution, which creates pressure to broaden scope requests or pre-request scope expansions. This is the same template accumulation failure described in Mission Shaping Part 2: over time, scope requests grow until the template covers everything the agent might plausibly need.

An Authority that cannot evaluate whether the requested scope faithfully represents the described task cannot meaningfully govern the delegation. It can confirm that the scope strings are syntactically valid and that the user has access to them. It cannot evaluate whether `["calendar:write", "email:send"]` represents a faithful compilation of "schedule a meeting with the engineering team."

The problem is sharpest in the headless case. AgentPass states that approval may be granted by an automated policy system rather than a user. When the approver is automated, the evaluation question becomes fully mechanical: the policy system must determine whether the requested scope array faithfully represents the described task without any human in the loop. [Mission Shaping Part 2](/notes/mission-shaping-is-not-enough/) covers this directly: headless governance requires machine-verifiable shaping rules and machine-verifiable provenance for the authority source being shaped. Neither is specified in AgentPass, which means automated approvers in a v0.1 deployment are likely applying coarse policy (is this scope in the user's entitlements?) rather than semantic evaluation (does this scope faithfully represent this task?).

None of this is a criticism of AgentPass's architecture. It is a description of where AgentPass stops and where Mission shaping begins. AgentPass correctly identifies the need for an Authority that evaluates delegation requests. It does not specify what evaluation means when the delegation is expressed as a natural-language task description.

# The Credential Is Not the Mission

AgentPass's credential model is: opaque, short-lived, single-use AgentPass redeemed for either a browser session or a bearer token. The bearer token is what the Harness actually uses to call the Service's APIs.

This is a clean, practical design for the credential transport problem. It is also the right place to ask the Mission question: where does the durable authority object live?

The [Mission-Bound OAuth series](/series/mission-bound-oauth/) makes the argument that a token is a projection artifact. Tokens exist to carry bounded information across a protocol boundary. The Mission, the durable authority record that says who approved what for whom and for what purpose, must exist above and outside the token.

In AgentPass's current model:

- The AgentPass credential is the token projection. It carries the delegated authority across the Harness-to-Service boundary.
- The `authorization_id` is the closest thing to a durable authority reference. Services use it to check Mission state across the bearer token's lifetime.
- The Authority holds whatever state backs the `authorization_id`. The spec does not define what that state looks like internally.

The `authorization_id` is therefore the closest thing to a Mission reference in AgentPass's architecture, and the Authority's backing state for it is the closest thing to a Mission state record. The spec's current silence on what that state contains is the gap. In the newer vocabulary used on this site, a fuller AgentPass-compatible model would need both:

- an **approved Mission** as the durable governance record of what was granted, by whom, for what task, and under what lifecycle
- a **Mission Authority Model** as the machine-evaluable derivative that Services, gateways, and policy systems can actually enforce

At minimum, that combined model would hold:

- the approved task description and its compilation into a bounded authority model
- the full lifecycle state machine (pending approval, active, suspended, revoked, expired)
- the delegation graph if sub-agents are involved
- the approval evidence chain
- the provenance of scope decisions

Without specifying that object, AgentPass Authorities can range from a simple boolean "revoked or not" flag to a full Mission governance record. Two AgentPass Authorities can both be spec-compliant and have radically different governance quality. That is exactly why this is the next place the spec needs to evolve.

# The Lifecycle Model Is Thin for Multi-Step Execution

AgentPass's lifecycle model is: issue, redeem, check, revoke. That covers the credential lifecycle correctly. It is not the full Mission lifecycle that long-running, multi-step agent execution requires.

Mission Shaping Part 2 identifies the failure modes that a thin lifecycle model cannot address:

**Quiet scope expansion.** An agent mid-execution concludes that a resource outside its approved scope is obviously necessary and accesses it through an unmediated path. The `authorization_id` check does not detect this because the agent is not asking for new scope, it is silently expanding its effective authority. Detecting this requires a Mission authority model that can be queried at each tool boundary, not just at the credential presentation boundary.

**Staged execution and scope transitions.** A task that starts with read-only discovery and moves to write-capable execution has different authority requirements at each stage. AgentPass issues one scope at delegation time. If the scope covers both phases, the read-only phase operates with unnecessarily broad authority. If the scope covers only one phase, the transition requires a new delegation request. The Mission model handles this through staged authority: the Mission state machine tracks which phase is active and gates the authority accordingly.

**Multi-agent delegation.** AgentPass's Harness is the agent. The spec does not address the case where the Harness spawns sub-agents. A parent agent that receives an AgentPass and delegates part of that task to a child agent has no mechanism in the current spec to issue the child an attenuated credential derived from the parent delegation. The Mission model requires that child authority be a proper subset of the parent, and that the attenuation be explicit and governed, not implicit through access control inheritance. The OAuth building blocks for this exist: RFC 8693 Token Exchange and the `act` claim provide the delegation chain semantics, and the [act claim standardization work](/notes/standardize-act-claim-across-assertion-grants-and-jwt-access-tokens/) covers the interoperability gap. AgentPass needs an equivalent model grounded in its own Authority-based architecture.

**Spontaneous delegation.** When an orchestrating agent spawns a sub-agent at runtime as an autonomous decision, not as a pre-specified workflow step, who triggers the Authority issuance for the child? AgentPass's issuance flow assumes the Harness initiates the request. A spontaneous runtime spawn has no natural initiator in the current protocol shape.

These are not hypothetical edge cases. They are the standard operating conditions of open-world agent execution, which is the environment AgentPass targets.

# What AgentPass Needs to Complete the Picture

The architectural gap between AgentPass v0.1 and a fuller Mission governance model is not primarily protocol mechanics. The protocols are tractable. The gap is in three areas.

**A specification for the Authority's Mission state.** The `authorization_id` is a reference to something. The spec should define what that something is, at least at a minimum viable level. In Mission terms, that means both a durable approved-Mission record and a defined machine-evaluable authority model derived from it. Without both, Authorities may record approval history but lack an enforceable authority object, or enforce coarse scope but lack a durable governance record. A minimum viable AgentPass model should define both surfaces.

**A Task compilation model.** AgentPass should specify how the relationship between a natural-language task description and a scope array should be established. It does not need to solve the full Mission shaping problem. But it does need to say something about what makes a scope array a faithful representation of the described task, and what Authorities should do when the relationship is unclear or suspect. Even a requirement that Authorities surface the compilation basis as part of the approval record would be a meaningful step.

**A sub-agent delegation model.** When a Harness spawns sub-agents, the child delegations should be derivable from the parent AgentPass with guaranteed attenuation. The parent's `authorization_id` should anchor the child delegation chain. This is a direct extension of the existing per-task credential model.

None of these require replacing AgentPass's architecture. They extend it in the direction the Mission work has already mapped.

# The Map

The relationship between AgentPass and the Mission architecture can be stated as an approximate translation between layers:

| AgentPass | Mission architecture |
|---|---|
| Task (natural language + scope array) | Closest analogue to Mission input or proposal surface |
| Authority | Mission Authority Service |
| AgentPass credential | Token projection carrying a reduced Mission view |
| `authorization_id` | Closest analogue to a Mission reference: the durable authority handle |
| Authority's backing state | Closest analogue to Mission state, but underspecified in the current draft |
| Continuous authorization check | Narrow Mission-state check focused on revocation/validity |
| Scope intersection enforcement | Partial analogue to Mission Authority Model enforcement, without a defined machine-evaluable Mission model |
| Holder binding | Sender-constraining via `cnf` / DPoP |
| Task attestation | Approval evidence in the Mission record |
| `"*"` scope | Minimum authority failure: approved intent without bounded authority |
| No sub-agent delegation model | Multi-agent delegation and trust attenuation |

The two rows where the mapping is cleanest today are Authority and `authorization_id`: both architectures agree that a separate governance entity should own durable authority state and expose it through a stable reference. The rows where the gap is sharpest are the Task, the Authority's backing state, and scope enforcement: AgentPass defines the shape of those concepts but not their internal semantics, which is where the distinction between approved Mission and Mission Authority Model becomes essential.

AgentPass is building from the credential and protocol layer upward. The Mission work builds from the governance and authority object layer downward. They meet at the Authority.

# Where to Engage

The [Mission Shaping series](/series/mission-shaping/) covers the Task compilation problem directly: why approved intent is not authority, and what the governance record must contain before bounded execution can begin.

The [Mission-Bound OAuth series](/series/mission-bound-oauth/) covers the protocol projection problem: how a durable authority object survives token issuance, exchange, and delegation across trust boundaries, and what the honest critique of any specific protocol choice looks like.

The [Mission control-plane post](/notes/where-mission-lives-in-the-iam-stack/) addresses where the Authority's Mission record fits in the IAM stack: not inside the OAuth AS, not inside the orchestrator, but as a separate control-plane object that the credential layer, policy layer, and audit layer all compose around.

AgentPass has built a credible foundation and is moving in the right architectural direction. The next version of this spec will be more interesting, and materially stronger, when the Authority is defined not just by what it issues but by what it knows about the Mission it is governing.