tegwick
0efa06fe5c
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
1.4 KiB
1.4 KiB
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, not a claim about current delivery.
Orientation
- SCOPE.md — what this repo owns, current state, and when it is relevant
- Security layer model — how the security estate is layered (Taxonomy / Tooling / Engines / Staff) and what each layer may own
- Security scenario composition — deterministic, plan-only capability and trust composition
- Posture feedback — deterministic, proposal-only posture and evidence remediation findings
Security Infrastructure Documents
- secrets-engine security infrastructure boundary 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.