---
title: "Answering the Laws of AIdentity"
date: "2026-07-22T07:20:00-07:00"
lastmod: "2026-07-22T07:20:00-07:00"
description: "A critical crosswalk from Patrick Parker's Seven Laws of AIdentity to Mission-Bound Authorization: where the architecture maps directly, where coverage depends on an assurance level or optional profile, and where real gaps remain."
summary: "Patrick Parker\u0026rsquo;s Seven Laws of AIdentity describe the dynamics a system must govern when agents act through delegated authority: split actors, generated intent, bounded agency, continuous authorization, least exposure, justifiable action chains, and proof-carrying action. This part maps those laws onto Mission-Bound Authorization without turning resemblance into compliance. The strongest matches are generated intent and bounded agency. Continuous authorization and split-actor attribution require the runtime and identity profiles. Least exposure, chain necessity, policy retention, evidence completeness, and embodied action remain conditional or outside the current wire model."
slug: "answering-the-laws-of-aidentity"
tags:
  - "Agentic Identity"
  - "Authorization"
  - "Mission-Bound Authorization"
  - "IAM"
  - "Delegated Authority"
series:
  - "testing-mission-bound-authorization"
---


{{< tldr >}}

- **The result.** [Patrick Parker's Seven Laws of AIdentity](https://www.linkedin.com/pulse/laws-aidentity-patrick-parker-zn9pe/) and Mission-Bound Authorization describe much of the same missing action-governance problem. The strongest matches are Generated Intent and Bounded Agency.
- **The qualification.** This is not a seven-for-seven compliance claim. Split-actor attribution, continuous authorization, least exposure, and proof depend on optional profiles or higher assurance levels. Justifiable Action Chains remains partial because the handbook verifies authorization, provenance, and integrity, but not whether every participant was necessary.
- **The architectural finding.** Authentication and credential issuance cannot carry this whole burden. Neither does Parker ask them to: his AIdentity framing is a metasystem that composes identity, authority, runtime controls, custody, and evidence. Mission-Bound Authorization is a candidate authorization layer inside that larger system, not a replacement for it.
- **The laws.** The yardstick throughout is [the five laws of delegated authority](/series/designing-mission-bound-authorization/#the-five-laws-of-delegated-authority), held beside Parker's seven.
- **What lives in this part.** [How to read the mapping](#how-to-read-the-crosswalk), [the seven-law crosswalk](#the-crosswalk), [what the convergence demonstrates](#what-the-convergence-demonstrates), [three close mappings](#three-mappings-worth-a-closer-look), [two sharpenings](#where-the-crosswalk-sharpens), and [the remaining gaps](#where-the-handbook-delegates-or-declines).
- **Specs (editor's copies).** The [issuance core](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission.html), [runtime enforcement](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-runtime.html), [Consent Evidence](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-consent-evidence.html), and [Audit Transparency](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-audit.html).

**Reading path.** ~13 minutes in order, or start with [the crosswalk](#the-crosswalk).

{{< /tldr >}}

# 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](https://www.linkedin.com/pulse/laws-aidentity-patrick-parker-zn9pe/) 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](/series/designing-mission-bound-authorization/#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](/notes/adopting-mission-bound-authorization/#run-governed-and-beyond): 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:

1. Is the requirement represented directly in the Mission model?
2. Does satisfying it require a runtime control, identity substrate, optional profile, or higher assurance level?
3. 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](/notes/mission-bound-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](/notes/the-mission-is-the-missing-abstraction/) 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](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-metering.html) 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](/notes/least-exposure-is-broader-than-least-privilege/) 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](/notes/the-mission-is-the-missing-abstraction/#three-objects-three-lifecycles), 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_version` identifies 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.