# PROPOSED reviewed-input template; not active catalog or credential admission.
# SECRETS-WP-0010; retain the existing KV and AppRole names.
id: openrouter-llm-connect
kind: kv
org: coulomb
repo: llm-connect
stage: prod
description: >-
  OpenRouter provider credential used by llm-connect for activity-core. The
  proposed native recipient checks key authentication only; trial delivery
  requires a separate reviewed recipient and exact-action approval.

mount: platform
path: workloads/activity-core/llm-connect/llm-connect-provider-secrets
mount_management: existing
fields:
  - OPENROUTER_API_KEY

consumers:
  - name: llm-connect-activity-core
    auth: kubernetes
    claim: serviceaccount:external-secrets/external-secrets
    purpose: sync llm-connect-provider-secrets for the activity-core deployment
  - name: intelligence-radar-key-check
    auth: approle
    claim: catalog:openrouter-llm-connect
    purpose: IR-WP-0004 read-only OpenRouter key authentication check; no inference

workload_delivery:
  - mode: external-secrets
    owner: railiance-platform + llm-connect

delivery_modes: [exec-env, read-check]
delivery_auth:
  method: approle
  management: engine
  policy_name: se-prod-openrouter-llm-connect
  role_name: se-prod-openrouter-llm-connect
  token_ttl: 15m
  token_max_ttl: 30m
  secret_id_ttl: 15m
  secret_id_num_uses: 1
  token_num_uses: 8

approval:
  model: ccr
  human_control: true
  purpose: IR-WP-0004 read-only OpenRouter key authentication check; no inference
  decision_ref: CCR-2026-0003
  notes: >-
    CCR-2026-0003 approves the existing workload lane. A live native AppRole
    apply remains gated by SECRETS-WP-0006-T05 review and operator approval.
    First native-cutover candidate (docs/native-lane-cutover.md); not an
    authorization to apply.

verification:
  positive: approved delivery AppRole can read OPENROUTER_API_KEY without printing it
  negative: unrelated token is denied on platform/data/workloads/activity-core/llm-connect/llm-connect-provider-secrets

risk:
  classification: high
  notes: provider key can incur spend and remains valid outside OpenBao until revoked at OpenRouter

rotation:
  owner: railiance-platform + llm-connect provider operator
  expectation: >-
    Mint a replacement at OpenRouter, update every live cluster copy, wait for
    ESO refresh, restart llm-connect, verify, and revoke the old provider key.
  ttl: provider-defined

deactivation:
  owner: railiance-platform + llm-connect
  expectation: >-
    Disable the front door and workload read path, remove materialized Secrets,
    stop consumers, and revoke the provider key at OpenRouter.

audit:
  evidence: CCR id, actor, exact path, field name, provider key identifier if non-secret, timestamps, and pass/fail only

delivery_config:
  exec_owner:
    status: pending
    owner: intelligence-radar-key-check
    reason: >-
      Pin tools/openrouter_key_check.py and its protected Python runtime, exact
      argv, private cwd and fixed environment after custody-owner admission.
      The pending binding refuses exec before consume or secret retrieval.