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

---
id: SECRETS-WP-0009
type: workplan
title: "Activate native Claude credential delivery for Glas"
domain: infotech
repo: secrets-engine
status: blocked
flavor: implementation
owner: codex
created: "2026-09-05"
updated: "2026-09-21"
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
blocking_reason: "Shared native chain proved by SECRETS-WP-0010-T03 (2026-09-16): Approval Engine, CCR-2026-0019 reader, requester client, Informed Decision human review, current PDP. Lane-specific residue: operator inputs (placement, spend envelope/model bounds, unrelated negative identity), private SpendPolicy/ledger and owner config (HFACT-WP-0001-T01/T04), configured exec_owner, three human approvals, attended apply/verify/exec/revoke."
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.

Digest join corrected 2026-09-07. The live proof from 2026-09-06 (commit
`03c0569`) showed `validate_decision_envelope` rejecting every real allow. The
cause and the fix are both now settled, and the fix follows a published rule
rather than an inferred one.

- **Cause.** The evaluator normalizes before hashing: the request tenant is
  copied onto `subject` and `resource`, and a registry hit copies `type`,
  `tenant` and selected `attributes` onto the refs. `binding.request_digest` is
  therefore over material we never sent and cannot reproduce, so byte-equality
  against our unenriched request is unsatisfiable, not merely mismatched.
- **The rule was already published.** flex-auth's `canonical-request-digest.md`
  section "Normalization" states it, and instructs consumers to compare
  structured `binding` fields to the proposed action and treat `request_digest`
  as the evaluator's statement of what it hashed, recomputing independently over
  the tuple the binding carries. Correction to the previous note: this repo
  raised it with flex-auth as an unpublished gap and asked them to choose
  between three shapes. It was already in their contract, and the answer was the
  first of the three. Nothing was blocked on them.
- **Implemented.** `_require_binding_corresponds` enforces that everything we
  proposed survives unchanged — tenant, action, context, `subject.id`/`type`,
  `resource.id`/`type`/`system`, and every attribute we sent. Enrichment may add
  only `type`, `tenant`, `attributes`; any other added field is refused, and an
  enriched tenant must be the request tenant so a cross-tenant binding cannot
  arrive wearing our request's clothes. `request_digest` is still checked, now
  against `binding_tuple(binding)` for self-consistency.
- **Proved against the artifact.** `tests/test_live_decision_enrichment.py`
  validates the real `decision:0f9c98f14545c42d` under the corrected rule, and
  separately asserts the unrefreshed envelope is refused on lifetime — reaching
  the lifetime check at all is the evidence every binding check now passes on a
  real decision. Negative tests cover a restated `resource.attributes.stage`, a
  foreign `subject.tenant`, and an unexpected enrichment field.
- **Why the fixtures could not catch it.** `_request_from()` rebuilds the
  request out of the binding, i.e. the already-enriched form, so every digest
  assertion hashed the evaluator's output and compared it to the evaluator's
  output. The defect survived the excluded-fields fix, the
  `approval_binding_digest` fix and the tenant fix because all three were tested
  that way. Only a real request through the owner access path exposed it.

Remaining before activation is now one external dependency, not two:
approval-engine must serve the claim endpoint so protocol step 1 can run and
`GH-DEC-2026-003` consume-before-OpenBao can be satisfied. The decision path
itself is proved end to end against the deployed pin.

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.


### 2026-09-09 consumer identity implementation and component proof

The "one external dependency" statement above concealed another local seam:
claim and consume could only read a manually supplied bearer-token file. The
OpenBao service-JWT provider cannot be reused with approval credentials because
its audience, tenant and scope are different.

Implemented the separate secrets-engine-approval provider and wired it into
both actual claim/consume call sites. It requests only read or consume for the
current request, keeps the token in memory, rejects mixed providers, and never
falls back on exchange failure. The exact service:secrets-engine / approval-engine /
tenant:platform identity and scope/time bounds are preflighted. Credential-bearing
redirects and unsupported approval endpoint shapes are refused.

The pinned real KeyCape image exposed a second defect: the shared consumer
expected assurance.aal/method but the issuer emits assurance.level/methods.
Corrected to the issuer's actual source contract, with regression coverage.
The real Approval Engine JWT verifier and SQLite store then accepted the actual
consumer's claim/check/consume chain in a disposable component exercise. Wrong
action/secret, spent claim, different digest and operator consume scope are
refused; same-digest consume retries are idempotent. Only the PDP was a test
double. The suite passed 350 tests; no production credential was read.

Contract and repeatable exercise: docs/approval-service-auth.md; receipt:
docs/evidence/2026-09-09-approval-identity-exercise.json.

T03 remains wait for RPF-WP-0035-T06's separately admitted client-side reader,
AUDIT-WP-0009-T09 audit custody, APPROVAL-WP-0002 live endpoint/claim/consume,
and the existing exact native OpenBao authority/delivery returns. The synthetic
proof does not grant these. KEY-WP-0013-T02 and verifier CCR-2026-0017/0018
are complete and must not be requested again. No new workplan duplicates T03.

Owner-return clarification: SECRETS-WP-0008-T02 is now progress for the published
FLEX-DEC-2026-012 submitted-request replay identity and approval-digest join.
The real-component identity exercise used a PDP double and does not close that
local implementation. T03 also consumes that correction before live activation.


## Replay-contract return — 2026-09-09

SECRETS-WP-0008-T02 supplies the implemented FLEX-DEC-2026-012 consumer join.
334 tests and 13 real local KeyCape/Approval Engine/Flex Auth checks pass;
receipt: docs/evidence/2026-09-09-replay-contract-exercise.json. The former PDP
double limitation is resolved for component conformance. T03 remains wait for
current deployed PDP adoption, separately admitted client-side/audit custody,
actual Approval Engine deployment, and the scoped native OpenBao delivery proof.


### 2026-09-10 exact recipient enforcement

The factory runtime is now installed on workstation and Railiance at digest
`5371156d2027dde6e8f140cc0a1833c4e90b8c75b3bec862e05f06a957f5fd34`;
consume project evidence `2026-09-10-runtime-placement.json`. Native delivery
review exposed an unclosed local boundary: exec accepted any argv and inherited
all parent environment after catalog/action approval.

Implemented optional catalog exec_owner with exact command, private cwd, fixed
non-secret environment and file pins. The factory catalog is explicitly pending
and refuses before approval/backend. The complete binding digest travels in the
existing CheckRequest context and producer/approval join. Changes before or during
retrieval refuse launch; the actual child has closed stdin and receives no inherited
engine auth environment. Existing action/consume/state/backend gates remain.

361 tests passed. The extended disposable actual KeyCape/Approval Engine/Flex Auth
exercise passed all 18 checks, including changed-recipient replay refusal and
consume-before-synthetic-backend followed by actual child execution. Receipt:
`docs/evidence/2026-09-10-exec-owner-approval-exercise.json`; contract:
`docs/exec-owner-binding.md`. Synthetic backend/key/recipient and test operator
identity only; no native secret read, human approval or paid execution.

T03 remains wait for configured/pinned owner inputs and holder admission, wanted
CCR-2026-0019 operator-group/file-delivery return, INFD-WP-0001-T07/T08 real human
approval, audit custody and deployed services/PDP/native delivery. CCR-2026-0020
was cancelled on owner withdrawal; do not wait for or recreate its presenter.
No runtime artifact rebuild is needed for this credential-engine change.

### 2026-09-10 workstation procedure return

`docs/approval-service-auth.md` now gives the concrete CCR-2026-0019 consumer
procedure requested by Platform: an operator-owned 0700 runtime session directory
outside Git, a new 0600 file, path-only CLI configuration, claim/consume lifetime,
EXIT/INT/TERM cleanup and explicit residual-file handling after hard interruption.
The source review distinguishes implemented permission/location/empty-file checks
from operator-owned creation, parent custody and cleanup. No automatic cleanup
or live reader proof is claimed. The exact group remains NetKingdom/KeyCape's
return, followed by reviewed attended admission and positive/negative evidence.
T03 stays wait; no identity, role, secret, runtime or route readiness changed.

### 2026-09-10 declared human-control consumer return

Consumed APPROVAL-WP-0002's GH-DEC-2026-016 implementation and schema-v5 release.
The existing human action-review requirement is explicit on the factory catalog:
`approval.human_control: true`. The CheckRequest carries that intent in its bound
context; the consumer requires exact true in the served claim before PDP and
again afterward. The internal consume binding carries the observed declaration.
Missing service coordinates, ordinary lane approval, stage and unsafe-demo paths
cannot substitute for the declared control. Undeclared lanes retain their behavior.
The catalog's exec owner stays pending; no policy, role or credential was changed.

Validation: 388 tests pass, including 27 new strict-type, missing/false claim,
request binding, post-PDP recheck, fallback and actual exec-handler cases.
The real local KeyCape/Approval Engine/Flex Auth exercise passes 22 checks.
The request API declares true; KeyCape service binding is refused; an undeclared
claim reaches no PDP/consume/backend; declared positive delivery consumes before
the synthetic backend/child. Positive human evidence is an explicit store fixture,
not a native human JWT or browser login. Evidence and repeatable command:
`docs/evidence/2026-09-10-human-control-consumer-exercise.json`,
`tools/exercise_approval_identity.py --exec-owner --human-control`.

This closes consumer source adoption. T03 still requires the narrow native
requester, INFD T07/T08 functional browser and human approval, audit custody,
CCR-2026-0019 operator binding/attended read, current deployed service/PDP and
configured MessagesOwner/native delivery. HFACT T01/T04/T05 retains factory
config/G0 and natural queue/model proof. No native secret read or paid attempt.

### 2026-09-21 activation preparation

SECRETS-WP-0010-T03 completed native OpenRouter delivery on 2026-09-16 over the
same shared chain: Approval Engine deployed, CCR-2026-0019 reader bound to
`net-kingdom-admins`, `secrets-engine-requester` admitted, Informed Decision
human review live with a real human approval, current PDP. Those items are no
longer T03 blockers. The operator offered the attended session.

Lane-specific residue, in order:

1. Operator inputs: placement (workstation or Railiance runtime copy from
   `prj-helixforge-factory/evidence/2026-09-10-runtime-placement.json`), spend
   envelope for one bounded run (`rein-aharness/docs/spend-admission.md` fields:
   per-run/daily/total EUR, max budget/liability USD, FX, expiry), MessagesOwner
   model and token bounds, and a real unrelated identity for negative verification.
2. Private SpendPolicy + ledger `spend init` and mode-0600 owner config
   (`rein-aharness/docs/owner-bootstrap.md`) at the chosen placement
   (HFACT-WP-0001-T01/T04). Their digests become `exec_owner.files` pins.
3. Configure `exec_owner` (argv `<runtime>/bin/python3 -I -B -m rein_aharness.cli
   metered-once --owner-config <private-owner-config>`), render final
   apply/verify/exec requests with evaluator-origin digests.
4. Attended: three human approvals, scoped Warden session, claim/Check/consume
   then apply, positive/negative verify, one bounded exec, session revoke,
   evidence returned to GLAS-WP-0012 / SAND-WP-0015.

Circular wait noted: HFACT-WP-0001-T04 waits on this task's admission while this
task waits on the owner config; the operator inputs in step 1 break it.
No credential read, no approval created, no policy or role changed.

### 2026-09-21 operator inputs

Received from the operator (Bernd), recorded here as inputs, not authorization:

- Placement: railiance01 runtime copy (`5371156d…`).
- Spend envelope: per_run_eur 5, daily_eur 20, total_eur 500; per-run
  max_liability_usd 5.75 and max_budget_usd 5.00 (derived from EUR 5 at the stated
  FX); eur_per_usd from 1 EUR = 1.15 USD; expires 2027-01-31. The operator's
  USD 600/800 figures are overall caps and are dominated by total_eur 500 (= USD 575).
- EUR 100/month: recorded as an operator-reviewed limit, not enforced; SpendPolicy
  has no monthly ceiling. Follow-up for rein-aharness to add `monthly_eur`.
- authority_ref: no CCR exists; the operator wants a budget decision in the
  Informed Decision framework. That record becomes `authority_ref`.
- Model: keep this Anthropic lane with a Claude default for MessagesOwner.
  Separately, the llm-connect default moves to DeepSeek V4.1 Flash (llm-connect
  change, not this task).
- Negative identity: the operator delegated this. Plan: use the existing
  CCR-2026-0019 approval-client reader token from the attended Warden session
  (real, reviewed, scoped only to its own KV path) written to a 0600 tmpfs file.
  No new identity or authority is minted.

### 2026-09-21 spend authority accepted (step A)

The operator accepted Informed Decision memo `infd-20260921-b01` at 19:51:29 UTC
under fresh AAL2 MFA, after acknowledging that the EUR 100 monthly limit is not
enforced. Approval Engine approval `ba5ce2d8-8b6d-40be-af89-2e8c147029a3`
(binding `sha256:e9eaf454…`) carries the confirmed human entry. It is the
SpendPolicy `authority_ref` for envelope `hfact-glas-anthropic-2026-09`.
Enforced values: per_run_eur 5, daily_eur 20, total_eur 500, eur_per_usd 0.87,
max_liability_usd 5.74, max_budget_usd 5.00, expires 2027-01-31T23:59:59+01:00.

Path: flex-auth compact-sitting v2 (`4f66c4d`/`882b381`, image `d77378e1…`,
package `sha256:24a52478…`); informed-decision `c8c60eb`..`4065450` (memo,
parametrized create/attach tools, WSL2 clock-skew fix, review cutover inputs).
Receipt: informed-decision `docs/evidence/2026-09-21-budget-sitting-accept.json`.
This approval authorizes spend only; it is not the apply/verify/exec approval.
Next: step B, SpendPolicy scope fields from the admitted factory profile.