The agent responsible to create, change, maintain and tear down access routes with new credentials, tokens, policies, etc inside net-kingdom. Ops-mason is responsible to build the security infrastructure as required and defined by architecture documents as a base for ops-warden..
tegwick
f90644e8c0
Handing an agent an operator session gives it everything you have, for as long as you have it, and every action lands in the audit log as you. scripts/bao-session.sh grant <task> mints a separate token into ~/.claude-bao-token — your ~/.vault-token is untouched and the two revoke independently. 45 minutes, max one hour, display_name claude-<task> so an audited action is attributable to a piece of work. policies/ops-mason-build.hcl is what makes the scope real. It allows the phase-2 survey (sys/mounts, sys/auth, policy list), policy and auth-role creation, KV metadata reads, and short-lived test tokens for positive and negative capability checks. It denies every read of */data/* on platform, operators and secret. That denial is the point: SCOPE.md says ops-mason never touches secret values, and until now that was a promise kept by whoever was driving. An explicit deny outranks any grant, including one added to this policy later by mistake. The one time the line was crossed is recorded in plans/state-hub-forge-derivation-read.md §8; under this policy it would have been refused rather than recorded. sys/mounts/* is deliberately absent — enabling a mount is a railiance-platform act, and a grant that needed it should be recognised as a broader thing rather than folded in here. Also fixes the WSL2 login trap: bao login's browser launch fails under gio, so the script prints the URL plainly instead of appearing to hang. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Assistant: claude-code Assistant-Model: opus Assistant-Process: 3377672@bnt-lap001 Assistant-Session: 15463ccf-238f-4e13-b163-93aa25c6d166 |
||
|---|---|---|
| bundles | ||
| docs | ||
| intakes | ||
| manifests/whitehat-plane | ||
| plans | ||
| policies | ||
| scripts | ||
| src/ops_mason | ||
| tests | ||
| workplans | ||
| .custodian-brief.md | ||
| .gitignore | ||
| .repo-classification.yaml | ||
| AGENTS.md | ||
| INTENT.md | ||
| LICENSE | ||
| pyproject.toml | ||
| README.md | ||
| SCOPE.md | ||
| WORK-RECORDS.md | ||
ops-mason
The builder of NetKingdom security infrastructure — creates, changes, maintains, and tears down access routes, credentials, tokens, and policies so that ops-warden always has something real to route to.
- Why and boundaries: INTENT.md
- Current work: workplans/
The four-phase process
- Construction plan — given an access demand, draft what needs building, respecting/extending/compacting existing structure first.
- Review and optimize — self-review the plan against what already exists, for consistency and ease of use.
- Executive summary — the one mandatory human decision gate: render who gets what access, for how long, and what it costs to reverse.
- Build — once approved, execute the plan.
See INTENT.md for the full responsibility boundary against ops-warden,
OpenBao, flex-auth, and key-cape.
Guarded Kubernetes planes
Small Kubernetes security foundations can use the fail-closed ops-mason plane workflow. It pins source manifests and object identities, validates
cluster context/RBAC/dependencies/drift, requires an approved construction
plan plus exact digest for apply, and produces metadata-only evidence and a
non-executing rollback plan.