---
id: SECRETS-WP-0009
type: workplan
title: "Activate native Claude credential delivery for Glas"
domain: infotech
repo: secrets-engine
status: blocked
owner: codex
created: "2026-09-05"
updated: "2026-09-05"
state_hub_workstream_id: "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

```task
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

```task
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

```task
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.