net-kingdom/README.md
tegwick ce2554fdc9 Security Layer Model v0.7 — write the rule v0.6 only announced
Four reviews. kings-guard found that v0.6 claimed a human/agent principal
separation in §1 and §15 while §3.4 was byte-identical to v0.5: a silent edit
failure, and their framing is the right one — a rule stated about a standard in
its own change log is not a rule, which is §11's principle turned on the
standard. The same failure had dropped two §16 entries. Both restored.

§3.4 is now written: no standing credential, conduit or engine API only, agent
memory is not a state plane, every action reconstructable as the caller's, and
the seam with glas-harness for session semantics.

The rest are collisions between rules each written for its own clean case:

- §6.4(1) forbade what §6.4(3) blesses. A PEP may proceed under its declared
  §9.3 stance where the application of that stance is recorded in place of the
  decision — stricter than v0.6, since a fail-open result becomes metadata
  rather than silence. Raised by ops-warden, the reference shape it made a
  violation.
- §6.4(2) forbade the session-bound allow §9.7.1 permits. Now scoped to replay
  outside the decision's own binding and lifetime, with access-engine's
  canonical request digest as the mechanical test. Negative caching ruled
  permitted where the refusal is recorded and the lifetime declared.
- §13.1 now exists: v0.6 mandated a stance-map register and implemented none.
  Its first inventory has one row, which is the finding.
- §9.6 gained a threat decomposition after audit-core corrected its own remedy:
  atomicity prevents accidental omission, cadence and reconciliation detect the
  adversarial case, nothing prevents it at a compromised source. Cadence is now
  MUST for load-bearing sources, with heartbeat or reconciliation required for
  low-volume classes where rate monitoring cannot work.
- §9.7.2 splits by role: per input class at a PDP, one boundary deadline at a
  PEP.
- §17 moves the decision-record schema to access-engine, which argued it against
  its own interest.
- §13 stops attributing the actuation gap to kings-guard; §19 removed, since a
  verdict inside a standard grades the document it lives in.

§20 records the Railiance interaction boundary on railiance-master's own
definitions: the four axes, that a workload is a managed running deployable so
approvals are never one, and that rein-* is not a fifth axis but a glas-harness
concern. What is unsettled is listed as unsettled.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2564823@bnt-lap001
Assistant-Session: 2a7ed827-4928-4b9f-8613-9135c9cadfe9
2026-08-29 10:44:53 +02:00

31 lines
1.5 KiB
Markdown

# NetKingdom
NetKingdom is the canonical security architecture, integration boundary, and
bootstrap/reference implementation for NetKingdom environments. It defines
identity, tenancy, credential, workload-zone, and security-composition
contracts while leaving provider and Railiance execution in their owning
repositories.
The dynamic, self-optimizing security platform is the long-term direction in
[INTENT.md](INTENT.md), not a claim about current delivery.
## Orientation
- [SCOPE.md](SCOPE.md) — what this repo owns, current state, and when it is relevant
- [Security layer model](canon/standards/security-layer-model_v0.7.md) — how the
security estate is layered (Taxonomy / Tooling / Engines / Staff) and what each
layer may own
- [Agent companion](canon/standards/security-layer-model-companion_v0.1.md) — the
operative two-page form of that standard: what to declare, what binds you, what
you may never claim
- [Security scenario composition](canon/standards/security-scenario-composition_v0.1.md)
— deterministic, plan-only capability and trust composition
- [Posture feedback](canon/standards/posture-feedback_v0.1.md) — deterministic,
proposal-only posture and evidence remediation findings
## Security Infrastructure Documents
- [secrets-engine security infrastructure boundary](docs/secrets-engine-security-infrastructure-boundary.md)
defines how secrets-engine participates in the NetKingdom security
infrastructure and how it interacts with OpenBao, flex-auth, user-engine,
ops-warden, ops-bridge, info-tech-canon, State Hub, and agents.