coulomb/ops-warden
4
0
Fork 0
Code Issues Pull requests Projects Releases 2 Packages Wiki Activity Actions

Align INTENT and SCOPE to layer model v0.7; assess gaps; open WARDEN-WP-0034
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 1s
Details

Browse source 
The standard is accepted at v0.7, with SECURITY-COMPANION.md v0.2 as its
operative form. Four ops-warden findings were adopted between v0.4 and v0.7 —
§9.1's two marks, §5's Tooling scope rule, §6.4 obligation 1's second limb, and
§13.1's existence — and both ops-warden declaration artifacts are now cited in
the text as the estate's reference forms.

INTENT.md gains frontmatter (layer: Staff, pep_shaped: true) because §11 requires
a machine-readable declaration and prose cannot distinguish a declaration from a
transcribed review. The note now covers the agent principal (§3.4), the PEP
shape, the attributive evidence position, and the role the companion assigns:
the estate is told to ask ops-warden which lane, which credential, which route.

SCOPE.md records what is actually shipped against v0.7 and the honest conformance
state — declared gap, which is tracked non-conformance, not conformance.

The assessment checked every obligation against shipped code rather than intent.
Three gaps survive:

- §9.7.2 requires a PEP to state one revocation visibility deadline. Ours is
  unstated, and the honest value is uncomfortable: the cert TTL, up to 48h. A
  cert outlives revocation of the decision that authorized it — no CRL, no KRL
  distribution. That is a design property never written down, which is exactly
  what §9.7.2 exists to force into the open.
- §3.4 rule 1 forbids standing credentials and requires issued, attributable
  authority. ADR-0004's boundary keys on WARDEN_AGENT_ID, which an agent sets
  about itself. key-cape now issues a real coding-agent identity, so the
  ops-warden half can stop being advisory.
- §9.6 cadence remains undeclared. Attributive, so SHOULD not MUST, but silence
  through two reviews is the one outcome that is not defensible.

WARDEN-WP-0034 addresses all three, plus the discoverability gap the companion
creates and two items to route rather than absorb.

402 tests pass, ruff clean.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YWBMovyFoy9RRrfL7zKvPJ

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 4014535@bnt-lap001
Assistant-Session: d0036016-73e8-4da1-8e47-563e3ab39a3c
This commit is contained in:
tegwick 2026-08-29 14:50:55 +02:00
parent 94f32bd160
commit fd08950231
4 changed files with 411 additions and 30 deletions
Download patch file Download diff file Expand all files Collapse all files

90
INTENT.md
View file

@ -1,34 +1,67 @@
---
layer: Staff
role: null # Engines only: PDP | PIP | Evidence | Lifecycle
pep_shaped: true # §6.4 — issuing a certificate is a protected side effect
standard: net-kingdom/canon/standards/security-layer-model_v0.7.md
standard_version: "0.7"
companion: net-kingdom/SECURITY-COMPANION.md
declaration: layer.yaml
pep_stance: pep-stance.yaml
assent: docs/adr/ADR-0010
---
# INTENT
> **Layer: Staff.** ops-warden is a Staff repository under the NetKingdom
> IT-security layer model (Taxonomy -> Tooling -> Engines -> Staff, layered by
> determinism and by the kind of artifact each layer produces):
> `net-kingdom/canon/standards/security-layer-model_v0.4.md` (**accepted**), owned by
> gate-house, ratified as `gate-house/decisions/decisions.md` GH-DEC-2026-001.
> ops-warden's assent is recorded there as `ADR-0010`.
> **ops-warden is Staff, and PEP-shaped.** Declared here in its own voice, per
> `security-layer-model_v0.7` §11 — a layer stated *about* a repository by another
> repository is not a declaration. The standard is **accepted**; its operative form
> is `net-kingdom/SECURITY-COMPANION.md`. ops-warden's assent is `ADR-0010`, and its
> reviews of v0.4, v0.6 and v0.7 are in `history/`.
>
> **The binding rule: Staff never touches Tooling directly. It acts only through
> Engine APIs.** ops-warden holds no state another layer depends on at runtime and
> renders no authorization decision — it consumes them from access-engine.
> **Staff** because ops-warden's core function is judgement, not computation: it
> decides which lane a need belongs to and stewards the paths through the estate's
> rules. Its artifacts are runbooks, routing decisions, workplans. **PEP-shaped**
> because issuing a certificate is a protected side effect — a shape, not a layer
> (§6.4). ops-warden renders no authorization decision and never will; it consumes
> them from `access-engine`.
>
> **Declared exception (standard section 5).** `src/warden/vault.py` (`VaultCA`) is a
> direct OpenBao client that performs a write, and `warden desk` shells `bao kv put`
> for paste-once provisioning. Both are non-conformant. Intended owner:
> **secrets-engine**; blocked on: no engine exposes an SSH certificate signing
> surface; reviewed quarterly. `src/warden/taint.py` reads KV metadata only, declared
> under the read-only observation allowance. `warden access --fetch/--exec/--wrap`
> runs the owner's tool under **the caller's** identity and supplies no authority of
> its own (`ADR-0002`).
> **The estate's front door for paths.** The companion routes the whole estate here:
> *"For how to get something done — which lane, which credential, which route — ask
> `ops-warden`. This document says what the rules are; ops-warden stewards the paths
> through them."* That is a standing obligation, not a compliment: every rule
> gate-house writes needs a path someone can actually walk, and ops-warden owes the
> estate that path.
>
> **The declaration is `layer.yaml`, not this note.** v0.4 §5.3 requires a gap to
> carry `capability`, `intended_owner`, `blocked_on` and `review` *machine-readably*,
> and §11 makes "every direct Tooling client maps to a declared §5.1/§5.2/§5.3 entry"
> a mechanical check. `layer.yaml` is that map; `scripts/check_layer_conformance.py`
> and `tests/test_layer_conformance.py` enforce it, so a new undeclared OpenBao
> client fails on the commit that introduces it.
> **The declarations are files, not this note** — prose cannot distinguish a
> declaration from a transcribed review (§11):
>
> Assent, reasoning, and the amendment offered back to gate-house — adopted as
> v0.4 §5.3: `history/2026-08-28-security-layer-model-assent.md` and `ADR-0010`.
> | File | Declares | Enforced by |
> | --- | --- | --- |
> | `layer.yaml` | every Tooling contact, mapped to a §5.1/§5.2/§5.3 shape, plus the non-Tooling clients so the check is total | `scripts/check_layer_conformance.py`, `tests/test_layer_conformance.py` |
> | `pep-stance.yaml` | the unreachable-engine stance map (§6.4 obl. 3), total per zone | test asserts the published map **equals** the shipped default |
> | `tenancy.yaml` | tenancy posture, and `z1-operational` zone membership | `ADR-0009` |
>
> Both are cited in the standard as the estate's reference forms (§11, §6.4, §13.1).
>
> **Two declared engine gaps (§5.3), tracked non-conformance and not conformance.**
> `VaultCA` signs over a direct OpenBao client and `warden desk` shells `bao kv put`.
> Intended owner **secrets-engine**; blocked on no engine exposing an SSH-CA or
> attended-provisioning surface; reviewed quarterly; registered in statute §13.
> ops-warden keeps signing while the gap is open — refusing would remove production
> host access to close a documentation gap.
>
> **The agent principal (§3.4).** ops-warden is operated by agents as well as people,
> and they share the layer but not the blast radius. No standing credential; tool use
> is a conduit or an engine API and there is no third route; **tool availability is
> not permission**, which is exactly what `ADR-0004`'s read-boundary enforces; agent
> memory is not a state plane. Session semantics belong to `glas-harness`, not here.
>
> **Evidence (§9.6).** ops-warden's audit trail is **attributive**, not load-bearing:
> no control branches on the presence of a signing record. Emission is deliberately
> non-atomic so an audit-store failure cannot remove production host access — a trade
> the standard sanctions, declared in `wiki/AuditTrail.md`, registered in §13. If any
> future control ever gates on this trail, that trade must be revisited before it
> ships.
> This file captures **why this repository exists**, the **direction it is
> moving toward**, and the **kind of system it is meant to become**.
@ -110,7 +143,7 @@ owns one lane and points at the rest:
## Lane routing — who owns which need
**This is a runbook, not doctrine.** Security doctrine, the authority model, and the
security curriculum are **gate-house's** (`security-layer-model_v0.1` section 8).
security curriculum are **gate-house's** (`security-layer-model_v0.7` §8).
ops-warden references them and does not restate them. What follows is lane
stewardship: which subsystem owns which need, and what ops-warden does about it.
@ -137,7 +170,7 @@ orientation, and the catalog is the source of truth (`ADR-0001`).
### Access lane versus access rule
Normative, per `security-layer-model_v0.1` section 8 and assented to in `ADR-0010`:
Normative, per `security-layer-model_v0.7` §8 and assented to in `ADR-0010`:
- **access lane** — ops-warden and ops-mason. *How* a worker reaches a host.
- **access rule** — access-engine. *Whether* they may.
@ -147,7 +180,8 @@ may do something is not an ops-warden question, however it arrives.
Canonical references:
- `net-kingdom/canon/standards/security-layer-model_v0.1.md` (layers, section 5, section 8)
- `net-kingdom/SECURITY-COMPANION.md` — the operative form; start here
- `net-kingdom/canon/standards/security-layer-model_v0.7.md` (accepted; §5 shapes, §6.4 PEP, §8 vocabulary)
- `net-kingdom/docs/platform-identity-security-architecture.md`
- `net-kingdom/docs/responsibility-map.md`
- `wiki/AccessManagementDirective.md` (ops SSH actor model)