secrets-engine/workplans/SECRETS-WP-0009-glas-claude-native-delivery.md

id	type	title	domain	repo	status	owner	created	updated	state_hub_workstream_id
SECRETS-WP-0009	workplan	Activate native Claude credential delivery for Glas	infotech	secrets-engine	blocked	codex	2026-09-05	2026-09-05	40ccc3b4-d046-5a58-8649-e7935f45c974

Demand: GLAS-WP-0012-T02 / SAND-WP-0015-T04, custody CCR-2026-0016. The user authorized continuing credential delivery after storing the key in Bao. This record tracks native read-lane adoption, not a new provider key or rotation.

Define the exact native read lane

id: SECRETS-WP-0009-T01
status: done
priority: high
state_hub_task_id: "4f1cf242-3aec-56a8-b958-5d53823875e0"

Added catalog glas-claude-agent-dev-anthropic; plan checks existing platform mount and proposes one data-only read policy/AppRole. Token TTL5m/max15m, single-use SecretID5m, token use budget8. See docs/glas-claude-delivery.md. No metadata, sibling, listing or write capability is proposed.

Support data-only delivery policies

id: SECRETS-WP-0009-T02
status: done
priority: high
state_hub_task_id: "fa4a3e87-0854-5e2b-af44-facd5b25f443"

Added boolean delivery_auth.metadata_read with compatible default true and explicit false for this lane. Validation refuses non-booleans; generated plan omits metadata permissions when disabled. Full owner suite passes. Sand-boxer synthetic exec-env transport proof passed; no real secret was read.

Activate the approved native lane and verify real owner delivery

id: SECRETS-WP-0009-T03
status: wait
priority: high
state_hub_task_id: "f8069c8a-ad6b-5d0b-9a36-c2326699437d"

Inbound 2026-09-06 (glas-harness GLAS-WP-0015 production dependency handoff). Ownership acknowledged. Answering their tenant question rather than assuming the values lined up found a blocking defect in this repo, so the handoff earned its keep before any activation work started.

• Our CheckRequest carried no tenant at all. The deployed secrets-engine.catalog-lane.lifecycle v2 package reads request_tenant := object.get(input, "tenant", "") against known_tenant := "tenant:platform", so an absent tenant is a wrong_tenant denial rather than an ignored field. Every gated action this engine sent would have been denied, and the omission also produced a request_digest matching no correctly issued decision, because tenant is hashed material. Fixed in 80eafaf; REQUEST_TENANT is pinned against the vendored allow envelopes.
• The package is v2, not the v1 glas reported. v1 had no tenant rule and failed open — a rotate under tenant:coulomb returned allow against the deployed package (decision:066e629bbf0c0924). flex-auth superseded rather than amended it, because a fail-open correction must be visible as a version change. Our accepted version moved to v2 and a test refuses a v1 decision.
• Wrong-tenant denial evidence delivered, from flex-auth's real deny envelope rather than asserted: decision:7d56b7fc274ddfd6, matched_rule wrong_tenant, binding.tenant tenant:coulomb. Vendored with tests that we refuse it on effect first and that a deny legally carries no lifetime.
• Tenant mapping NOT resolved, deliberately. service_auth.TENANT is tenant:coulomb, which is exactly the value the package denies. Either those are two layers sharing a namespace format or one constant is wrong. Choosing without an owner ruling is the fail-open shape GH-DEC-2026-008 rejected for action vocabularies. Both constants stay as they are, not unified behind one symbol. Recorded in docs/tenant-alignment.md for KEY-WP-0013-T02 / APPROVAL-WP-0002-T01.
• Hazard found while probing the caller access path. Every *.svc.cluster.local name resolves on this workstation to one unrelated public address via the ad.binect.de search suffix, including names of services that do not exist. Pointing SECRETS_ENGINE_PDP_URL at the Service name would ship CheckRequest metadata and the Bearer token to that host, and decision envelopes are structurally validated but not signed, so a knowing responder could return a well-formed allow. Reported to flex-auth for FLEX-WP-0021-T05; not mitigated here because the transport control is the owners' call. The pin stays unset, so the hazard is theoretical today.

CCR-2026-0016 is explicitly treated as custody provenance, not a per-action authorization. No unsafe-demo switch and no human runtime token will be used to reach a prod lane. This task stays wait: activation is blocked on the owner access path, not on engine work or on approval shape.

Depends on SECRETS-WP-0007-T04 and SECRETS-WP-0008-T02/T06: canonical production authorization, successful consume and scoped service authority must exist. Current production exec refuses before OpenBao because durable access-engine decision records are not served. Do not bypass this with unsafe-demo or a human operator runtime token. Then apply the exact read policy/AppRole, prove positive and negative access, register delivery-ready evidence, bind owner exec with service authentication, and return verified pins/evidence to SAND-WP-0015 and GLAS-WP-0012. Provider scope/budget and expiry remain explicit acceptance inputs. Keep the catalog route inactive until real verification passes.