Overview
This part is the chapter’s second proof, and the one framing built for identity rather than threats. Patrick Parker published The Laws of AIdentity in May 2026 as a proposed framework for delegated agent action. The laws are not presented as an exhaustive checklist. Each names a dynamic whose violation produces a recognizable failure: confused agency, authorized-but-unintended action, authority laundering, time-of-check/time-of-use drift, cascade exfiltration, action-chain poisoning, or auditability collapse.
That makes the laws a useful test for this handbook. Mission-Bound Authorization starts from the five laws of delegated authority and asks how an approved task can govern authority across credentials, actions, actors, and time. Parker starts from the agent identity fabric and asks what a system must preserve when intent, authority, custody, execution, downstream identity, and proof no longer belong to one actor. The decompositions differ, but they meet around the same control problem.
The overlap is evidence of a real architectural seam. It is not proof that this draft family is the only answer, that the two frameworks were developed independently, or that every conforming Mission deployment satisfies all seven laws. Parker repeatedly describes systems that begin to satisfy a law. The handbook likewise has assurance levels: Baseline Issuance does not make an action-time safety claim, while Runtime-Enforced, Governed Agent, and High-Assurance Agent add progressively stronger controls.
This crosswalk therefore asks three questions for each law:
- Is the requirement represented directly in the Mission model?
- Does satisfying it require a runtime control, identity substrate, optional profile, or higher assurance level?
- What part remains a deployment responsibility or an explicit non-goal?
How to read the crosswalk
The coverage labels are deliberately narrower than “answered.”
- Direct means the requirement is native to the Mission object or issuance core.
- Composed means the answer exists only when Mission-Bound Authorization is combined with its identity, runtime, or evidence profiles.
- Partial means the architecture covers part of the law but leaves a material requirement unstandardized or out of scope.
That distinction matters because the core and the full reference security architecture make different claims. A mission claim on a token is governance metadata and a derivation gate. It becomes action-time control only when a PEP checks each consequential action against current Mission state.
The crosswalk
| Parker’s law | What it requires | Mission-Bound Authorization mapping | Coverage and caveat |
|---|---|---|---|
| 1. The Split Actor | Preserve the principal, delegate, generator, authorizer, approver, credential holder, executor, and downstream identity as distinct roles | The Mission record separates subject and approver; the Actor and instance profiles identify the acting instance and delegation chain; Decision and Execution Evidence separate the PDP’s decision from the PEP’s action; mediated custody separates the agent from the key holder | Composed. Strong when the identity and runtime profiles are deployed. The issuance core alone does not record every role or the identity observed downstream |
| 2. Generated Intent | Evaluate the concrete action that an agent generates after broader authority has been granted | The Authorization Server derives an approved Authority Set from the Mission Intent; runtime enforcement then checks each consequential action, its parameters, actor, audience, and current Mission state before execution | Composed, strong at Runtime-Enforced. Baseline Issuance does not satisfy the action-time requirement |
| 3. Bounded Agency | Express purpose, resources, constraints, duration, budget, approval rules, and revocation; narrow authority through delegation | The Mission carries goal, purpose, resources, constraints, and expires_at; derivation is subset-only; lifecycle controls terminate authority; Child Missions narrow durable sub-work | Direct for most bounds. Cumulative budget enforcement depends on the experimental Consumption Metering profile |
| 4. Continuous Authorization | Govern discovery, invocation, execution, and outcome rather than authorizing only entry | The discovery loop turns newly encountered authority into a denial or governed expansion; the runtime gate checks invocation against fresh Mission state; PEP placement and mediated custody constrain execution; Execution Evidence records the result | Composed and scope-dependent. Outcome is recorded, not “authorized,” and the guarantee reaches only the execution paths named in the deployment’s enforcement-scope statement |
| 5. Least Exposure | Minimize the data, context, tools, schemas, and credentials an agent can see or hold | Narrow, short-lived credentials reduce authority exposure; filtered discovery limits visible tools; mediated custody keeps usable credential keys inside a governed PEP; the handbook’s least-exposure discipline scopes context to purpose | Partial. Mediated custody is High-Assurance. Retrieval, memory, and context scoping remain design guidance without a common wire format |
| 6. Justifiable Action Chains | Prove the identity, provenance, integrity, and necessity of every participant in the action path | Actor chains and instance attestation establish who participated; source digests and capability_drift detect changed capabilities; strict-subset Child Missions preserve authority lineage; model and deployment provenance can be policy inputs | Partial. The handbook can prove that a participant was identified, authorized, and unchanged. It does not decide that the participant was necessary, and it has no physical actuator or sensor profile |
| 7. Proof-Carrying Action | Produce signed evidence that binds authority, decision, delegation, execution, outcome, and tamper detection | Consent, Decision, and Execution Evidence join on the Mission and its integrity anchors; optional SCITT registration commits evidence digests to a verifiable transparency service | Composed, with limits. policy_version is a reference, not a policy snapshot. Transparency proves registration and integrity of registered records, not their truth or the completeness of the set |
The table shows substantial convergence, but not seven identical answers: one law maps directly to the core model, four require composed identity, runtime, or evidence profiles, and two retain explicit semantic or coverage gaps. That result is more useful than a perfect score because it tells an implementer what must actually be deployed.
What the convergence demonstrates
The laws divide one apparently simple question into four system responsibilities:
| Question | Primary responsibility |
|---|---|
| Who acted, and for whom? | Agent identity, instance identity, and actor-chain profiles |
| Why did this authority exist, and what bounded it? | The Mission, approval record, Authority Set, and lifecycle |
| May this concrete action occur now? | The PEP/PDP runtime control loop and resource policy |
| What decision and outcome can later be proved? | Signed evidence, retention, reconciliation, and optional transparency |
No authentication mechanism can answer all four, but that observation should not be turned into a strawman about identity. Parker defines AIdentity broadly as a system of systems that composes identity, delegation, policy, credentials, action surfaces, human ceremonies, and proof. The better conclusion is narrower: agent identity needs an action-governance layer, and Mission-Bound Authorization supplies a concrete candidate for its authority object and runtime contract.
The mapping also tests the handbook’s internal decomposition. The Mission object answers Bounded Agency but not Generated Intent by itself. Runtime enforcement answers action time but not chain attribution by itself. The identity profiles answer who acted but not why the work remained authorized. Evidence proves what a producer recorded but grants no authority. The layers compose because their responsibilities do not collapse into one another.
Three mappings worth a closer look
Generated intent is the deepest agreement. Parker’s second law identifies the category change: the concrete action may not exist when broader authority is granted. The handbook responds at two different moments. At admission, an accountable Approver decides on a structured Mission Intent and the Authority Set derived from it. At execution, a PEP asks a PDP whether the generated action and parameters fit that committed boundary under current state. The first check prevents the agent from inventing its own authority; the second prevents an approved Mission from becoming ambient permission for every action inside a token lifetime.
This is why the architecture cannot stop at a well-shaped prompt or a mission-bound token. Shaping proposes. Approval establishes the ceiling. Runtime enforcement decides whether a concrete draw against that ceiling is permitted now.
Least exposure is broader than credential safety. Parker includes prompt context, retrieved material, tools, schemas, secrets, and downstream responses in the exposure surface. The handbook reaches that same conclusion: what an agent can observe shapes what it can decide, even when access policy would later deny an action. Its strongest wire-level control is mediated custody. For a mediated class, the PEP, not the agent, holds the sender-constraint key and releases a governed outcome rather than a reusable credential.
But the match has a boundary. The runtime profile can enforce filtered discovery and mediated egress on paths it controls. The broader discipline of purpose-scoped retrieval, memory, and context assembly is not yet an interoperable protocol. Calling Law 5 fully answered would hide exactly the standardization gap the handbook’s own least-exposure chapter names.
Proof-carrying action requires several kinds of proof. Decision Evidence records what the PDP evaluated and whether it permitted or denied the action. Execution Evidence is a separate PEP-produced record of whether a permitted action was attempted, completed, failed, or suppressed. The separation prevents a permit from being misread as proof that an action occurred. Both bind back to the Mission, and the integrity anchors commit the approved intent and authority.
Optional SCITT registration adds a different property. It commits a digest of a retained evidence record and produces a receipt that a verifier can check offline. It does not make a false record true, prove that every expected record was registered, or remove the need to retain the evidence and the policy material needed to interpret it. The receipt model is therefore strong, but its claims must stay precise: attributable records, verifiable inclusion, tamper detection, and deterministic joins, not omniscient audit.
Where the crosswalk sharpens
Authorize the action against what? Law 2 requires action-time authorization. The handbook adds that the comparison target must be an approved, committed boundary rather than a fresh inference about what the user probably meant. Runtime context is attacker-influenceable. Semantic alignment can inform a decision, but it cannot widen authority. The enforceable comparison is the Authority Set an accountable Approver accepted, under the policy and current state that apply at execution.
Separate the actor from the behavioral version. Parker’s Split Actor law distinguishes roles in an action chain. The handbook adds a different axis: the Agent Deployment, the versioned bundle of code, model, system prompt, tool allowlist, data scope, and runtime configuration. Instance identity answers which running actor. Deployment identity answers which reviewed behavior was running. Where a Mission uses the optional controls.agent_deployment pin, a replacement model or prompt is not silently treated as the same approved actor class.
That is not an eighth actor. It is a change-governance object with its own lifecycle and kill switch, kept separate from both agent identity and the Mission.
Where the handbook delegates or declines
An honest crosswalk ends with the parts it does not solve.
- Necessity remains a judgment. The architecture can verify that a sub-agent or tool was identified, authorized, within a strict subset, and unchanged from an approved digest. It does not decide whether invoking that participant was necessary. That remains an orchestration, design-review, or policy question.
- Exposure control is incomplete. Credential custody, tool filtering, egress mediation, and the harness taint rule have enforceable surfaces. Purpose-scoped retrieval, memory, and context assembly do not yet have a common wire representation.
- Model provenance is not model trustworthiness. Attested model or deployment identifiers can be verified policy inputs. They do not prove that the model is safe, truthful, or suitable. The authorization layer deliberately bounds behavior instead of certifying the actor’s judgment.
- Policy references require retention.
policy_versionidentifies the derivation policy in force; it does not embed or hash the policy content and is not a promise that the decision can be reproduced later. A deployment that needs Parker’s policy-snapshot property must retain the referenced policy, dependencies, and evaluation inputs. - Evidence completeness is not automatic. Signatures protect individual records. SCITT can prove inclusion and ordering for records that were registered. Completeness requires an expected registration schedule, reconciliation rules, and, if equivocation is in the threat model, trust in one transparency service or registration with multiple independent services.
- Embodied action is outside the current profiles. Parker explicitly extends the laws to sensors, controllers, actuators, vehicles, and other cyber-physical systems. Mission-Bound Authorization can carry their authority vocabulary, but it does not yet define the safety-envelope, telemetry, or actuator bindings needed to claim coverage.
The literal answer to Parker’s closing question is therefore a composition, not one token. Who acted? The subject, client or attested instance, actor chain, and runtime evidence identify the relevant roles. Under whose authority? The mission claim names the Mission Issuer and commits the approved Authority Set by hash; the Mission record carries the Approver and lifecycle. Through what chain? The act chain preserves actor lineage while Mission parentage preserves authority lineage, so delegation does not blur the two. With what proof? Signed Consent, Decision, and Execution Evidence join on the Mission and its hashes, with optional transparency receipts strengthening the retained record set.
That is a substantive answer to the authorization-heavy core of the Seven Laws. The crosswalk’s strongest conclusion is not that one draft family has finished AIdentity. It is that Parker’s framework and this handbook, starting from different questions, decompose agent governance into identity, bounded authority, action-time enforcement, custody, and proof. Any deployable system will need those responsibilities to compose without pretending they are the same thing.