net-kingdom/canon/standards/service-identity-privilege_v0.1.md

id	type	title	domain	status	version	created	updated	scope	revision	owner	last_reviewed	review_interval	standard_token	profiles	related
netkingdom-service-identity-privilege	standard	NetKingdom Service Identity and Privilege v0.1	netkingdom	accepted	0.1	2026-10-24	2026-10-25	service-account-governance	v0.1	net-kingdom	2026-10-25	3m	service-identity-privilege_v0.1	security-canon/infospace/standards/devops-secrets-management/SecurityCanonDevOpsSecretsManagementStandard.md security-canon/infospace/vocabulary/mode-of-authority/SecurityCanonModeOfAuthority.md	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.