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.6 — type the engines, name the gate, hold actuation at zero
From the independent assessment of 2026-08-29, which found the model sound as a
layering constitution and incomplete as a self-healing one: cognition,
authority, and execution are specified, but the two verbs that close a healing
loop — observe in production, actuate through a deterministic surface — are
pending, and one is unstaffed.
Section numbers below §14 are unchanged; the estate cites them.
- §3.3 types the Engine layer: PDP, PIP, Evidence, Lifecycle, with a role column
in §4. Collapsing them hid different failure modes — a PIP outage is input
degradation, a PDP outage is consumer residue, an evidence-plane outage must
not block the operation it records. A new engine is a PIP unless amended.
- §6.4 names the enforcement point. The standard was precise about the decision
and silent about the gate, so enforcement lived in Staff runbooks. Four
obligations: no side effect without a decision record, no local recaching of
the verdict, a declared unreachable-engine stance, reconstructability.
- §9.2 replaced. Containment was marked pending against kings-guard, the right
mark on the wrong repository: reduce, step-up, and isolate are
authority-changing operations, so they are rendered by an Engine and enforced
by a PEP. Actuation is an unowned Engine concept held at zero. Staff proposes
containment and never performs it.
- §3.4 separates human and agent principals inside Staff — same permissions,
different blast radius. No standing credential, conduit or engine API only,
agent memory is not a state plane, every action reconstructable as the
caller's.
- §9.7 puts time into the model: explicit lifetimes, revocation visibility
deadlines, consumption as a state change never inferred from a decision
record, and the three race modes named. §9.8 states what holds under
partition.
- §17 requires the Taxonomy artifacts — claim, decision-record, gap-record, and
emission-cadence schemas — without which §6.2 and §11 are reviewable but not
compileable. Ownership proposed, not assigned.
- §18 composes the sibling standards, which had been cited in frontmatter and
nowhere in the rules.
- §5 sunsets the uncatalogued-infrastructure carve-out. §5.3 declines a proposed
fourth "operator of third-party Tooling" shape: it would convert a tracked gap
into a permanent allowance, which is the relabelling failure this standard
exists to prevent.
- §10 gains the six artifacts a layer change must carry, written from the
zone-engine case, including a permission freeze during the cut.
- §2 lifts the observation rule so it cannot be lost in a summary. §13 separates
its three normative rules from the table, now a snapshot due to move into
maturity-engine. §16 decides the approval custody question: no. §19 records
the fitness verdict.
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 03:32:58 +02:00
|
|
|
- [Security layer model](canon/standards/security-layer-model_v0.6.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
|
Add the agent companion to the security layer model
v0.6 is dense, self-referential, and written for readers who already live in the
estate. That is acceptable in canon and poor as a contract for the nine
repositories yet to declare and for the Staff agents expected to conform.
The companion is the operative form: the rules, no change log, no review
archaeology. Machine-readable layer key, the three sanctioned Tooling shapes as
a table, the PEP obligations, the evidence bound with the two unsound claims
written out, the four agent rules, and the four conformance states. The statute
governs on disagreement, and a disagreement is reportable as a finding.
Its §9 records that operations is HelixForge's responsibility — reef, rail,
rapp, rein — consuming the NetKingdom security and approval framework, and that
the interface is NOT yet specified. What holds today is only what holds for any
consumer. No mapping of those concepts onto the layer model should be assumed
until it is written; the statute's §16 carries the same open question.
Its §10 states the two things the estate cannot do yet — nothing is observed in
production, nothing can be contained automatically — so no reader plans around
a capability that does not exist.
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 09:25:40 +02:00
|
|
|
- [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
|
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.
|
