# Agent high-risk OpenBao boundary — 2026-08-21

## Scope

This is capabilities and metadata evidence for `RAILIANCE-WP-0022`. No
credential value was read, no token was minted, and no operator role was
modified.

## Source and live coverage

- State Hub message `828e4903-30fe-4903-acfd-cd2ecdda437d` reported that the
  live `agent-high-risk-boundary` lacked the Core Hub path and that six other
  concrete high-risk catalog paths were absent from both source and live.
- Source now denies KV-v2 data and permits metadata only for all concrete
  high-risk catalog paths. Pattern-only and non-KV lanes do not generate an
  invented address.
- Under attended `platform-admin` OIDC, OpenBao accepted the updated policy.
  A normalized readback matched the source file.
- The ops-warden audit used `policy_source: server` and reported 17 high-risk
  lanes: 12 covered catalog entries, zero uncovered, and five with no concrete
  KV address. The policy itself contains 12 unique deny paths because two
  catalog entries share the Binky IMAP path and Core Hub is an additional
  reviewed deny without a catalog lane.

### 2026-08-22 generated-input reconciliation

- Ops-warden delivered generated artifact revision
  `55f0f47a021375b8b25c924953d1b49a24e002c5`: 19 high-risk lanes, 14
  concrete entries (13 unique paths), and five pattern/non-KV lanes.
- The corrected grades add issue-core runtime (whose bundle also contains
  `GITEA_BACKEND_TOKEN`) and reuse-surface runtime (whose bundle also contains
  `REUSE_SURFACE_FORGEJO_WEBHOOK_SECRET`). Both data paths now have explicit
  deny blocks and read-only metadata blocks.
- `scripts/agent_high_risk_boundary.py` verified that the vendored input equals
  the clean upstream artifact aside from generation time and that every entry
  is covered. Forty-nine focused tests passed.
- Under attended `platform-admin` OIDC, the policy was uploaded and read back.
  OpenBao added only its normal trailing newline. The server-backed ops-warden
  audit reported 19 high-risk lanes, 14 covered, zero uncovered, and five with
  no concrete address.

## Attachment audit and residual blocker

A metadata-only scan listed and read role configuration under netkingdom OIDC,
Kubernetes auth, AppRole, and token roles. It found:

- roles attaching `agent-high-risk-boundary`: **0**;
- roles combining it with any `workload-kv-read-*` policy: **0**.

The 2026-08-21 scan accurately found no attachment at that time. On 2026-08-22,
State Hub decision `f0955252-7b20-4c80-86e9-f8080ec60793` selected the
platform-owned `coding-agent-railiance-platform` AppRole as the operational
machine identity while retaining the KeyCape JWT role as an issuer-backed
migration target.

Live AppRole metadata matched the reviewed source:

- `bind_secret_id=true`, `secret_id_ttl=300`, and
  `secret_id_num_uses=1`;
- `token_ttl=900`, `token_max_ttl=900`, `token_num_uses=8`, and no default
  policy;
- policies exactly `agent-high-risk-boundary` and
  `workload-kv-read-issue-core-runtime`.

The non-disclosing verifier minted one ephemeral SecretID, logged in, and used
only token metadata plus `sys/capabilities-self`. The data path resolved to
`deny`; its metadata path resolved to `read`; the token TTL was 900 seconds.
The first verification exposed that a no-default-policy token could not revoke
itself. That bounded test token was located and revoked by accessor under
attended authority, `auth/token/revoke-self:update` was added to the boundary,
and the repeat verification passed and self-revoked without warning. No KV read
was attempted and no SecretID, token, or protected value was printed or logged.

The exact-bound JWT role `auth/netkingdom/role/coding-agent` was also applied
with audience `codex-railiance-platform`, subject
`service:codex:railiance-platform`, `principal_type=service`,
`tenant=tenant:coulomb`, and role `coding-agent`. KeyCape client registration
is a future identity-hardening handoff; it is not required for the live AppRole
attachment proven here.