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:

```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.