secrets-engine/docs/openrouter-native-access.md
tegwick 7ba1b6223e
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 5s
Bind native OpenRouter approval to custody and delivery inputs
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a09cbb-87c6-7900-a145-4ce53ba9f1a6
2026-09-14 00:54:55 +02:00

5.2 KiB

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 a pending 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 and pending exec refuses before consume/backend. 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. Complete APPROVAL-WP-0002-T01/T03/T05 and its identity/audit dependencies; its declared namespace currently has no StatefulSet, pod or Service. 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. Install and pin its Python runtime and script, exact argv, private working directory and fixed environment via 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.