# OpenRouter native preparation — 2026-09-14

SECRETS-WP-0010 implements the bounded owner packet from IR-WP-0004,
message `cfab5355-b0f9-4868-b4e6-61ea42c54b0f`.

## Implemented

Every action request now includes a deep copy of the non-secret catalog target
in `context.catalog_target`: custody mount/path, owning org/repo, declared fields,
consumers, mount management, delivery modes/config/auth and workload delivery.
The existing action, stage, purpose and human-control fields remain bound.
Approval object identifiers are excluded so issuance does not change its own
approval-free digest. Changed targets or token limits require a new approval;
existing approvals created before this change cannot authorize new submissions.
This binds proposed inputs; it does not turn catalog metadata into a grant.

Plans now expose all AppRole limits, including the secret-ID TTL and use count.
The OpenRouter plan checks the existing mount and writes only the exact-path
policy and AppRole `se-prod-openrouter-llm-connect`. Limits: token TTL 15m, maximum
30m, secret-ID TTL 15m/single use, eight token uses. No KV mutation or ESO change.
See the non-secret plan and claim-free request under `docs/evidence/2026-09-14-*`.
Those are review inputs, not issued approvals; regenerate after configuring the
actual recipient because its target binding changes.

`tools/openrouter_key_check.py` is the first proposed recipient. It performs one
TLS-verified GET to the fixed endpoint, ignores proxy configuration, follows no
redirects and makes no inference request. It emits only a fixed result and HTTP
status; no provider fields, labels, response bodies, key values or exception text.
The endpoint is OpenRouter's documented
[current-key information API](https://openrouter.ai/docs/api/api-reference/api-keys/get-current-key).
A successful check does not reconcile radar's existing spend reservation.

`docs/proposals/openrouter-key-check.yaml` is an inactive proposed catalog overlay.
It retains the existing lane id/KV/policy/AppRole and ESO consumer, declares human
control, and names the key-check recipient with an installed, configured exec-owner binding.
The active `catalog/openrouter-llm-connect.yaml` remains limited to its admitted
llm-connect purpose. The proposal is outside the active catalog; configuration is not approval.
Its exact interpreter/script paths and pins are recorded in the install receipt. Do not copy it into the active catalog until
custody-owner admission and the exact protected recipient installation are reviewed.

## Verification

410 tests passed, including disposable OpenBao coverage. New tests cover changed
path, mount, owner, consumer, limits, fields and delivery mode replay; frozen
request inputs; complete plan limits; and sanitized key-check success/errors,
redirect refusal, malformed/oversized responses and transport cleanup.
The actual local KeyCape + Approval Engine + compiled Flex Auth exercise passed
26 checks, including changed catalog target refusal before consume/backend and
exact child isolation. Its human approval and backend are explicit synthetic
fixtures, not native production evidence.

Flex Auth's dedicated native pin was promoted to Helm revision 4 with the existing
published image `sha256:05a03a8790c2210c48ea92391441c77ddf640d0cd32f5ec09838f5393171fcbd`.
Eleven live evaluation checks passed, including current replay/approval binding;
other PDP deployment specs are unchanged. The separate local and live receipts
state their scope and cleanup. This removes the outdated PDP image dependency.

## Remaining admitted execution sequence (SECRETS-WP-0010-T03)

1. APPROVAL-WP-0002-T03 is now deployed, with existing audit custody and current
   JWKS verified (2026-09-14 deployment receipt). T01/T05 still require the
   admitted requesting/human/consumer path. Complete
   RPF-WP-0035-T06 / CCR-2026-0019 client-side reader admission for the secrets-engine
   approval-client. Keep secrets outside Git and use the existing attended
   procedure in `docs/approval-service-auth.md`; do not read the verifier's Secret.
2. Have the custody owner admit this exact read-only recipient. The configured local installation already pins
   its Python executable and script, exact argv, private working directory and fixed
   environment; review the installation receipt against `docs/exec-owner-binding.md`. Obtain the scoped attended
   platform authority; no standing bootstrap credential or sibling identity.
3. Render the finalized request, use the evaluator-origin digest to create a
   declared-human-control approval, obtain the real human entry, observe claim,
   validate Check and CAS-consume before apply. `ActionAuthorization` is deferred,
   not a missing API to implement. CCR-2026-0003 is provenance, not this approval.
4. Apply only the reviewed policy/AppRole. Verify correct-reader access, unrelated
   identity and unrelated path denials, all fields, role limits, native session
   revocation and llm-connect ESO/application health. No raw provider value in
   evidence. Obtain a separate exact exec approval for the pinned key check.
5. Only after verified native readiness should SECRETS-WP-0006-T06 retire the
   interim route. Rollback removes only the new policy/AppRole; preserve KV/ESO.
6. Trial delivery requires its own reviewed, pinned radar recipient/config and
   approval. Reconcile the existing USD 0.023712 reservation in campaign
   `ir-openrouter-pilot-20260913`; preserve the authorized USD 10 ceiling. This
   task did not execute the key check or spend campaign funds.


The finalized request artifacts are `docs/evidence/2026-09-14-openrouter-final-*-request.json`.
They replace the earlier pending-recipient proposal as review inputs, not as an
issued approval. Recipient proof is in `2026-09-14-openrouter-recipient-install.json`.
The exact operator-group question is pending user input. Native requesting
identity (`approval:create`) and Informed Decision human review are also needed;
do not reuse the withdrawn combined operator client or seed a production approval.