tegwick
7c5e644d6f
- DecisionQueue: moved to resolved log with rescoped outcome (three-layer model; binky-control = tenant #1); hub decision resolved - Secret lanes doc: identifiers renamed executor-worker → agent-harness before any provisioning happens - Cutover runbook + WP-0004-T06: gate 1 done; deployment gate now points at HARNESS-WP-0001-T06/T07 in the agent-harness repo Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
86 lines
4.1 KiB
Markdown
86 lines
4.1 KiB
Markdown
# Agent Harness — OpenBao Secret Lanes (BINKY-WP-0004-T03)
|
||
|
||
> Status: prepared 2026-07-17. Catalog metadata and provisioning steps only —
|
||
> **no secret values appear here or anywhere in git/hub/chat**. All new
|
||
> provisioning is founder Red lane per AutonomyPolicy.md.
|
||
|
||
The agent harness (DEC-2026-002 resolved: single shared runtime repo `agent-harness`, deployed on Railiance)
|
||
needs three credential lanes. One exists and is reusable; two need
|
||
provisioning.
|
||
|
||
## Lane 1 — LLM provider key: REUSE (verified)
|
||
|
||
Warden catalog `openrouter-llm-connect` (active, resolvable, reviewed
|
||
2026-07-02):
|
||
|
||
- Path: `platform/workloads/activity-core/llm-connect/llm-connect-provider-secrets`
|
||
- Field: `OPENROUTER_API_KEY`
|
||
- Auth: any token carrying policy `workload-kv-read-llm-connect-provider-secrets`
|
||
- Policy gate: `flex-auth check secret.read:llm-connect` (advisory today)
|
||
|
||
**Verdict: reuse.** The key is scoped to "llm-connect in activity-core"; the
|
||
agent harness is the consumer that scoping anticipated (it executes tasks
|
||
activity-core emits, via llm-connect adapters). No new secret needed. If the
|
||
worker later gets its own workload identity, bind that identity to the same
|
||
policy — same secret, separate auth principal — rather than duplicating the
|
||
key.
|
||
|
||
## Lane 2 — Forgejo deploy key: NEW (Red lane)
|
||
|
||
No warden catalog entry exists (checked 2026-07-17; nearest match falls
|
||
through to `key-cape-oidc-login`). The worker must push commits to target
|
||
repos on forgejo (railiance01:30022), starting with a sandbox repo (T04),
|
||
later binky-control (T06).
|
||
|
||
Proposed provisioning (founder Red lane, ~10 min):
|
||
|
||
1. Generate an ed25519 keypair on Railiance (worker host), private key never
|
||
leaves the host; store a copy under OpenBao
|
||
`platform/workloads/agent-harness/forgejo-deploy-key`
|
||
(fields: `SSH_PRIVATE_KEY`, `SSH_PUBLIC_KEY`).
|
||
2. In forgejo, add the public key as a **per-repo deploy key with write
|
||
access** — sandbox repo only at first; add binky-control at T06 cutover.
|
||
Per-repo deploy keys beat a machine-user account here: blast radius is
|
||
exactly the repo list.
|
||
3. New OpenBao policy `workload-kv-read-agent-harness-forgejo` scoped to
|
||
that path; warden catalog entry `agent-harness-forgejo-deploy` (owner:
|
||
railiance-platform, risk: high).
|
||
|
||
## Lane 3 — Non-interactive AppRole for company-email scan: NEW (Red lane)
|
||
|
||
Blocker being closed: the existing OIDC role
|
||
`binky-company-email-imap-workload-kv-read` is browser-interactive with a
|
||
15-minute TTL — unusable for recurring scans (email-integration checklist
|
||
item 9, `integrations/company-email-openbao.md`).
|
||
|
||
Proposed provisioning (founder Red lane, ~10 min):
|
||
|
||
1. Enable/confirm AppRole auth on the OpenBao instance (`bao auth list`;
|
||
enable at path `approle` if absent).
|
||
2. Create role `agent-harness-binky-mail` bound to the **existing** policy
|
||
`workload-kv-read-binky-company-email-imap` (no policy change needed):
|
||
`token_ttl=15m`, `token_max_ttl=30m`, `secret_id_ttl=0` (or rotate
|
||
quarterly), `token_num_uses` bounded.
|
||
3. Deliver `role_id` + `secret_id` to the worker host via the
|
||
secrets-engine delivery mechanism (files `0600` on Railiance, outside any
|
||
repo). The worker logs in per run:
|
||
`bao write auth/approle/login role_id=… secret_id=…` → short-lived token
|
||
→ `bao kv get -field=IMAP_USERNAME|IMAP_PASSWORD tenants/binky/company-email/imap`.
|
||
4. Warden catalog entry `agent-harness-binky-mail-approle` (owner:
|
||
railiance-platform, risk: high) so the lane is discoverable and audited.
|
||
|
||
Scan invocation stays exactly the manual pattern (read-only email-connect,
|
||
values only ever in process env):
|
||
config `integrations/mailbox-binky-company.yml`, reports to
|
||
`mailmeta/reports/`.
|
||
|
||
## Founder Red-lane summary
|
||
|
||
- [ ] Lane 2: forgejo deploy key (generate, register on sandbox repo, store
|
||
in OpenBao, catalog entry)
|
||
- [ ] Lane 3: AppRole `agent-harness-binky-mail` (create role, deliver
|
||
role_id/secret_id to Railiance, catalog entry)
|
||
- [x] Lane 1: nothing to do — reuse confirmed
|
||
|
||
T04 (worker MVP) can start with Lane 1 alone plus a workstation-side dry
|
||
run; Lanes 2–3 gate unattended operation, not development.
|