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](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](platform-tenant-decision.md). 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.