railiance-platform/docs/evidence/agent-high-risk-boundary-2026-08-21.md

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.