---
id: netkingdom-service-identity-privilege
type: standard
title: "NetKingdom Service Identity and Privilege v0.1"
domain: netkingdom
status: accepted
version: "0.1"
created: "2026-10-24"
updated: "2026-10-25"
scope: service-account-governance
revision: "v0.1"
owner: net-kingdom
last_reviewed: "2026-10-25"
review_interval: 3m
standard_token: service-identity-privilege_v0.1
profiles:
  - security-canon/infospace/standards/devops-secrets-management/SecurityCanonDevOpsSecretsManagementStandard.md
  - security-canon/infospace/vocabulary/mode-of-authority/SecurityCanonModeOfAuthority.md
related:
  - SECURITY-COMPANION.md
  - canon/standards/iam-profile_v0.3.md
  - canon/standards/credential-management_v0.2.md
  - canon/standards/tenancy-posture_v0.1.md
  - canon/standards/posture-feedback_v0.1.md
  - docs/service-identity-inventory.md
  - docs/crisis-custody-list.md
---

# NetKingdom Service Identity and Privilege v0.1

## 0. Status

**Accepted, v0.1. Ratified by the founder on 2026-10-25.** The text is draft-4, unchanged by ratification: the
founder approved draft-3 in principle on 2026-10-24, both owner replies arrived the same day (security-canon and
railiance-platform; §10), and the corrections they produced were applied before ratification. Ratifying the
standard does not apply any exception's elimination path, change any live service, or make a declaration
owner-confirmed; each service owner still adopts it on their own schedule, and the declarations stay
`owner_confirmed: false` until they do.

- **draft-1** (2026-10-24): thirteen rules, naming, five initial exceptions, seven open questions.
- **draft-2** (2026-10-24): the founder's review decided six points (§10), added the agent class and SI-14.
- **draft-3** (2026-10-24): realigned as NetKingdom's **estate profile of SecurityCanon**, after a comparison
  with the canon showed that drafts 1 and 2 restated SEC-DSM rules and invented a taxonomy beside the canon's.
  Classes are replaced by the imported `principal_type` and **authority grants** written `MODE @ SCOPE` with
  the canon's dimensions. Break-glass is an *activation*, not a kind of identity. Every rule now names the SEC-DSM
  rules it profiles and states only what NetKingdom adds. New: the estate identities in canon terms (§3) and
  SI-15, accountable automation. All founder decisions and every rule id from draft-2 are kept.

- **draft-4** (2026-10-24): applies the owner replies. security-canon confirmed all five mode readings and found
  citation errors (§4, §8), now corrected; railiance-platform prepared the F-1 and `aal2` role changes (source only);
  key-cape, glas-harness and state-hub assessed the agent-identity and attribution gaps (§10). No decision changed.

The offline validator (`tools/service-identity`) implements draft-3 (principal type and grants, NK-WP-0054-T08).
The live health check (T04) does not exist yet.

## 1. Purpose, scope and authority

This standard says which accounts, with which authority, may exist inside the services that make up
NetKingdom, and how that is declared and checked.

It is a **profile**, not a second rulebook. Per SecurityCanon SEC-ADR-001, the identity model belongs to
InfoTechCanon and security concept definitions to SecurityCanon; NetKingdom holds the security architecture and
standards of record for the estate. So this standard:

- **imports** the vocabulary: `principal_type` as classified by SecurityCanon over the InfoTechCanon Principal
  (the canon itself words its ownership two ways; open as SECURITY-IN-0001) and the Mode of Authority grant
  notation with its dimensions (SecurityCanon, draft 0.2.0);
- **profiles** the DevOps Secrets Management Standard (`SEC-DSM` 1.0.0): it names the rules that apply to
  NetKingdom accounts and, where NetKingdom is stricter, says so;
- **adds** only what is estate-specific: which identities exist, their names, the declarations, the link to
  crisis custody, and how conformance is checked.

Out of scope: tokens (IAM Profile v0.3), custody procedure (Credential Management v0.2), tenant isolation
(Tenancy Posture, Security Zones), and accounts a tenant creates inside its own workloads.

## 2. Vocabulary (imported)

**Principal type** (`principal_type`): `HUMAN`, `WORKLOAD`, `SERVICE`, `AGENT`, `CONTROLLER`, `DEVICE`. IAM
Profile v0.3 carries the same distinction in tokens in lower case. `Environment` is cited as a Mode of Authority
dimension without naming an owner, because the canon names two.

**Authority grant:** `MODE @ SCOPE`, where the mode is one of `USE`, `OBSERVE`, `OPERATE`, `ADMINISTER`,
`GOVERN`, `CONSTRUCT`, `SOVEREIGN`. A grant may state `activation` (`STANDING`, `JUST_IN_TIME`, `SCHEDULED`,
`APPROVED`, `INCIDENT`, `BREAK_GLASS`, `RECOVERY`), `provenance`, `environment` (`DEVELOPMENT`, `TEST`,
`STAGING`, `PRODUCTION`, `RECOVERY`), `evidence` and `relation` (`DELEGATED`, `IMPERSONATED`). Modes classify the
*kind* of authority, not its amount.

**Account** (NetKingdom term): an identity held in a service's own store, with or without a stored credential.
**Credential** and **standing authority** are used as in SEC-DSM §4.

Estate conventions, which are names for recurring grant shapes and not new canon terms:

| Convention | Canon expression |
| --- | --- |
| Bind account `svc-<service>` | a `SERVICE` principal with `USE @ directory`, read-only operations, one consumer |
| Service-admin account `<short>-admin` | an account held by a `HUMAN`, `ADMINISTER @ <that service>` |
| Break-glass | any grant with `activation = BREAK_GLASS` |
| Agent | an `AGENT` principal with `relation = DELEGATED` and the person it acts for as `authority_context` |

Draft-2's classes map as follows: `human` → `HUMAN`; `break-glass` → `activation = BREAK_GLASS`; `bind` and
`infrastructure` → `SERVICE` with the matching grant; `service-admin` → the convention above; `workload` →
`WORKLOAD` or `SERVICE`; `agent` → `AGENT`.

## 3. The estate identities

The founder's model, written in canon terms. This is what the declarations must express.

| Account | Principal | Grants | Activation | Environment |
| --- | --- | --- | --- | --- |
| `platform-root` | `HUMAN` | `SOVEREIGN @ platform`; `CONSTRUCT @ platform` (build mode), a separate grant | `BREAK_GLASS` for `SOVEREIGN`; standing for `CONSTRUCT` | `SOVEREIGN`: `PRODUCTION`, and `RECOVERY` for restored environments; `CONSTRUCT`: `DEVELOPMENT` and `TEST` only, never `PRODUCTION` |
| `admin` | `HUMAN` | `OPERATE @ platform`; `OPERATE @ backup-system`; `ADMINISTER @ directory` through an admin group | `STANDING` | `PRODUCTION` |
| `tegwick` | `HUMAN` | `CONSTRUCT @ product` | `STANDING` | `DEVELOPMENT`, `TEST` |
| `ld-admin` | account held by a `HUMAN` | `ADMINISTER @ lldap` | `BREAK_GLASS` (sealed fallback) | `PRODUCTION` |
| `pi-admin` | account held by a `HUMAN` | `ADMINISTER @ privacyidea`; `GOVERN @ privacyidea` (its policy `pi-admin-all-rights` can set the policies that bound other admins) | `STANDING` (exception SI-X5: only a local admin exists) | `PRODUCTION` |
| `svc-authelia`, `svc-keycape`, `svc-privacyidea` | `SERVICE` | `USE @ directory`, read-only | `STANDING` | `PRODUCTION` |
| provisioner account | `SERVICE` | `ADMINISTER @ directory/people,groups`, narrowest working scope | `STANDING` | `PRODUCTION` |
| Claude Code, Codex, Grok sessions | `AGENT` | what the tools they can reach allow (SI-14) | per task | that of the person they act for |

`backup operator → OPERATE @ backup-system` and `developer → CONSTRUCT @ product` are the canon's own
translations, and match the founder's intent that `admin` operates backups and `tegwick` builds.

Readings confirmed by security-canon on 2026-10-24 (its review, `docs/netkingdom-service-identity-review.md`):
`USE @ directory` for a bind, `SOVEREIGN` with `BREAK_GLASS` for `platform-root` (the canon's vocabulary card has the
same shape), `ADMINISTER` for a local admin (the canon's own example is "break-glass admin → ADMINISTER,
activation=BREAK_GLASS"), and `OPERATE @ backup-system` for `admin`. Notes: `SOVEREIGN @ platform` does not imply
sovereignty over realms nested inside it, so recovering OpenBao, LLDAP or the identity realm is its own scope. The
canon flags `GOVERN` plus `CONSTRUCT` on one actor as a finding, and is silent on `SOVEREIGN` plus `CONSTRUCT`;
the two grants are kept separate and split by environment. Whether break-glass use of production is
`PRODUCTION` or `RECOVERY` is open in the canon (SECURITY-IN-0002); the direct form is used here.

## 4. Rules

Each rule keeps its draft-2 id. **Canon** names the SEC-DSM rules it rests on, with their strength: *MUST* and
*MUST NOT* bind; *SHOULD* guides. **NetKingdom adds** states what is stricter or estate-specific. A NetKingdom
MUST that rests on a canon SHOULD is said to do so. security-canon checked these references on 2026-10-24
(`docs/netkingdom-service-identity-review.md` in that repository).

**SI-1 One account, one principal type, one purpose.** Canon: DSM-ID-004 (MUST: human and machine credentials are
distinguishable). DSM-AP-003 (shared production account) is an anti-pattern and is cited only as an illustration.
NetKingdom adds: an account presented by a `HUMAN` and by a `SERVICE` is non-conformant, whatever its privileges.

**SI-2 People and services never share a credential.** Canon: DSM-ID-004 (MUST NOT: human credentials embedded in
automated workloads; SHOULD NOT: machine credentials used interactively). NetKingdom adds: the stronger "never
share", and that a human's password is not stored where a service reads it, including a Kubernetes Secret.

**SI-3 Bind accounts.** Canon: DSM-ID-001 (SHOULD: each workload its own identifiable identity; MUST NOT: depend on
a shared generic credential where individual identity is practical) and DSM-AUTH-001 (MUST: least authority).
NetKingdom adds: the SHOULD becomes MUST, so each consuming service has its own bind account with read-only
`USE @ directory`; and "never used interactively" strengthens DSM-ID-004's SHOULD NOT. A service that must write gets
its own `SERVICE` account with the narrowest working `ADMINISTER` scope, never the service-admin account.

**SI-4 One local admin per service.** Canon: DSM-AUTH-001 (MUST) supports limiting the grant to that one service.
NetKingdom adds: one local admin account per service, named `<short>-admin`, whose grant is `ADMINISTER @ that
service` and, where the service has a single admin tier, `GOVERN @ that service`. Nothing in the canon requires the
single account or the naming.

**SI-5 Attributed administration first.** Canon: DSM-AUDIT-003 (SHOULD: audit records identify the principal) and
the objective of reducing standing authority (SEC-DSM section 4.12, a statement of objective). NetKingdom adds, as a
MUST resting on those: day-to-day administration uses the administrator's own `HUMAN` account through group
membership. The local service-admin account is a sealed fallback listed in the crisis custody list.

**SI-6 Break-glass is an activation.** Canon: DSM-HUM-003 (MUST: break-glass is exceptional, attributable, auditable,
time-bounded where practical); DSM-ROOT-001, -003, -004 (MUST); DSM-ROOT-002, -005 are SHOULD. NetKingdom adds:
`platform-root` holds `SOVEREIGN @ platform` with `activation = BREAK_GLASS` in production, held offline; it
authorizes and does not operate; it is never used for routine work, validation or as a drill's test subject; its
`CONSTRUCT` authority (build mode) is not available in `PRODUCTION`. DSM-ROOT-003 itself requires only that root
credentials not travel through ordinary application delivery.

**SI-7 The developer identity.** Canon: DSM-AP-012 (an anti-pattern: developers routinely holding production
secrets) illustrates the risk; it is not a rule. NetKingdom adds, as its own MUST: `tegwick` holds `CONSTRUCT @
product` in `DEVELOPMENT` and `TEST`, no production credential and no recovery custody item.

**SI-8 Assurance.** NetKingdom rule, using IAM Profile v0.3 assurance claims. Every `HUMAN` account and every
service-admin account requires a second factor where the service can enforce one. A role that grants `ADMINISTER` or
higher MUST bind the assurance claim itself (for example `aal2` in an OpenBao role); relying on an upstream check
needs an exception. Decided 2026-10-24 for OpenBao `platform-admin`.

**SI-9 Every place a credential lives is declared.** Canon: DSM-INV-001 (MUST: maintain an inventory of
security-significant persistent credentials); DSM-INV-002 (SHOULD: attributes; it has no location field) and
DSM-STORE-002 (SHOULD: minimize copies). NetKingdom adds: declaring every storage place, and that a person's
password safe MUST NOT hold a `SERVICE`, `WORKLOAD` or `AGENT` credential.

**SI-10 Owner, rotation and coupling.** Canon: DSM-INV-003, DSM-ROT-001, DSM-ARCH-002 and DSM-TRANS-002 (MUST);
DSM-ROT-003 (MUST NOT consider rotation complete until adopted) is the basis of coupling. NetKingdom adds:
declaring the coupling. Static binds are governed residual secrets (exception SI-X2).

**SI-11 Declared or it is a finding.** Canon: DSM-INV-006 (MUST treat a discovered, unowned production credential as
a finding); DSM-INV-005 and -007 are SHOULD. NetKingdom adds, stricter: every account that exists and is not
declared is `unknown`, and `unknown` is itself a conformance result. A legacy account has a disposition with owner
and date.

**SI-12 Recovery identities are in the crisis custody list.** Canon: DSM-ROOT-001 and -004 (MUST). NetKingdom adds:
each recovery item answers "does it work with SSO and OpenBao down?", and an account that cannot be used while its
own service is down is never the only recovery path.

**SI-13 Validation is operated by the operator identity.** NetKingdom rule. Restore drills and backup validation are
`OPERATE @ backup-system`, run by `admin` with `admin`'s own token as the test subject, and record which identity ran
each stage.

**SI-14 Agents.** Canon: DSM-AGENT-001, -004, -006, -007, -008 (MUST or MUST NOT); DSM-AGENT-002, -003, -005 are
SHOULD; DSM-AP-016 and -017. DSM treats an agent as a kind of workload identity; mapping it to the `AGENT` principal
type is NetKingdom's reading. NetKingdom adds: an agent presents as `AGENT` with its mode (IAM Profile v0.3); its
tokens last at most 60 minutes (3600 seconds, decided 2026-10-24; DSM-AGENT-003 only says "short"); it is bounded by
a named boundary policy; and its **effective authority includes everything reachable through its tools**
(DSM-AGENT-008). **Scope:** the rule can be met in full only for sessions that a harness launches (glas-harness,
GLAS-WP-0018). An interactive Claude Code, Codex or Grok terminal stays at the person's tool-reachable authority
until a session contract exists, and declarations say so (§10).

**SI-15 Accountable automation.** Canon: DSM-AUDIT-001 binds the secrets or capability authority and not every
action of an agent, and DSM-AUDIT-003 is a SHOULD; DSM-DX-002 (SHOULD: reusable integrations) is only the generic
basis for having a golden path. The reconstructability claim and the path below are NetKingdom's, resting on the
companion's section 7 ("every action is reconstructable as the caller's action"). Every state-changing action by an
`AGENT` or `WORKLOAD` is reconstructable: actor, on whose authority, run or session, operation, result and where the
evidence is kept. High-impact actions follow the NetKingdom golden path:

1. **Prepare.** The agent writes source-reviewed tooling and tests it on synthetic fixtures. No live effect.
2. **Admit.** A person authorizes the exact action: a signed admission or a recorded decision.
3. **Execute.** The person, or a bounded executor under the admission, runs it, isolated where possible.
4. **Verify.** An independent verifier checks the receipt against the source it names.
5. **Retain.** The receipt is kept by hash, with no secret values.

Evidence available today: commit trailers (`Assistant`, `Assistant-Session`, `Assistant-Process`), safe receipts
with source hashes, signed admissions, and State Hub progress events. Hub authorship is unauthenticated free text; the
design to attribute it is STATE-WP-0100 (§10).

## 5. Naming

| Convention | Pattern | Notes |
| --- | --- | --- |
| Bind account | `svc-<service>` | one per consuming service; `svc-<service>-<function>` if one needs several |
| Service-admin account | `<short>-admin` | the short form belongs to one service: `pi-admin` (privacyIDEA), `ld-admin` (LLDAP only) |
| Break-glass | `platform-root` | the king credential |
| Human | the person's own login | `admin`, `tegwick` |
| Workload, service, agent | the token subject form in use | for example `service:secrets-engine`; IAM Profile v0.3 governs the token |

The name `admin` is the human platform administrator's name wherever it appears (decided 2026-10-24); no
service-admin account is called `admin`. A `svc-` or `-admin` name MUST NOT be used for a human account. A
federated role that holds no credential, such as an OpenBao role mapping a group to a policy, is not an account
and is not bound by this rule.

## 6. Declaration

Each service declares every account it holds: name, `principal_type`, purpose, grants (`MODE @ SCOPE` with
activation and environment), operations, where the credential lives, consumers, owner, rotation and coupling,
second-factor requirement, status (`active`, `legacy`, `planned`) and exceptions. The canon's ten questions are
the checklist for a complete entry: who is the actor, on whose authority, what mode, over what scope, which
operations, where the authority originates, how it is activated, which realm enforces it, who keeps the evidence,
and who can override enforcement.

Declarations start in this repository (`tools/service-identity/declarations/`) and move to each service's
repository as its owner confirms them (decided 2026-10-24). A declaration holds no credential and no
secret-shaped value.

## 7. Conformance and the health check

Per account the result is `conformant`, `non-conformant`, `excepted`, `unknown` or `planned`. Unknown is a
finding, not a pass. These match the companion's conformance states: `excepted` is a declared gap,
`non-conformant` is an undeclared violation.

The offline validator decides from a declaration alone: SI-1, SI-2, SI-3, SI-4, SI-6, SI-7, SI-8, SI-9, SI-11,
SI-12, SI-14 and naming; more than one service-admin account per service is an advisory. SI-5, SI-10, SI-13 and
SI-15 are process rules, checked by evidence rather than by declaration. Dates are explicit (`--as-of`).

The health check (T04) is SEC-DSM's automated discovery (DSM-INV-004, a SHOULD) applied to accounts. It compares
declared against observed state from owner-provided read-only metadata and repository manifests. It MUST NOT read a
Secret; that rule is NetKingdom's and is compatible with DSM-AUDIT-002.
Its findings are proposals routed to the owner through Posture Feedback, with an evidence-freshness bound. It
changes nothing.

## 8. Exceptions

Exceptions follow DSM-EXC-001 to DSM-EXC-004: explicit, recorded (rule, account, reason, owner, compensating
control), expiring or revalidated. DSM-EXC-002 accepts an elimination path *or* a review trigger; NetKingdom requires
the **elimination path** (what change ends the exception), which is stricter and consistent with DSM-EXC-004.
DSM-EXC-001 binds violations of a canon MUST; an exception against a rule that is only NetKingdom's is NetKingdom's own.

| Id | Rules | Account | Reason | Elimination path |
| --- | --- | --- | --- | --- |
| SI-X1 | SI-1, SI-2, SI-3, SI-4, SI-9, naming | LLDAP `admin` | The human, the super-admin and the shared bind of four services in one account; password in a person's safe and a Kubernetes Secret | NK-WP-0054-T05: `svc-*` binds, provisioner account, `ld-admin`, `admin` human-only |
| SI-X2 | SI-10 | LDAP bind accounts | Static long-lived credential; LDAP has no lease | Governed residual secret (DSM-TRANS-002) until a federated directory lookup exists |
| SI-X3 | naming, SI-11 | `trigger-admin` (privacyIDEA) | Legacy account, consumers uninventoried | NK-WP-0049-T22 disposition |
| SI-X4 | SI-8 | OpenBao `netkingdom-platform-admin` | Role binds the group claim only | railiance-platform binds `aal2` (decided 2026-10-24); prepared in source as RPF-WP-0065, applied by a founder-run live step |
| SI-X5 | SI-4, SI-5 | privacyIDEA | Only a local administrator is supported | Upstream support for attributed administrators |

**Findings at adoption, not excepted:** F-1, the OpenBao coding-agent role binds `principal_type: service`, so the
agent presents as a service against IAM Profile v0.3 (SI-14). railiance-platform has prepared, in source only,
a transitional role that accepts both `service` and `agent`, plus an exception record with compensating controls,
the removal condition and a review date of 2026-12-31 (RPF-WP-0065). KeyCape must first emit `principal_type: agent`
(KEY-WP-0043), because flipping the role alone would lock the agent out. The account stays non-conformant until the
owner accepts that exception or the issuer and role change land.

## 9. Relationship to other documents

- **SecurityCanon:** vocabulary from Mode of Authority (draft 0.2.0); rules profiled from SEC-DSM 1.0.0. A
  disagreement between this profile and the canon is a finding for the canon's owner, not a local override.
- **InfoTechCanon:** owns the identity model and `principal_type`.
- **Security Companion** (`SECURITY-COMPANION.md`, operative form of the security layer model): its §7 rules for
  agents ("no standing credential", "tool availability is not permission", "every action is reconstructable as the
  caller's action") are the basis of SI-14 and SI-15. Its four conformance states map to §7 here.
- **IAM Profile v0.3:** governs tokens, including the agent principal. KeyCape's confidential clients stay governed
  by the profile plus a declaration (settled 2026-10-24).
- **Credential Management v0.2 §6** lists `LLDAP_LDAP_USER_PASS` as a three-way coupling; the inventory found five
  consumers. That row is corrected when SI-X1 is eliminated.
- **Crisis custody list** (`docs/crisis-custody-list.md`) is the recovery companion to SI-9 and SI-12, and the
  enumeration of roots that DSM-ROOT-001 asks for.

## 10. Decisions and open items

**Approved by the founder, 2026-10-24, on review of draft-3:** the profile approach (§1, §2); `platform-root` as
`SOVEREIGN @ platform` with `BREAK_GLASS` activation in production and build-mode `CONSTRUCT @ platform` in
`DEVELOPMENT` and `TEST` only; `admin` as `OPERATE @ platform`, `OPERATE @ backup-system` and `ADMINISTER @ directory`
through an admin group (§3). Ratification as v0.1 follows the owner replies named in §0.

**Decided by the founder, 2026-10-24:**

1. OpenBao `platform-admin` binds the `aal2` claim itself (SI-8). The change is railiance-platform's.
2. The human administrator administers through a group on their own account (SI-5); service-admin accounts are
   sealed fallbacks.
3. Declarations start here and move to each service repository as owners confirm them (§6).
4. Agents are a distinct principal with SI-14; their token ceiling is 60 minutes.
5. `ld-admin` is for LLDAP only; `admin` stays the human's name on every service.

**Settled with draft-3 (not objected to in review):** KeyCape's confidential clients are governed by IAM Profile v0.3 plus a
declaration; the reserved-name rule applies to credential-holding accounts, not to federated roles.

**Open in the estate, with the plan that eliminates each gap:**

- **Hub authorship is unauthenticated.** Progress events and decisions carry a free-text `author`. For SI-15 they
  need an attributable actor and session, as commits already have.
- **Agents act under the person's ambient authority.** There is no per-run agent identity yet (DSM-AGENT-002). Until
  there is, each agent session's effective authority is the person's tool-reachable authority, and that is a
  declared gap, not conformance.

**Owner replies, 2026-10-24** (all documentary; none applied anything live):

| Owner | Result | Plan |
| --- | --- | --- |
| security-canon | All five mode readings confirmed; citation errors found and corrected in §4, §8 | SECURITY-IN-0001 (ownership wording), SECURITY-IN-0002 (four canon questions) |
| railiance-platform | F-1 and `aal2` prepared in source, rollback written; nothing applied | RPF-WP-0065; the `aal2` live step is the founder's |
| key-cape | Agent tokens are feasible **with changes**, not today. Autonomous agents: `client_credentials` with a new agent client class (2 to 3 days). Delegated agents: RFC 8693 token exchange (1 to 1.5 weeks). Missing: `principal_type` `agent`, the `agent{id,mode}` claim, `act.sub`. Risks: revocation state is in memory; client registrations are static | KEY-WP-0043 |
| glas-harness | Per-session identity and attribution are feasible **only for sessions the harness launches**. Interactive terminals stay outside | GLAS-WP-0018 |
| state-hub | Option A recorded: `X-Actor-*` headers into an append-only attribution table, labelled `claimed`, `unattributed` or `legacy`; real authentication needs key-cape tokens (Option C). **Decided 2026-10-25:** Option A is phase 1 with no `hub_core` schema change; correlation by equal session and run id only (no commit verifier); phase 3 observes tokens and enforcement is a separate later decision; existing authors are not backfilled | STATE-WP-0100 |

**Needs an amendment:** IAM Profile v0.3 asks for assurance evidence for "any delegated human authority" but defines no
nested claim for it. Delegated agent tokens need one; it belongs in the IAM Profile v0.4 amendments.

**Open canon questions** (security-canon, SECURITY-IN-0002): whether break-glass use of production is `PRODUCTION` or
`RECOVERY`; whether one actor may hold `SOVEREIGN` and `CONSTRUCT` separated by environment; whether a sealed offline
credential is a `HUMAN` principal or a credential held by a human; and the ownership wording of `principal_type` and
`Environment`.

**To be rehearsed in isolation, not decided:** introducing `ld-admin` as the configured super-admin and demoting
`admin` (T06); the provisioner's narrowest scope (T05); whether a bind account can be kept from signing in
interactively (SI-3).

## 11. Adoption

Structure first, tooling second. Ratify the vocabulary and rules (the declarations and validator already follow
draft-3); confirm the declarations with their owners; run the health check read-only (T04) and publish the
first report; then eliminate the exceptions one by one, starting with SI-X1 (T05). No exception is closed by
writing a declaration. Each is closed by the live change and an evidence run.