gate-house/history/2026-08-28-security-layer-model-and-gate-house-recut.md

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:

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.

---

12. Outcome — assent, and what it changed

Added 2026-08-28, after the review closed.

Assent was requested as intakes in the owning repositories (FLEX-IN-0001, KG-IN-0001, WARDEN-IN-0001) with State Hub notification. All three assented, each with its own decision record, and each returned a finding:

• flex-auth (FLEX-DEC-2026-001) — assent to all three items, reasoning that it "cannot hold this boundary against zone-engine and decline it as a general rule". Self-declared a non-conformance: DecisionProvenance carries no digest of the registry snapshot, so a decision turning on registry content is not replayable from its own provenance. Drew one boundary back at gate-house: an authority ceiling that determines an outcome must reach the decision as an input claim or a versioned policy rule.
• kings-guard (KG-DEC-2026-001) — assent, and declined the offered relaxation of §5, arguing that latency and blast radius both argue for keeping it and that a containment path bypassing the decision point becomes an authority path the moment it is subverted. Raised the real defect instead: §4 catalogued containment while §5 forbade the only route to discharging it.
• ops-warden (ADR-0010) — assent to all three; the access-engine veto was not exercised. Grepped §5 as invited and self-reported a signing write to OpenBao. Offered the amendment that became §5.3.

The standard was revised to v0.2 and accepted. Three of the four changes came from the assenting repositories rather than from gate-house; the conformance loop in §12 of that standard turned on first contact, which is the only evidence so far against this repository's paper-generator falsifier.