railiance-platform/docs/credential-lane-designs/factory-audit-senders-review.md

Factory audit senders: concrete custody review

CCR-2026-0021 and CCR-2026-0022 were approved by the user on 2026-09-11, replying "good, go on" to the explicit question naming the platform operator, Audit Core owner, and each producer owner. The source review comments and the two existing State Hub decisions record that approval. RPF-WP-0035-T08 owns platform execution; AUDIT-WP-0009-T09/T11 retain receiver admission. Approval alone does not mark custody delivered or either producer admitted.

Approved scope

Request	Producer / exact source	OpenBao path	Producer Secret / key
CCR-2026-0021	approval-engine	platform/workloads/approval-engine/audit-sender	approval-engine/approval-engine-audit / audit-token
CCR-2026-0022	informed-decision	platform/workloads/informed-decision/audit-sender	informed-decision/informed-decision-audit / token

Each sender is limited to tenant:platform, write true, read false, evidence_kind: load-bearing, secret_policy: redact. The producer receives only its own AUDIT_TOKEN. CUSTODY_REQUEST is a non-secret provenance marker stored beside that token, enabling an interrupted first provision to identify its own version-1 value. It is not projected to the producer.

Each lane has its own exact-path policy, Kubernetes auth role and namespace- restricted ClusterSecretStore. Only external-secrets/external-secrets may log in to the reader role (15-minute session). Neither producer can read the full sender registry or its sibling's token. The coding-agent boundary gains exact denies on the two new data/metadata paths; existing rules are preserved.

The approved first-provision operation generates two independent values in the attended platform process, store them with CAS=0, and append the exact identities to platform/workloads/audit-core/senders with compare-and-set on its observed KV version. That process necessarily reads the existing registry in memory; it never emits its credentials or gives it to a producer. No token passes through Git, a Hub record, command arguments or stdout/stderr.

Historical receiver finding (resolved before custody)

On 2026-09-11 the native receiver is 1/1 Ready on forgejo.coulomb.social/coulomb/audit-core@sha256:c2fe39a0185b99be3fc0cb14d2de69772b8e66e20490097c9d11d90cc39719a6. Its SenderIdentity has no evidence_kind support. A synthetic registration probe in the native pod fails the load-bearing contract; the same probe against current Audit Core source passes. Readiness did not detect this contract gap.

factory_audit_custody.py receiver-check now enforces that contract before any credential access. An approved CCR alone cannot bypass it. Audit Core must build, publish, admit and roll out its current implementation and source scope first. Its existing AUDIT-WP-0009-T09/T11 tasks retain that work; no completed source task is reopened. No receiver restart or deployment was done here.

Approval Engine's namespace is also absent. Three of four ESO objects passed server dry-run in their intended namespaces; its ExternalSecret was refused because that namespace does not exist. This packet creates no namespace, workload or network permission. Its owner must supply that prerequisite.

Current execution status

Both independent version-1 credentials are provisioned and the authoritative registry advanced with CAS 7→8, preserving existing senders and fields. The fresh attended delivery retry completed at 2026-09-11 08:27 UTC: exact native reader/scope/namespace checks passed; both ESO projections are Ready and match custody; registry JSON matched before Audit Core reloaded. The temporary namespace is absent and Warden exited 0 with session revocation confirmed. The receiver is operational/durable and 1/1 Ready on c82e0442de0f.

Both CCRs remain applied. Native producer accepted/duplicate-after-restart and receiver scope/read-refusal checks passed at 10:42 UTC. Independent archive readback and audit bearer-revocation acceptance remain pending. The completed reader-session revocation does not expire those audit bearers. See the seed and native delivery receipts. Earlier failed login receipts remain historical. Do not repeat provisioning or delivery for this unchanged successful result; continue producer acceptance.

Executable sequence

Review the source and exact policies:

python3 scripts/credential-change.py render CCR-2026-0021
python3 scripts/credential-change.py render CCR-2026-0022
python3 scripts/factory_audit_custody.py plan

After a compatible receiver release, the credential-free check is:

python3 scripts/factory_audit_custody.py receiver-check \
  --kubeconfig /operator/railiance-kubeconfig \
  --expected-receiver-image forgejo.coulomb.social/coulomb/audit-core@sha256:ADMITTED_DIGEST \
  --receipt /operator/unique-receiver-receipt.json

The seed command requires approved CCR files with all named owner reviews, the expected image, exact Railiance cluster UID, ready/current pod, both target namespaces and the Warden attended platform-admin login envelope. Route via warden route show openbao-platform-admin-login --json before arranging access. Use its installed attended wrapper; do not copy a token into the command.

Inside that envelope, invoke:

python3 scripts/factory_audit_custody.py seed \
  --kubeconfig /operator/railiance-kubeconfig \
  --expected-receiver-image forgejo.coulomb.social/coulomb/audit-core@sha256:ADMITTED_DIGEST \
  --confirm 'PROVISION CCR-2026-0021 CCR-2026-0022' \
  --receipt /operator/unique-custody-receipt.json

A successful seed deliberately reports custody_seeded_pending_delivery_and_receiver_reload. It applies the exact reader metadata and seeds custody, but does not apply ESO objects, reload the shared receiver or claim live ingestion. Preserve that receipt. After an interruption, review it and use --resume with a new receipt: only exact request-owned version-1 custody is reused. Changed tokens, source scopes, provenance, unknown duplicate identities and concurrent registry writes refuse. No automatic deletion or rotation is attempted on failure.

Under the same reviewed lane, the subsequent attended delivery uses manifests/factory-audit-senders.yaml; verify both stores/ExternalSecrets and exact token equality inside the protected process. Sync the existing registry ExternalSecret, verify its update, and reload Audit Core through its owner runbook. Then run each real producer's accepted/duplicate and wrong-source, wrong-tenant/read-refusal checks and retrieve evidence with the independent operator reader. The delivery helper automates delivery, scope checks and receiver reload; it does not deploy producers or automate their outbox acceptance. Do not mark either CCR verified/active until those receipts exist.

Attended delivery helper

After the seed receipt exists, run this silent command inside a fresh Warden attended platform-admin envelope (do not rerun seed or reuse a revoked session):

python3 scripts/factory_audit_delivery.py \
  --kubeconfig /operator/railiance-kubeconfig \
  --server https://127.0.0.1:16444 \
  --expected-receiver-image forgejo.coulomb.social/coulomb/audit-core@sha256:c82e0442de0fd181342916ae9cd5d6de41d859e1efda637bd93936c67873afa5 \
  --confirm 'DELIVER CCR-2026-0021 CCR-2026-0022' \
  --receipt /operator/unique-delivery-receipt.json

The helper pins the reviewed manifest bytes and native cluster/image. It verifies exact policy, role, version-1 custody and provenance; independently logs in as each native ESO reader; proves sibling, full-registry, metadata, listing, wrong-SA and coding-agent-boundary denials; and revokes temporary reader tokens. It checks exact projected token equality and ESO ownership in captured memory, forces receiver-registry reconciliation and compares the complete JSON before restarting the receiver. A uniquely owned temporary namespace proves wrong-namespace login and explicit ESO namespace restriction with no Secret created. Cleanup uses the namespace UID precondition.

The metadata-only receipt advances by phase. Its successful status is delivered_and_scope_verified_pending_producer_acceptance. Failures preserve completed phases for diagnosis; they do not rotate or delete permanent custody. Receiver accepted/duplicate and negative HTTP checks, real producer outbox recovery and bearer revocation remain owner acceptance work. Do not mistake short-lived ESO-reader revocation for receiver bearer revocation.

Revocation and limits

ESO login expiry does not expire an audit bearer. Stop the affected producer, remove only its token from the receiver registry using CAS, reload the receiver and prove refusal, then disable its reader/projection. Retain stored events and KV provenance. Rotation is separately reviewed and overlap-first. Existing senders and reader permissions remain intact.

warden route show audit-core-senders still points to the older Mason bootstrap. The receiver runbook records the later OpenBao migration; this packet uses that current authority and the platform's existing attended custody mechanics. It creates no second registry or generic credential broker.

Factory policy/caller admission, registered human binding, CCR-2026-0019's operator group, native runtime delivery and spending/operating acceptance stay with their existing records. Sender approval does not admit any of those acts.