secrets-engine/docs/glas-claude-delivery.md

# Glas Claude exec delivery

Proposed native lane `glas-claude-agent-dev-anthropic`, provenance
railiance-platform CCR-2026-0016; implementation/activation record SECRETS-WP-0009.
KV custody is already confirmed at version 2. Do not provision or rotate it as
part of native read-lane adoption.

2026-09-10: the factory continuation uses a metered MessagesOwner outside the
sandbox. Its exact runtime is installed and synthetically proved on Railiance.
The catalog now blocks exec with an explicit pending recipient binding until the
native holder and immutable configuration are admitted. See
[exec owner binding](exec-owner-binding.md). The older transport description
below records the original child-key route; it cannot admit the metered holder.

The generated plan checks existing mount `platform`, creates policy and AppRole
`se-prod-glas-claude-agent-dev-anthropic`, and grants read only on
`platform/data/workloads/glas-harness/claude-agent-dev`. Field ANTHROPIC_API_KEY
is selected by the exec adapter; KV policies scope entries, not fields.
`delivery_auth.metadata_read: false` excludes the metadata endpoint; existing
lanes retain their previous metadata access by default. Token TTL 5m, maximum
15m, SecretID TTL 5m and single use, token use budget 8. No wildcard, listing,
workload writes, mount mutation, provider creation or default-policy change is
included in this plan. Verify effective token identity policies at activation.

Sand-boxer's owner-configured credential route binds profile, project, actor and
nonempty run id before invoking secrets-engine's exec-env interface. The
provider injects the key into a private host helper that directly forwards it to
the namespace broker. The broker injects only ANTHROPIC_API_KEY into the command
and redacts exact values before truncating output. No OpenBao token crosses
into the sandbox; no key is returned through Glas's API. Values are available
to the trusted workload and descendants; encoding/exfiltration by hostile
workload code is not prevented by an output redactor. Existing sandbox, egress,
artifact verification and profile admission boundaries remain required.

A synthetic provider proves the transport only. It does not stand in for native
approval, OpenBao access, provider authentication or production readiness.

## Activation requirements

As of 2026-09-27, the shared approval/consume/PDP chain has live evidence from
SECRETS-WP-0010-T03. The Glas catalog still has a pending owner binding and
refuses exec before approval consumption or backend access. The earlier lack
of a served decision path is no longer the current activation blocker.

The metered owner configuration and binding were prepared on 2026-09-23.
Activity Core reports ACTIVITY-WP-0039 complete on 2026-09-24: custody and the
separate `rein-aharness-metered@railiance01` identity are live. See the exact
handoff in SECRETS-WP-0011. Its worker token is companion-only; direct exec of
`activity-core-metered-worker-token` is refused. The intended recipient is the
metered MessagesOwner described in [exec owner binding](exec-owner-binding.md),
not the historical sandbox helper above.

SECRETS-WP-0009-T03 still owns current recipient/pin admission and the attended
activation. Review the draft binding, revalidate installed files and private
state, configure the approved owner, and obtain exact per-action/per-lane
approvals. Apply the scoped policy/AppRole, verify positive read and denied
metadata/sibling/write access with an unrelated negative identity, then prove
bounded owner delivery and session revocation. Both lanes must independently
pass approval, PDP, consume and delivery readiness. The handoff and draft are
not runtime authorization. No production activation was performed in this review.

Rotation: store replacement with CAS, stop old runs, verify replacement, revoke
predecessor at Anthropic and prove denial. Bao session expiration does not revoke
the provider key. Compromise disables the provider key and affected runs first.