coulomb/secrets-engine
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Bind native OpenRouter approval to custody and delivery inputs
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 5s
Details

Browse source 
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a09cbb-87c6-7900-a145-4ce53ba9f1a6
This commit is contained in:
tegwick 2026-09-14 00:54:55 +02:00
parent 0783b50216
commit 7ba1b6223e
16 changed files with 656 additions and 7 deletions
Download patch file Download diff file Expand all files Collapse all files

82
docs/openrouter-native-access.md Normal file
View file

@ -0,0 +1,82 @@
# 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 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.