2026-02-28 17:21:51 +01:00
|
|
|
# NetKingdom
|
2026-02-28 09:41:41 +00:00
|
|
|
|
2026-08-23 12:40:52 +02:00
|
|
|
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.
|
2026-07-02 00:21:49 +02:00
|
|
|
|
2026-07-08 13:19:06 +02:00
|
|
|
## Orientation
|
2026-07-08 13:07:03 +02:00
|
|
|
|
2026-07-08 13:19:06 +02:00
|
|
|
- [SCOPE.md](SCOPE.md) — what this repo owns, current state, and when it is relevant
|
Security Layer Model v0.5 — four reviews, nine changes
All four reviewing repositories returned findings on v0.4 and one contested a
rule. Every change below came from a reviewer, not from gate-house.
- §9.1 split into `pending` (no route, capability zero) and `declared-gap`
(route exists under §5.3, capability works). v0.4's single mark would have
forced a false "pending" onto ops-warden's production SSH issuance —
the fix was worse than the defect, and the defect was in this section.
- §9.3 rewritten. flex-auth contested it and was right: it collapsed "engine
reachable but degraded" with "engine unreachable", and the second has no
evaluator in the path to express anything. Input degradation is the engine's;
unreachability is the consumer's, bounded by a declared auditable total
stance — which ops-warden ADR-0009 already satisfies. v0.4 had ruled against
shipped behaviour in a repository that assented to it.
- §5 scoped: "Tooling-layer system" means a §4 Tooling row. Without this every
Staff repository was in undeclared violation for writing progress events.
- §9.4 requires the outbox to be local — no synchronous audit-core dependency
inside the state-change transaction, so an audit outage cannot block a
revocation.
- §9.5 forbids compiling maturity levels into registry content while decision
provenance carries no registry-snapshot digest.
- §9.6 gained load-bearing versus attributive evidence, the mirror rule that
absence is not evidence of non-occurrence, and kings-guard's finding that
suppression biases posture optimistic and silently.
- §11 gained a fourth state: blocked-clean, which MUST NOT rank below
conforming. A repository that declined a break-glass path and left a
capability at zero complied at cost; one that quietly opened a client and
declared nothing did not.
- §11 gained a machine-readable declaration form; ops-warden's layer.yaml is
the reference implementation.
- §13 gained state and owner-status columns; access-engine's decline of
authentication evidence is recorded.
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 02:54:25 +02:00
|
|
|
- [Security layer model](canon/standards/security-layer-model_v0.5.md) — how the
|
Add NetKingdom Security Layer Model v0.1 (proposed)
States how the security estate is layered — Taxonomy, Tooling, Engines,
Staff — distinguished by determinism and by the artifact each layer
produces, and what each layer may own.
Carries two normative rules. §5: Staff never touches Tooling directly; it
acts only through Engine APIs — the architectural form of "no privilege
from cognition", and mechanically checkable. §6: access-engine is the only
policy decision point, generalizing to the whole estate the ruling first
drawn in zone-engine/INTENT.md §5, and barring any Staff repository from
hosting a decision point.
Also fixes the vocabulary the estate has used for more than one thing:
access lane vs access rule, doctrine vs runbook, control plane as Engine
vocabulary, and the posture asymmetry.
Owner gate-house, published by net-kingdom. Status proposed: the two
adaptations carrying the most weight — flex-auth's reframing and rename to
access-engine, and kings-guard and ops-warden releasing vocabulary — are
not yet assented by their owners.
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-28 20:59:00 +02:00
|
|
|
security estate is layered (Taxonomy / Tooling / Engines / Staff) and what each
|
|
|
|
|
layer may own
|
2026-08-23 12:40:52 +02:00
|
|
|
- [Security scenario composition](canon/standards/security-scenario-composition_v0.1.md)
|
|
|
|
|
— deterministic, plan-only capability and trust composition
|
2026-08-23 13:16:34 +02:00
|
|
|
- [Posture feedback](canon/standards/posture-feedback_v0.1.md) — deterministic,
|
|
|
|
|
proposal-only posture and evidence remediation findings
|
2026-07-08 13:07:03 +02:00
|
|
|
|
2026-07-02 00:21:49 +02:00
|
|
|
## 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.
|
