The operator token was not expired after all -- `bao policy read` succeeded, so
the deployed policy is now compared directly instead of the file. Three
corrections to RISK-F-0009, which was filed static:
1. Six high-risk lanes are uncovered, not eight. The finding counted
openbao-api-key (a path pattern) and ops-warden-warden-sign-token (a broker
grant, not KV) among the concrete uncovered paths, while its own prose said
the first was a pattern. Five lanes have no address for a policy to deny.
2. Coverage holds at 6 of 17 against the live policy.
3. The deployed policy has drifted from the file: the file denies
platform/workloads/core-hub/runtime, the server does not. No ops-warden lane
maps there so our numbers are unchanged, but it proves the file was never a
safe proxy for the server -- which is what the finding flagged as unconfirmed.
scripts/check_agent_read_boundary.py is the invariant RISK-F-0009 asked for
rather than a one-off audit: it fails when a high-risk lane has no corresponding
deny. Capabilities-only by construction -- it reads the policy document, never a
secret value, and never mints a token.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
issue-core asked us to drop a CoulombCore/port-18765 bridge topology from
activity-core-issue-sink. That topology was never in this repo — the only address
the playbook carried was a local-dev 127.0.0.1:8765 example. What was actually
stale was step 5, which still told workers to coordinate with railiance-platform
"when the canonical path ships"; it shipped 2026-07-02 and the lane is active.
So: point at issue-core's SCOPE.md for the production address rather than
restating it here (ADR-0001), state plainly that no bridge or forwarded port is
involved so the next reader does not re-derive the retired topology, and route
step 5 through warden route / warden rotate-guide instead of a read.
WP-0032-T01 closes as done. What was owed was inputs, not a design, and
ZONE-WP-0001-T02 is done carrying all of them — including the two that were
corrections to ops-warden's own claims (organization_posture, refused by
net-kingdom; and the workload join key, which this repo wrongly said did not
exist anywhere).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Computes the join rather than asserting it, and offers both plausible workload
segments per path instead of a single positional guess, because the path
convention is inconsistent.
Measured result: 1 of 27 lanes matches a declared workload. The workload
declaration surface exists, but it covers almost none of the credential estate.
Read-only; touches no secret value and no live system.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
agent-high-risk-boundary denies 5 data paths, covering 6 of ops-warden's 17
high-risk lanes. Eight high-risk lanes with concrete KV paths are not denied,
four of which were already graded high before the 2026-08-19 regrade — the
divergence is pre-existing and the regrade only made the lists comparable.
This is the layer that matters most: warden access exits 7 for all 17, but that
protects only the ops-warden path. The policy protects a direct bao kv get,
which is the 2026-07-16 vector.
Routed to risk-nexus as RISK-F-0004 with fix_owner railiance-platform, since the
policy is theirs. Live confirmation outstanding — ops-warden's OpenBao token is
expired, so this is a static file-vs-catalog comparison and the finding says so
rather than implying it was verified against the server.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The mechanism behind RISK-F-0003 was sharper than the finding described.
is_high_risk was risk == "high", but risk was never absent at the model layer:
RouteEntry.risk carried a dataclass default of "standard". An omitted grade was
not unhandled, it was actively resolved to the permissive value — fail-open by
construction, which is why nothing ever warned.
The default is now "ungraded" and is_high_risk returns true for anything outside
an explicit low-risk vocabulary (standard / low / accepted). An omitted grade and
an unrecognised grade from a newer catalog both resolve to high, so the boundary
fails safe in both directions rather than reading an unknown value as permission.
test_every_repo_catalog_lane_is_explicitly_graded is the CI gate that stops an
ungraded lane being committed, per ADR-0007: absence is not a grade.
"accepted" is in the low-risk vocabulary deliberately, ready for the
maturity-derived default — an experimental-context lane may be explicitly
accepted, which is a graded decision rather than an omission.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Closes the RISK-F-0003 exposure. All 14 ungraded lanes now carry an explicit
risk grade with its justification in the entry: 17 high, 10 standard, 0
ungraded. The agent read-boundary now fires (exit 7) on lanes that were silently
outside it.
Graded on merit rather than defensively. A first pass marked two ordinary
internal workload secrets high; test_high_risk_lanes_classified asserted the
opposite and was right, so both were regraded down. high means disclosure into a
logged context is damaging beyond what rotation recovers. inter-hub-bootstrap-ssh
is high conservatively, with the reason in the entry so it is regraded with
evidence rather than assumed down.
ADR-0007 records the rule the grading rests on: build-stage permissiveness
applies to controls that gate work, not to controls that prevent credential
disclosure. The test is friction, not severity — the read-boundary blocks nobody,
since --out/--exec/--wrap remain available, so relaxing it buys nothing. A
blocked operation is recovered by retrying; a credential in a logged transcript
is not recovered by rotation.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Splits RISK-F-0003's response in two. T05 grades the five exec_capable ungraded
lanes explicitly — a live gap in a shipped ADR should not wait months for the
zone model. T06 makes absence impossible once the model says what absence means,
per the operator's maturity-derived default.
Grading is flagged as judgement requiring operator sanction, not backfill.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
net-kingdom ruled that zone membership rides tenancy.yaml under a reserved
zones: key, and ops-warden had no such file — so declaring zones later implies
declaring the six-axis vector first. This is that file.
Current: I1 A1 E0 P n/a R n/a V0, validated against the canon schema.
Graded honestly against the standard's own worked examples rather than
flatteringly. A1 not A2: there is a single choke point on the signing path, but
it binds an actor to principals, not a request to the tenants it may act for,
and tenant context is a constant. E0 is accurate and is not a defect to
remediate — ops-warden holds no tenant-keyed data because ADR-0002 forbids it
custody, and claiming E1 on the strength of OpenBao's enforcement would be
someone else's control counted as ours. V0 because the code path for a local-CA
fallback exists but has never been exercised, and §13 does not accept "the code
path exists" as evidence.
implemented: A3 is the one place ops-warden is ahead of its current level —
flex-auth delegation is built and was verified live against the enforcing pin
(decision:f3f7c88f9585582a). It is not current because ADR-0006 defers it.
The zones: key is deliberately absent with the reason written in: no zone
vocabulary exists yet, so any value would be fabricated.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Amended by net-kingdom as canon owner of tenancy-posture_v0.1, answering
ZONE-WP-0001-T01.
T01: organization_posture does not fold into zones and does not belong in a
per-repo declaration — it is a fleet-wide time-varying scalar. Hand it over as an
input.
T03: zone membership is declared in tenancy.yaml under a reserved zones: key
(canon Decision 5.6). ops-warden has no tenancy.yaml, so this now implies
declaring the six-axis posture vector too. Also records why this declaration may
not set stance: a declarer that sets its own stance makes exempt conformant.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
flex-auth reviewed ZONE-WP-0001 as the consuming PDP and two findings
land on the ops-warden consumer side:
T02 - fail_closed is not expressible by a PDP. Fail-open describes what
warden sign does when flex-auth is unreachable, so no decision exists to
carry it. The replacement for policy.enabled is two things: stance,
which arrives in the decision, and failure mode, which stays local and
is declared per zone.
T02 - build_flex_auth_registry.py:77 already emits a hardcoded
trust_zone: platform that no policy reads. Resolve that before
compiling zone membership rather than adding security_zone beside it.
T03 - the declaration must say whether a zone rides the actor (subject)
or the lane (resource); in the compiled registry an actor is both.
No flex-auth registry schema change is needed - metadata, labels and
attributes already flatten into the rego input.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
zone-engine is seeded and owns the security zone model as ZONE-WP-0001. Under
ADR-0005 ops-warden implements one lane narrowly and routes the rest, and an
estate-wide enforcement model is not a lane to absorb — it was ops-warden's
deferred flip that exposed the gap, not ops-warden's model to define.
WARDEN-WP-0032 is rewritten as the consumer side: hand the estate inputs to
ZONE-WP-0001-T02 (27 catalog lanes, the actor inventory, the three posture axes,
the three controls the model must express, and the compiled-registry path),
then replace policy.enabled with a zone-aware control and amend ADR-0006 to say
ops-warden follows the model rather than owning it.
ADR-0006 and SCOPE updated to point at zone-engine, which joins the related
repositories table.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Expands the placeholder into a real plan, grounded in what the estate already
has rather than first principles:
- tenancy-posture_v0.1 is the structural model to follow (canon standard +
per-repo declaration + "accuracy, not altitude"), and its §14 adoption stance
is "structure, not tooling" — a precedent about sequencing.
- Reefs are substrate placement zones with real risk statements. A security
zone is not a reef; repo-manager's own "topology is not readiness" applies
here as "placement is not posture".
- flex-auth is latency-critical and already consumes a compiled registry
snapshot, so zone membership should reach the PDP by compilation rather than
a synchronous lookup in the decision path.
- warden plan already returns verdicts with reasons; zone-aware enforcement
extends that machinery instead of growing a parallel one.
T01 settles ownership before any modelling, because it decides which repo the
rest lives in: canon standard, a zone-engine runtime authority, or flex-auth
policy data. The recommendation is canon-first with zone-engine named as an
explicit promotion — but the time-boxed refactor exception is the case that
could justify an engine immediately, since an expiring grant is state and state
wants an owner.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
flex-auth enforced its ops-warden pin (FLEX-WP-0016 T03) and the gate verified
clean against it: readiness exits 0, decision:f3f7c88f9585582a, anonymous
/v1/check now 401. Everything needed to set policy.enabled: true was in place.
It stays false, by decision. policy.enabled is a single repo-wide boolean, and
with fail_closed: true it makes flex-auth a hard dependency of every warden
sign — including the certs the ops-bridge tunnels depend on, one of which
carries the policy call itself. Uniform enforcement across an estate being
actively rebuilt hardens the access needed to perform the rebuild.
The repo already refuses one-dimensional posture: WP-0015 shipped environment
and maturity axes, WP-0029 added organization_posture. A global flag ignores all
three. ADR-0006 records that enforcement belongs to a zone, and binds future
work — a zone-blind enforcement flag is out of order, not merely unwise.
WARDEN-WP-0032 drafts the zone model, leading with the ownership question:
whether this is ops-warden's to own or NetKingdom canon to consume (ADR-0005).
WP-0031 is finished with T05 cancelled and resuming as WP-0032-T05.
Also replaces the hand-run kubectl port-forward with a managed ops-bridge
tunnel, flex-auth-ops-warden-railiance01 (-L 19090:10.43.1.165:8080).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
CoulombCore is being retired, so the docs stop using it as the reference host:
state-hub-coulombcore examples become state-hub-railiance01, and the reuse-surface
playbook no longer attributes bao.coulomb.social to it — that resolves to
92.205.62.239, which is railiance01. The openrouter lane keeps its factual note
about ESO on the CoulombCore cluster, with a retirement flag for its owner.
Also corrects this session's own error. The WP-0031 evidence blamed the
Unauthorized on a local-port collision between k3s-api-coulombcore and
k3s-api-haskelseed. That was wrong: the haskelseed tunnel is a reverse forward,
where local_port is a destination rather than a listener, so they never competed.
16443 was simply CoulombCore's k3s — a different cluster whose client CA does not
know that cert. The wrong reason had already gone to flex-auth, so it is
corrected in the file rather than quietly dropped.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
flex-auth's binding names system:serviceaccount:ops-warden:ops-warden, and that
ServiceAccount did not exist. deploy/kubernetes/caller-identity.yaml creates it
plus its namespace — no RBAC, automount off; it is never used to call the
Kubernetes API, only to be TokenReviewed. Applied to the railiance01 cluster.
Operator warden.yaml now uses caller_auth mode: command (kubectl create token,
audience flex-auth, 10m). Gate exits 0 live against a port-forward of the pin:
HTTP 200, effect=allow, decision:f3f7c88f9585582a.
The evidence is not that allow — warn allows anonymous callers too. It is that
the pin's "caller authentication warning" count held at 4 across two
authenticated runs. That is the ADHOC-2026-08-17-T01 condition.
Also gives the readiness probe a structurally complete context, so a deny means
the policy said no rather than the probe being malformed.
policy.enabled stays false. T05 waits on flex-auth setting callerAuth.mode:
enforce (their FLEX-WP-0016 T03).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
flex-auth's flex-auth-ops-warden pin (FLEX-WP-0016) TokenReviews the caller and
binds resource.system: ops-warden to system:serviceaccount:ops-warden:ops-warden.
policy.py posted /v1/check with no Authorization header, so the pin logs
"caller authentication warning" and can only run callerAuth.mode: warn — which,
under ADHOC-2026-08-17-T01, is exactly what blocks policy.enabled: true.
- policy.caller_auth (none | file | env | command) + src/warden/caller_identity.py:
token resolved per call, never cached, written, or logged (ADR-0002)
- both check_sign_policy and check_fetch_policy attach the bearer header; an
unobtainable token fails closed rather than retrying anonymously
- scripts/check_policy_caller_identity.py: read-only gate, prints length and a
truncated fingerprint only, distinguishes 401 (audience/binding) from 403
- example config: caller_auth block, and flex_auth_url corrected — it pointed at
flex-auth.flex-auth.svc, a Service that does not exist
- WARDEN-WP-0031, PolicyGatedSigning caller-identity section and flip sequence
Default stays mode: none, so behaviour is unchanged until an operator opts in.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Five rules that governed this repo lived in wiki prose, a workplan, and a
comment at the top of catalog.yaml. All were followed; none was addressable.
A reader outside ops-warden could not cite one, could not tell whether it was
current, and — the point of this change — could not tell whether it was ours
to change or someone else's that we merely obey.
ADR-0001 The routing catalog is a pointer layer, never a second copy
ADR-0002 ops-warden is a transparent conduit, never a secret broker
ADR-0003 Cover gaps, but never silently own them
ADR-0004 High-risk lanes refuse raw value streaming to agent sessions
ADR-0005 Implement one lane narrowly, route everything else
Each carries owner: ops-warden, which is the load-bearing field. It says we
follow the rule AND we are responsible for changing it — by superseding ADR,
never an in-place edit. The failure this prevents runs both ways: a rule we own
mistaken for inherited canon never gets fixed, because we wait for an owner who
does not exist; inherited canon mistaken for ours gets quietly bent, and the
drift is invisible until it breaks a repo that trusted the canonical version.
Rules we follow but do not own — NetKingdom canon, the IAM profile, the
credential-management standard, the-custodian's ADR-001 workplan convention —
are cited, never copied into docs/adr/. Copying them would recreate exactly the
second-source-of-truth failure ADR-0001 exists to prevent. architecture.md also
now flags the three-digit/four-digit ADR-001 vs ADR-0001 collision, which is
itself an ours-versus-inherited confusion waiting to happen.
Publication verified rather than assumed: all five render through policy-nexus
tools/render.py, and owner reaches the reader in three places — the page eyebrow
(render.py:346), the index Owner column (build_site.py:123,137), and the
publication manifest. build_site.py:179 makes title/status/owner required, so
ownership cannot be dropped on the way out. policy-nexus publishes and never
writes back; docs/adr/ stays the source of truth.
Documentation adapted: SCOPE.md gains a Governing rules section and an orientation
entry; .claude/rules/architecture.md replaced its stub with the ADR index, the
owned-versus-inherited rule, and ADR-over-wiki precedence; finding-routing.md's
ADR-gap section closed; catalog.yaml's no-double-source header now cites ADR-0001
rather than the originating workplan.
uv run pytest -q → 338 passed, 4 deselected.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Two estate repos now own things ops-warden had been handling in-repo by
default. New rule .claude/rules/finding-routing.md, wired into CLAUDE.md.
The correction it encodes: on 2026-08-17 flex-auth reported a live
authorization bypass directly to ops-warden — in the service our own pre-sign
gate consults. We answered the design question and wrote the recommendation
into wiki/NetKingdomSecurityMap.md, and did not route the finding.
rapp-postgres filed it, which is why RISK-F-0001 reads
reported_via: rapp-postgres despite ops-warden being a first-hand recipient
and the affected PEP. That is the exact failure risk-nexus/INTENT names:
findings landing in whichever document was open. A wiki section answers a
question; it carries no severity, owner, date, or review that fires when
nobody looks. Answering and routing are not alternatives.
Also recorded: the delegation register is explicitly NOT a findings feed
(risk-nexus wants a register small enough to read); severity/disclosure/
escalation stay unset when we route, because the reporter says what is true
and that repo says how bad it is; and a blocker is a claim about the world at
a date — RISK-F-0001 invalidated one of ours in a day.
Offers warden plan (WP-0029) to risk-nexus for its unwritten escalation duty:
a shipped classifier for what must reach the operator personally, decided by
properties rather than instinct, carrying reasons and a typed act.
Flags but does not close the policy-nexus gap: ops-warden has no ADRs, yet
carries rules that govern other repos (no-double-source, conduit-not-broker,
interim-by-default, agent read-boundary). They sit in wiki prose and are
therefore unpublishable and uncitable. Structural call, left to the operator.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Inbox triage (ADHOC-2026-08-17), three messages, all answered and marked read.
flex-auth (FLEX-WP-0015 T02) reported that /v1/check and /v1/batch_check
authenticate no caller — any workload with cluster reach can assert any subject
and get an authoritative allow. It lands here because ops-warden owns workload
identity in this estate and its pre-sign gate is a flex-auth PEP.
Recommendation recorded in wiki/NetKingdomSecurityMap.md: Kubernetes
ServiceAccount TokenReview with a projected, audience-scoped token. Rejected the
shared-secret header — it manufactures a risk: high lane with a rotation owner
per caller on the authorization path, the exact interim-proxy debt WP-0030
exists to stop growing. Deferred mTLS pending an owner for a workload X.509 CA.
Bind `system` to the authenticated SA at auth time, but keep the resource-type
allowlist in the policy package rather than the admission layer. Warn-only
rollout; policy.enabled must not flip while /v1/check answers unauthenticated
callers. Recorded as a pattern, not a catalog entry.
Catalog delegation refreshes:
- coulomb-social-runtime-env: USER_ENGINE_PROXY_SECRET ownership settled
(decision 8fe22037, USER-WP-0021) — intended_owner stays railiance-apps,
answered clause dropped from blocked_on, consumers: [user-engine] recorded.
- rapp-qonto-keycape-client: blocked_on no longer implies an in-flight
KEY-WP-0008 dependency; the key-cape-native exchange command is unopened work.
uv run pytest -q → 338 passed, 4 deselected.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Every execution position is now explicit. Catalog entries carry
delegation.mode (permanent / native / interim) with intended owner and
blocker. warden route gaps lists the interim set. Promotion requires
the ownership question. Doctrine lives in AccessRouting.md; the
register was published to the named owner repos.
Revised the classification axis after inspecting the entries: sorting by
subsystem was wrong. Nine of eleven lanes are a generic KV read with the
caller's own token, duplicating no owner procedure. Test is now
procedure-or-lifecycle vs generic read.
Interim now: rapp-qonto-keycape-client (key-cape), binky-company-email-imap
and binky-qonto-api (tenant-engine), railiance-backup-offsite-lane and
agent-harness-forgejo-deploy (re-establish procedures).
Held: the six thin-wrapper lanes are permanent only if secrets-engine exec
stays per-lane; asked whether it generalizes (msg 7d55d332).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Founder decision 2026-08-11: neither withdraw nor proceed. The broker covers
the workstation, but unattended signing on a remote tunnel host is unresolved,
and there the AppRole is narrower than placing the broker's issuer token.
Recorded where each trigger will be hit: WP-0027 break-glass task (trust-root
design), and the ops-bridge cutover playbook (token source must be resolved
before going live). secrets-engine told to stop holding apply readiness.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Founder directive: ops-warden works with, never replaces or duplicates,
secrets-engine / tenant-engine / user-engine. Covering an unfilled gap is
acceptable only as a tracked interim with a named intended owner.
- INTENT §9 "Cover gaps, but never silently own them"; success criterion 7;
tenant-engine and user-engine added to the literacy table; non-goal on
permanently owning another component's lane
- WP-0030 (proposed): delegation: metadata, backfill, warden route gaps,
promotion gate, publish the register to owner repos
- history/2026-08-11-delegation-surface-assessment.md: 2 of 24 lanes carry
exec_owner; 11 proxies record no intended owner
- SCOPE refreshed to 2026-08-11 (was 6 workplans behind); completeness C5 -> C4
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Answers owed were sent and all 11 marked read: railiance-platform front-door
thread confirmed closed (both lanes active, selector is openrouter-llm-connect),
railiance01/activity-core and llm-connect requests superseded, secrets-engine
warden-sign referred back to the operator.
Leaves T03 open: whether to keep or withdraw the warden-sign AppRole now that
the credential broker serves the VAULT_TOKEN lane.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The catalog pointed at wiki/CredentialRouting.md#credential-routing-catalog,
which does not exist; the live heading is "Routing catalog index". Restores
tests/test_routing.py to 61/61.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Maintainer decision, 2026-07-29: adopts TRSL V1C1 as this repo's
preliminary governing license, per target-revenue's
workplans/TREV-WP-0008-governance-and-pilot-rollout.md T05. Full
specialist legal review is deferred until out of beta (target-revenue
SCOPE.md §1). No Phase is yet declared for this repo.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Founder completed paste-once-provision; glas-harness/GLAS-WP-0002-T02's
live verification succeeded for real (AppRole login, KV v2 read, real
OpenRouter call, real commit, OPENROUTER_API_KEY unset throughout).
Two real fixes recorded along the way: platform-admin's policy needed
a new reins/* entry (every other KV mount was already listed there),
and the consumer policy itself needed the KV v2 data/+metadata/ path
shape instead of the bare KV v1 path it was originally written against.
Full account in ops-mason/plans/rein-openweights-openrouter-approle.md
section 7.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Proposed by ops-mason (MASON-WP-0001-T05), built and approved 2026-07-27
(Bernd Worsch). New pointer-only entry mirroring
agent-harness-binky-mail-approle's shape: AppRole login, no operator
present, scoped to exactly one KV path (reins/rein-openweights/openrouter,
new reins/ KV v2 mount -- no existing mount fit without widening scope
beyond what was approved). status: draft until the founder completes
paste-once-provision and glas-harness/GLAS-WP-0002-T02's live
verification succeeds.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
