tegwick
1c3a9b46e3
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
28 lines
1.4 KiB
Markdown
28 lines
1.4 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.1.md) — how the
|
|
security estate is layered (Taxonomy / Tooling / Engines / Staff) and what each
|
|
layer may own
|
|
- [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.
|