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.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
|
|
|
- [Security layer model](canon/standards/security-layer-model_v0.7.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.
|
