glas-harness/docs/production-dependency-handoffs.md

Production dependency handoffs

Prepared 2026-09-06 from GLAS-WP-0012 and the deployed policy-service evidence. Sent to the seven owners on 2026-09-06 after explicit user authorization. Receipt IDs are in production-handoff-receipts.json. Delivery does not establish owner acceptance or an authority grant. Glas coordinates acceptance; each owner retains implementation and authorization. No credential values belong in responses.

Ready infrastructure

FLEX-WP-0021-T04 deployment now serves flex-auth-secrets-engine revision 3, available 1/1, with authenticated caller enforcement. Six live policy fixtures passed at revision 2. Positive/negative network probes passed at revision 1; revision 3 retains the same policy image and ingress policy. In-cluster endpoint only: http://flex-auth-secrets-engine.flex-auth.svc.cluster.local.:8080. Package: secrets-engine.catalog-lane.lifecycle v2. Image: sha256:db1c4f7e621c7ea119489a321d7db0e05da09afc17be5f69d873b2b3c7f60cfc. Caller-auth is enforce after successful short-lived caller adoption. Direct cluster ingress requires namespace secrets-engine and pod label app.kubernetes.io/name=secrets-engine. Workstation access uses a loopback-only kubectl port-forward through authenticated Kubernetes API TLS and a ten-minute TokenRequest token for system:serviceaccount:secrets-engine:secrets-engine, audience flex-auth. Bare Service DNS must not be used from the workstation. See flex-auth/docs/operator-caller-access-path.md and FLEX-WP-0023. Caller provenance in the envelope (T04) remains open; response signatures are separate FLEX-WP-0024 work. The forwarding session is temporary, not a deployed tunnel.

1. Tenant alignment — key-cape, approval-engine, secrets-engine, flex-auth

Operator decision accepted 2026-09-06: use exact tenant:platform for the approval store, both proposed approval-client JWT tenant claims, and lifecycle CheckRequest tenant. This is the platform management and services tenant. See accepted decision. No alias or implicit cross-tenant privilege follows from the landlord role.

Return: aligned source/deployment coordinates and wrong-tenant denial evidence. The decision is resolved; owner implementation and verification remain open. Related: KEY-WP-0013-T02, APPROVAL-WP-0002-T01, SECRETS-WP-0009-T03.

2. Admit service-client custody — railiance-platform with key-cape

Use key-cape/docs/approval-engine-provisioning-request.yaml, not a new invented lane. After tenant alignment, admit these proposed exact coordinates:

Client	OpenBao entry	Secret field	Kubernetes delivery
secrets-engine-approval	platform/workloads/secrets-engine/approval-client	client_secret	sso/keycape-secrets-engine-approval-client, key client-secret
approval-engine-operator	platform/workloads/approval-engine/operator-client	client_secret	sso/keycape-approval-engine-operator-client, key client-secret

Resolve first-provision authority through the custody owner. Do not bootstrap these via the very production lane whose authorization they enable. Record admission/CCR ids, field names, reader/writer scope, revocation and delivery receipts, never values. Supply protected delivery for KeyCape and the intended client process; a KeyCape-side Secret alone does not provision the consumer.

Return: admitted owner records, protected materialization and exact consumer bindings, plus negative sibling/read/write tests where applicable. Local KEY-WP-0013 source registration is not evidence of live provisioning.

3. Deploy and prove KeyCape clients — key-cape

KEY-WP-0013-T02: roll out resource-audience support and both registrations with the approved custody inputs. Live issuer is https://kc.coulomb.social; JWKS service is keycape.sso.svc.cluster.local:8080/jwks. Verify JWT signature, resource audience approval-engine, exact agreed tenant, subject, scopes, principal type and lifetime (15m), plus excessive-scope/wrong-secret denial. Preserve existing registrations and signing key.

Return immutable image and claim-contract proof references; no tokens. Identify whether missing human callback registration blocks this service-only phase or can remain separately tracked. Do not invent a human callback or relax MFA.

4. Register approval audit source — audit-core with railiance-platform

AUDIT-WP-0009-T09 / AUDIT-IN-0001 is now on the deployment critical path: approval-engine production startup requires audit delivery. Its task currently says low priority and "not blocking" because the producer is not emitting; please review that dependency against the concrete startup gate.

Register source/sender approval-engine, agreed tenancy, the four event classes, retention/access/export policy and load-bearing evidence handling. Provision its token by the approved custody path to approval-engine/approval-engine-audit key audit-token; add narrowly scoped receiver ingress and receiver config. Keep user-engine's sender unchanged.

Return: registration/custody references, accepted/duplicate and wrong-token proof, approved ingress, and the remaining cadence/reconciliation gates (AUDIT-WP-0009-T04/T06/T09). No sender token in the response.

5. Release approval-engine — approval-engine

APPROVAL-WP-0002-T03: build/scan an immutable image for current migrated schema, render corrected issuer/JWKS and agreed tenant, and validate deployment inputs. Image preparation can proceed before live credential materialization. Deploy only when identity and audit requirements pass; retain single-writer PVC and migration semantics. For first install record no prior DB; for replacement require verified backup. Prove readiness, restart persistence and restore.

Return deployed base URL, image digest, migration/storage/restart/restore and audit evidence. Existing manifest endpoint fixes at 06544b0 do not close T03.

6. Adopt authorization and activate lane — secrets-engine with flex-auth

SECRETS-WP-0009-T03 / FLEX-WP-0021-T05: consume the deployed policy coordinates above through a verified caller access path. Confirm exact package/image and CheckRequest/claim binding against the real service; adopt the caller identity before authentication enforcement. Configure the approval endpoint and per-lane authorization id only after the owner service and approval exist.

Then apply the exact data-only read policy/AppRole, verify positive and negative access and protected owner delivery for glas-claude-agent-dev-anthropic. Custody CCR-2026-0016 is not a per-action authorization. Do not use a human runtime token or unsafe-demo. Return activation and scoped delivery receipts.

7. Pin combined runtime — sand-boxer with rein-aharness

SAND-WP-0015-T04: pin Claude executable plus the rein Python artifact, prepare the exact combined sandbox profile and credential-route binding, and prove startup/private state/egress through the owner path Glas uses. Runtime work can proceed in parallel with identity/audit deployment.

Resolve the currently different project examples explicitly: the Glas real acceptance runner uses actor agt/project glas-local-proof; the owner delivery documentation example uses project glas-harness. Return the reviewed binding and adapt the fixture/config together; do not broaden the route to all projects.

Return: profile id/revision, host scope, runtime digest/executable paths, exact consumer tuple, declared egress and denial/cleanup evidence. GLAS-WP-0012 then reviews version 1.1.0, executes its real artifact proof and promotes only the proven candidate. Provider workspace scope and spend limit remain operator inputs; model budget_tokens does not establish a provider spend limit.

Repository access for owner sessions

Primary owner workspaces: key-cape, railiance-platform, audit-core, approval-engine, secrets-engine, flex-auth and sand-boxer. Give each owner read access to glas-harness for this packet and the acceptance contract. Sand-boxer also needs rein-aharness as a sibling for runtime packaging/startup. KeyCape/custody/audit preparation and approval-image/runtime preparation can proceed in parallel; final native activation follows the verified prerequisites.

Owner returns reviewed — 2026-09-06

Six acknowledgements received: key-cape, audit-core, approval-engine, secrets-engine, flex-auth and sand-boxer. railiance-platform has not returned a reply in this review. See GLAS-WP-0015 for the receipt summary.

• v1 lacked tenant enforcement; v2 is now live with wrong_tenant denial.
• Tenant choice is now accepted as exact tenant:platform; owner alignment and verification remain outstanding (see platform-tenant-decision.md).
• Workstation caller access remains open even though FLEX-WP-0021-T05 was marked done; service coordinates are insufficient for the actual consumer.
• AUDIT-WP-0009-T03 must precede T09 so load-bearing evidence is represented.
• sand-boxer 23d0c2b resolves the exact project as glas-local-proof; its profile.claude-agent-dev-proof v1.1.0 is a source candidate, not a deployed combined runtime. Claude executable pin/startup remains outstanding.

Verified owner returns and deployment progress — 2026-09-06, later review

• KeyCape 7a6666d and approval-engine 6d18f62 implement the exact approved tenant in source; live registration/custody remains open.
• secrets-engine 80eafaf/b9058c9 includes the formerly absent lifecycle request tenant and accepts policy v2 only. Its OpenBao login client retains the separate tenant:coulomb identity; the approved decision does not change it.
• Audit-core 15e5436 completes evidence-kind T03 and prepares T09. Exact tenant:platform scope and redact policy confirmation requested from the approval owner; wildcard is not assumed. Freshness T02 and suppression detection T04/T06 bound evidence claims rather than blocking admission.
• Approval-engine d7a9fe5's scanned Alpine candidate was published as 0.1.0. Remote registry index digest sha256:73333f5ceb55e48192e3095cb2e2a741cdc6ff0be2f18128301072b4a6b6eb9d now pins both manifest image references. No service rollout before identity and audit prerequisites.
• Five follow-ups delivered in production-owner-review-followups-2026-09-06.json. Platform custody acknowledgement and the Claude executable pin remain open.