[M1/Security] Enforce the Authority Action Matrix through a governed control plane

[samovers]

Parent: #167
Depends on: #172, #173, #174

Problem

Authority evaluation accepts caller-supplied stage information, applies incomplete actor/delegation rules, and relies on unproven scope containment. Grant/delegation mutation is not consistently governed through the same atomic command path.

Acceptance criteria

• One executable, reviewable table maps each accepted action class to stage, target types, human/software-agent posture, inheritance, and delegability.
• The evaluator derives restrictions from the action class; callers cannot weaken them by supplying an action stage or posture.
• Distinguish AI-assisted human action from autonomous software-agent action and enforce the accepted posture for each action.
• Tenant scope covers only targets whose tenant membership is proven in governed data; descendant/derived scope requires durable containment or lineage evidence.
• Actor-bound commands govern creation, narrowing, and revocation of every grant/delegation family.
• A delegator proves live source authority; delegation cannot widen action, scope, time, inheritance, evidence conditions, or delivery rights.
• Sharing grant/revoke actions receive their own authority checks and required human posture.
• Authority decision, mutation record, edges, invalidation where applicable, and idempotency receipt commit atomically through [M1/Correctness] Introduce a request-scoped UnitOfWork and explicit commit ordering #173.
• Production code cannot use fixture/bootstrap raw inserts as an ordinary authority control plane.
• Hostile tests cover forged stages, cross-tenant targets, invalid inheritance, delegated governance actions, agent posture, expired/revoked source authority, and concurrent grant/revoke.

Boundaries

Implement the accepted Authority Action Matrix; do not add action classes, widen authority, change OFARM law/contracts, or make deployment/capability claims.

Integrated M1/M2 review addendum (2026-07-10)

Initial authority bootstrap

A fresh production tenant cannot use the governed control plane until an initial active Party and source authority exist. Fixture/raw inserts are not an acceptable production bootstrap.

Add these acceptance criteria:

• Define one explicit deployment bootstrap ceremony, separate from public/runtime mutation endpoints, for creating the minimal initial tenant Party and root/source AuthorityGrant.
• Bootstrap is tenant-scoped, deployment-authenticated, one-time, atomic, idempotent for the same canonical request, and permanently auditable with actor/operator provenance and RuntimeBundle.
• A different replay, second root, partial bootstrap, or bootstrap against non-empty/conflicting authority state refuses; no “first caller becomes owner” behavior.
• Normal application startup never silently seeds authority. An unbootstrapped tenant reports a precise fail-closed operational state.
• Define governed rotation/recovery and break-glass posture without creating an unlogged authority-widening path.
• Tests cover two concurrent bootstrap attempts, rollback, replay, cross-tenant use, leaked/expired bootstrap material, restart, and transition from bootstrap authority to ordinary [M1/Security] Enforce the Authority Action Matrix through a governed control plane #175 commands.

This is implementation plumbing, not a new action class or change to law/contracts.

First-release scope alignment — 2026-09-11

Renewed canonical Phase A approval at exact PR #11 head 4494924998183fe3fa7bc1b63b76a85893335044 now defines the initial two-action planning scope. First delivery targets ASSERT_OPERATION_CLAIM and RECEIVE_READ_DATA through #353, with complete unchanged rule semantics and all selected transitive prerequisites. These are approved Phase A semantics, not a promoted executable package.

The other eighteen action evaluations and all applicable human-finalization execution remain open here. Grant/delegation/sharing mutation, bootstrap and rotation/recovery keep their existing owners. Reading their current source evidence is not deferred because mutation commands are later. First-release completion does not close this epic, check off its wider criteria or approve its other capabilities.

Deferred evaluations: OBSERVE_CREATE_OBSERVATION; OBSERVE_ATTACH_EVIDENCE; ASSERT_STRUCTURE; ASSERT_COMPLIANCE; OPERATE_PLAN_INTERVENTION; OPERATE_REPORT_EXECUTION; REVIEW_REQUEST; REVIEW_ACCEPT; REVIEW_REJECT_OR_CONTEST; REVIEW_SUPERSEDE; CONTEXT_INSTALL_PACK; CONTEXT_ACTIVATE_PACK; CONTEXT_DEACTIVATE_PACK; OUTPUT_APPROVE_DOCUMENT_ASSEMBLY; OUTPUT_ATTEST_DOCUMENT_ASSEMBLY; OUTPUT_FILE_SUBMISSION_ASSEMBLY; SHARE_GRANT_ACCESS; SHARE_REVOKE_ACCESS.

Keep CP2A-DEP01 and complete source-history/historical-admission proof open; no qualifying writer or additional action is approved. No existing acceptance criterion, owner, status or child completion is changed by this additive note.

What is next: deliver the selected provider only after its canonical and real-input gates; retain the wider control-plane programme as separate one-boundary Delivery work.

[samovers]

Delivery decomposition after current-main reconciliation

The broad issue is correctly a Tracking Epic. Current main still lets callers supply action_stage, relies on incomplete scope proof, has no governed grant/delegation mutation command, and has no production bootstrap ceremony. Those are real gaps, but they are not one independently reviewable capability.

• Derive runtime authority decisions from an executable action-class matrix #353 is the only child created now. It owns the executable action-class matrix, derived stage/posture rules, and fail-closed scope proof in the runtime evaluator.
• After Derive runtime authority decisions from an executable action-class matrix #353 settles the evaluator interface, create one Delivery child for governed grant/delegation creation, narrowing, and revocation.
• Keep production bootstrap, recovery, and break-glass custody in a separate later Delivery child.

No implementation PR should target #175 directly, and the later children should not be opened speculatively before their input interfaces are known.

What is next: prepare #353's risk-shaped Phase A in its one draft implementation PR.