# NetKingdom IT-security layer model, and the gate-house re-cut **Recorded:** 2026-08-28 **Audience:** gate-house, flex-auth, ops-warden, ops-mason, kings-guard, whitehat-security, net-kingdom canon **Sources:** `INTENT.md` of net-kingdom, info-tech-canon, key-cape, user-engine, tenant-engine, zone-engine, secrets-engine, flex-auth, ops-mason, ops-warden, kings-guard, whitehat-security, gate-house; `net-kingdom/canon/standards/`; State Hub domain summary for `infotech` (2026-08-28) **Status:** Reference note. Records the outcome of a working discussion. Not canon, not a decision record — the decisions it recommends are listed in §9 and still have to be written and assented to. --- ## 1. Executive summary gate-house was seeded describing itself as a deterministic authority plane: a policy decision point with `/authorize`, `GRANT`/`DENY`, grant storage, a revocation service, and an ADR to select a policy engine. A review of the security estate's `INTENT.md` files established that this is the wrong role for the repository, that it collides with `flex-auth`, and that the estate had already ruled on the underlying question in `zone-engine`. The discussion produced a four-layer model of NetKingdom IT security, distinguished by **determinism and artifact kind**. Under that model gate-house belongs to the top, interactive layer — the council where security and defence doctrine is established, documented, taught, and supervised — and explicitly not to the deterministic decision path. No code exists in gate-house. The re-cut costs nothing but documents. --- ## 2. The layer model | Layer | Character | Artifacts | Members (security estate) | |---|---|---|---| | **Aspects / taxonomy** | cross-cutting language | terms, semantic contracts | info-tech-canon | | **Tooling** | deterministic infrastructure; consistent, performant, scalable state | data structures, persistence | authelia, lldap, privacy-idea → packaged as key-cape; OpenBao | | **Engines** | deterministic APIs for a modeled concept | interfaces, contracts | user-engine, tenant-engine, zone-engine, secrets-engine, flex-auth, role (future) | | **Staff** | interactive, non-deterministic; management, operations, change, innovation, controlling | specifications, decisions, workplans, tasks | gate-house, ops-mason, ops-warden, kings-guard, whitehat-security | The layer boundary is defined by what a layer *produces* and how deterministic it is, not by technical tier. Engines model a concept and expose it deterministically; new concepts get new engines as they become relevant. Staff repos work through agentic capability — assistants and autonomous agents — and their output is specification and decision, not state. ## 3. Why the model is load-bearing: it is self-similar to the Canon Read by determinism, the layers reproduce the three planes of the Active Secrets Management Canon: ```text Staff interactive, non-deterministic ≈ Cognitive Plane Engines deterministic APIs ≈ Authority Plane Tooling deterministic state ≈ Execution Plane Taxonomy cross-cutting language ``` *Cognition proposes. Authority disposes. Infrastructure executes.* stops being a security maxim and becomes the layering rule of the estate. NetKingdom's structure is an instance of the principle its security canon teaches. This yields the argument that settles gate-house's role: > **If gate-house implemented `/authorize`, it would place the deterministic > authority boundary inside the non-deterministic management layer — violating > INV-02 ("No Privilege from Cognition"), its own first invariant.** The repository would be the clearest available counterexample to the canon it hosts. This is not a turf dispute with `flex-auth`; it is internal incoherence. ## 4. The invariant that makes the layering checkable A taxonomy that only labels decays. The model carries one falsifiable rule: > **Staff never touches tooling directly. It acts only through engine APIs.** This is the architectural form of "no privilege from cognition". It is why kings-guard — agentic, therefore Staff — may contain a threat only by calling an engine, never by reaching into OpenBao itself; and why an autonomous coding agent gets no shortcut. It is greppable: a Staff repo holding a direct database or OpenBao client is violating the model. ## 5. Findings from the INTENT review **5.1 gate-house already contradicts itself.** `README.md` line 7 — *"Think of Gate House as observability for vault managed secrets based on sound governance policy best practices"* — is a Staff-layer sentence, and the only one in the repository. Everything after it describes a runtime decision point. **5.2 Direct collision with flex-auth.** `flex-auth/INTENT.md` carries a section titled **"Flex-Auth Owns Authorization"**, claiming canonical action vocabulary, policy-as-code packages, PDP adapter coordination, and *"decision logging, explanations, and audit export"*. gate-house's INTENT claims each of these, and its shorthand line "**Gate House authorizes**" contradicts flex-auth's *"flex-auth decides what that actor is allowed to do"*. **5.3 The estate already ruled.** `zone-engine/INTENT.md` §5, after flex-auth pushed back on review of a first draft that got it wrong: > *"`flex-auth` is the policy decision point. It stays the only one."* and §7, naming the failure mode: > *"It becomes a second decision point. The failure would not announce itself; > it would arrive as a small convenience."* zone-engine's resolution is the precedent: *"The honest outcome is canon plus offline conformance tooling, not an engine."* **5.4 gate-house is invisible to the estate, in both directions.** There is no mention of gate-house or the ASM Canon anywhere in `net-kingdom/canon/`. ops-warden's "NetKingdom Security Literacy" table enumerates every plane and routes *"Policy decision — may actor X access resource Y"* to flex-auth; gate-house does not appear. Conversely gate-house's own responsibility table omits flex-auth, zone-engine, and info-tech-canon. The collision was unrecorded on both sides, which is why it surfaced only now. **5.5 What is genuinely gate-house's, and unowned.** Removing the decision point leaves substance with no other home: assistant vs autonomous as distinct security regimes; the principal / actor / runtime-identity triple; mandates, authority ceilings, and kill switches; the Change Dynamics Envelope; the MCP doctrine that tool availability is not permission; the posture→authority asymmetry shared with kings-guard; the ASM Canon itself; and the assurance tests T-01…T-10 as specifications. ## 6. The re-cut gate-house is the council where security and defence doctrine is established, documented, taught, and supervised — the headquarters of the operational staff that does the chores of IT security in NetKingdom. The name is retained. Boundary, in one line: > **The mandate and the operating mode are gate-house's. The decision is the > authorization engine's. The credential is secrets-engine's. The perimeter is > ops-mason's and ops-warden's.** **gate-house owns:** the authority context schema (principal / actor / runtime / tenant / mandate / task / mode) consumed by the authorization engine as input claims; the invariants as canon, federated into `net-kingdom/canon/standards/`; conformance review — whether an actor's actual authority matches its declared mandate and ceiling; the assurance-test specifications, executed by whitehat-security; and the security curriculum. **gate-house stops owning:** `/authorize`, the policy evaluation order, policy engine selection, grant storage, and the revocation service. ## 7. Two boundaries this clarifies **7.1 Policy authoring vs policy evaluation.** flex-auth today claims both *"policy-as-code packages, tests, versions, and rollout"* and the evaluation itself. Under the model these are different layers: authoring and governing policy is Staff work; evaluating it deterministically and in-path is Engine work. This resolves the `FLEX-WP-0017` overlap constructively — designing the approval contract (what must bind to an approval, what an authority ceiling means) is gate-house; validating an approval at decision time is the engine's. **7.2 Doctrine vs runbook.** gate-house owns doctrine and curriculum; ops-warden owns the lanes it stewards and their runbooks. That ops-warden had to grow its own "Security Literacy" section is evidence the curriculum had no owner. ## 8. Risks and falsifiers - **HQ becomes a paper generator.** Doctrine no engine implements is fiction. gate-house needs a conformance loop — it asserts invariants, whitehat tests them, kings-guard observes, results return — or it fails as architecture boards fail. - **Workplan absorption.** An HQ that "manages the chores" drifts toward hosting workplans for secrets-engine and ops-warden. ADR-007 and repo-manager place work structure in the repo doing the work. gate-house sets doctrine and reviews conformance; it must not become the second decision point in management clothing. - **The name argues against the role.** A gatehouse is where requests pass through; it reads as an enforcement point. Historically it also housed the guard and the porter's rules, so "where entry doctrine is set and the watch is briefed" is defensible — but only if `INTENT.md` says so in the first paragraph, or every reader re-derives the PDP misreading. ## 9. Rulings taken, and what remains open Taken on 2026-08-28, to be written up as the decision record in §11.2: 1. **The layer is named Staff.** "Helpers" was the working term and undersold a layer holding architecture, doctrine, controlling, and change. Staff carries the general-staff sense — plans, doctrine, and orders, without execution — and sits in the kingdom metaphor beside guard, warden, and mason. Applied throughout this note. 2. **The layer model is NetKingdom canon, not info-tech-canon.** It is NetKingdom-flavored security architecture, not general semantic contract, so it belongs in `net-kingdom/canon/standards/` alongside `security-zones_v0.1`, `credential-management_v0.2`, `tenancy-posture_v0.1`, and the `*-boundary-contract_v0.1` family. info-tech-canon keeps the cross-cutting terminology role and does not carry the model. 3. **flex-auth is reframed as an Engine and renamed.** `access-engine` is the working proposal. Sequence is unchanged: reframe the INTENT first, rename second, as a governed migration — the rename touches `FLEX-WP` prefix ownership, State Hub identifiers, ops-warden's tables, zone-engine's binding boundary text, and secrets-engine integrations. Open: - **The rename target.** `access-engine` reads naturally and avoids the authentication/authorization ambiguity that rules out `auth-engine` while key-cape owns authentication. Its cost is that "access" is already spoken for operationally: ops-warden is the *"operational access steward"* owning *"operational SSH access guidance"* and `wiki/AccessManagementDirective.md`, and ops-mason's one-liner is to maintain *"access routes, credentials, tokens, and policies"*. In current NetKingdom usage "access" denotes the operational lane by which a worker reaches a host — Staff territory — rather than the decision about whether they may. Adopting `access-engine` therefore requires demarcating the word in both INTENTs: **ops-warden and ops-mason own access lanes; access-engine owns access rules.** `permission-engine` avoids the collision but ages badly against a future `role-engine`, since roles grant permissions and the two would overlap; `access-engine` sits cleanly above roles. `authz-engine` is precise but insider shorthand. ## 10. Consequences for existing gate-house artifacts - `INTENT.md` — major remake; the re-cut in §6 replaces the authority-plane framing. - `README.md` — the "observability … governance best practices" sentence is the correct one and should lead. - `ArchitectureBlueprint.md` — the component architecture (§10–11), policy evaluation order (§13), API surface (§26), and storage model (§25) describe an engine and do not survive the re-cut. The domain model (§6), canonical authority context (§7), operating modes (§14–15), change dynamics (§20), MCP integration (§19), and the security test program (§34) do. - ADR-003 (policy engine selection) falls away; ADR-001, ADR-002, ADR-006, ADR-009, ADR-010, ADR-013 and ADR-014 remain meaningful as contract and doctrine. - Milestones M0, M3, and M4 lapse. `GH-WP-0001-T04` (`/authorize` skeleton) should not be built; `GH-WP-0001` needs rewriting against the re-cut before it is promoted to active. ## 11. Next steps 1. Rewrite `gate-house/INTENT.md` against §6. 2. Write the decision record covering the layer model, the gate-house re-cut, and the flex-auth reframing as three linked rulings — the second does not hold without the first. 3. Adapt the other `INTENT.md` files that need clarification, and seek assent from flex-auth and ops-warden for the boundaries in §7. 4. Rewrite `GH-WP-0001`; revise the Blueprint per §10.