secrets-engine/docs/openrouter-native-access.md

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