From 9f7df24c735b6e12ed79961ac94e4db2ed2a2842 Mon Sep 17 00:00:00 2001 From: tegwick Date: Fri, 28 Aug 2026 19:55:40 +0200 Subject: [PATCH 1/6] Record security layer model and gate-house re-cut MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Reference note from the 2026-08-28 review of INTENT.md across the security estate. Establishes the four-layer model (taxonomy / tooling / engines / helpers), distinguished by determinism and artifact kind, and its self-similarity to the ASM Canon's three planes. Key finding: gate-house's authority-plane framing places a deterministic decision point inside the non-deterministic management layer, violating INV-02, and collides with flex-auth's declared ownership of authorization. zone-engine §5 already ruled that flex-auth is the only policy decision point. Re-cuts gate-house as the doctrine and conformance council. Not canon and not a decision record; the decisions it recommends still have to be written and assented to. Co-Authored-By: Claude Opus 5 Assistant: claude-code Assistant-Model: opus Assistant-Process: 2564823@bnt-lap001 Assistant-Session: 2a7ed827-4928-4b9f-8613-9135c9cadfe9 --- ...curity-layer-model-and-gate-house-recut.md | 222 ++++++++++++++++++ 1 file changed, 222 insertions(+) create mode 100644 history/2026-08-28-security-layer-model-and-gate-house-recut.md diff --git a/history/2026-08-28-security-layer-model-and-gate-house-recut.md b/history/2026-08-28-security-layer-model-and-gate-house-recut.md new file mode 100644 index 0000000..908df43 --- /dev/null +++ b/history/2026-08-28-security-layer-model-and-gate-house-recut.md @@ -0,0 +1,222 @@ +# 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) | +| **Helpers** | 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. +Helpers 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 +Helpers 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: + +> **Helpers never touch tooling directly. They act only through engine APIs.** + +This is the architectural form of "no privilege from cognition". It is why +kings-guard — agentic, therefore a Helper — 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 Helper 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 Helpers-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 Helpers 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. Open questions, not decided here + +1. **Layer name.** "Helpers" is the working term; it undersells a layer holding + architecture, doctrine, controlling, and change. "Staff" — the general-staff + sense of plans and doctrine without execution — was proposed and fits the + kingdom metaphor. Undecided. +2. **flex-auth reframing.** Renaming to an `*-engine` form is agreed in + principle to make its layer and role legible. The specific name is open: + `auth-` is ambiguous between authentication and authorization, and key-cape + owns authentication, so `auth-engine` preserves the confusion the rename + should remove. `authz-engine` and `access-engine` were the alternatives + raised. **Sequence: reframe the INTENT first, rename second** — the rename + touches `FLEX-WP` prefix ownership, State Hub identifiers, ops-warden's + tables, zone-engine's binding boundary text, and secrets-engine + integrations, so it is a governed migration, not a `git mv`. +3. Whether the layer model itself is written into net-kingdom canon or + info-tech-canon. + +## 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. From 4d913c52fd0c5b69c2372d352a3e7df1c51549b7 Mon Sep 17 00:00:00 2001 From: tegwick Date: Fri, 28 Aug 2026 20:04:57 +0200 Subject: [PATCH 2/6] Record layer-model rulings: Staff, net-kingdom canon, access-engine MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Name the top layer Staff rather than Helpers, throughout. Place the layer model in net-kingdom canon rather than info-tech-canon — it is NetKingdom security architecture, not general semantic contract. Record flex-auth's reframing as an Engine with access-engine as the working rename target, and note the one cost: "access" is already spoken for operationally by ops-warden and ops-mason, so adopting it requires demarcating access lanes from access rules in both INTENTs. Co-Authored-By: Claude Opus 5 Assistant: claude-code Assistant-Model: opus Assistant-Process: 2564823@bnt-lap001 Assistant-Session: 2a7ed827-4928-4b9f-8613-9135c9cadfe9 --- ...curity-layer-model-and-gate-house-recut.md | 68 ++++++++++++------- 1 file changed, 44 insertions(+), 24 deletions(-) diff --git a/history/2026-08-28-security-layer-model-and-gate-house-recut.md b/history/2026-08-28-security-layer-model-and-gate-house-recut.md index 908df43..43730a6 100644 --- a/history/2026-08-28-security-layer-model-and-gate-house-recut.md +++ b/history/2026-08-28-security-layer-model-and-gate-house-recut.md @@ -33,12 +33,12 @@ No code exists in gate-house. The re-cut costs nothing but documents. | **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) | -| **Helpers** | interactive, non-deterministic; management, operations, change, innovation, controlling | specifications, decisions, workplans, tasks | gate-house, ops-mason, ops-warden, kings-guard, whitehat-security | +| **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. -Helpers work through agentic capability — assistants and autonomous agents — +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 @@ -47,7 +47,7 @@ Read by determinism, the layers reproduce the three planes of the Active Secrets Management Canon: ```text -Helpers interactive, non-deterministic ≈ Cognitive Plane +Staff interactive, non-deterministic ≈ Cognitive Plane Engines deterministic APIs ≈ Authority Plane Tooling deterministic state ≈ Execution Plane Taxonomy cross-cutting language @@ -70,19 +70,19 @@ hosts. This is not a turf dispute with `flex-auth`; it is internal incoherence. A taxonomy that only labels decays. The model carries one falsifiable rule: -> **Helpers never touch tooling directly. They act only through engine APIs.** +> **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 a Helper — may contain a threat only by +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 Helper repo holding a direct +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 Helpers-layer sentence, and the only one in the +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 @@ -148,7 +148,7 @@ engine selection, grant storage, and the revocation service. **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 Helpers work; evaluating it deterministically and in-path is Engine +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. @@ -175,23 +175,43 @@ owner. is briefed" is defensible — but only if `INTENT.md` says so in the first paragraph, or every reader re-derives the PDP misreading. -## 9. Open questions, not decided here +## 9. Rulings taken, and what remains open -1. **Layer name.** "Helpers" is the working term; it undersells a layer holding - architecture, doctrine, controlling, and change. "Staff" — the general-staff - sense of plans and doctrine without execution — was proposed and fits the - kingdom metaphor. Undecided. -2. **flex-auth reframing.** Renaming to an `*-engine` form is agreed in - principle to make its layer and role legible. The specific name is open: - `auth-` is ambiguous between authentication and authorization, and key-cape - owns authentication, so `auth-engine` preserves the confusion the rename - should remove. `authz-engine` and `access-engine` were the alternatives - raised. **Sequence: reframe the INTENT first, rename second** — the rename - touches `FLEX-WP` prefix ownership, State Hub identifiers, ops-warden's - tables, zone-engine's binding boundary text, and secrets-engine - integrations, so it is a governed migration, not a `git mv`. -3. Whether the layer model itself is written into net-kingdom canon or - info-tech-canon. +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 From 7f13f7290d972a4e07760974880a4a9f4db5a5c8 Mon Sep 17 00:00:00 2001 From: tegwick Date: Fri, 28 Aug 2026 20:16:31 +0200 Subject: [PATCH 3/6] Rewrite INTENT.md: Gate House as the doctrine council MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Re-cuts Gate House from deterministic authority plane to the Staff-layer council where NetKingdom's security and defence doctrine is established, documented, taught, and supervised. The decisive argument is now stated in the document itself: a decision point inside Gate House would place the deterministic authority boundary inside the non-deterministic management layer, violating INV-02 — the first invariant the repository exists to defend. access-engine (currently flex-auth) stays the only policy decision point. Adds the layer model and the Staff invariant (Staff never touches tooling directly), a corrected responsibility table that names access-engine, zone-engine, and the canon repos, the access lane/rule demarcation with ops-warden and ops-mason, the conformance loop, and falsifiers. Drops the /authorize surface, policy evaluation order, policy engine selection, grant storage, revocation, and the technical direction section. Keeps what no other repo owns: operating modes, the principal/actor/runtime triple, mandates and ceilings, change dynamics, MCP doctrine, the posture asymmetry, and the assurance specifications. Addresses the name/metaphor risk in the opening: the gate house is where the watch is set and the porter's rules are posted, not the gate itself. Co-Authored-By: Claude Opus 5 Assistant: claude-code Assistant-Model: opus Assistant-Process: 2564823@bnt-lap001 Assistant-Session: 2a7ed827-4928-4b9f-8613-9135c9cadfe9 --- INTENT.md | 863 ++++++++++++++++++++---------------------------------- 1 file changed, 322 insertions(+), 541 deletions(-) diff --git a/INTENT.md b/INTENT.md index a60d595..849ead3 100644 --- a/INTENT.md +++ b/INTENT.md @@ -1,49 +1,169 @@ # Gate House — INTENT -**Repository:** `gate-house` -**Project family:** NetKingdom -**Status:** Initial intent -**Date:** 2026-08-24 +**Repository:** `gate-house` +**Project family:** NetKingdom +**Layer:** Staff +**Status:** Re-cut as the security and defence doctrine council +**Version:** 0.2 +**Date:** 2026-08-28 +**Supersedes:** v0.1 (2026-08-24), which framed Gate House as a deterministic authority plane. See `history/2026-08-28-security-layer-model-and-gate-house-recut.md` for why that framing was withdrawn. ## The Mission -> **Gate House establishes and enforces deterministic authority boundaries for human, workload, and agent actions across NetKingdom.** +> **Gate House is the council where NetKingdom's security and defence doctrine is established, documented, taught, and supervised.** -Gate House is the reference implementation of the **Active Secrets Management Plane** defined by the Active Secrets Management Canon. +It is the headquarters of the operational staff that does the chores of IT +security in NetKingdom: the place where the conceptual model of the security +architecture is worked out, written down, taught to the humans and agents who +have to live by it, and checked against what the estate actually does. -Its purpose is deliberately narrow: +A word about the name, because it argues the other way. A gate house sounds +like the thing requests pass through. It is not. In a real castle the gate +house is where the guard is quartered, the watch is set, and the porter's rules +are posted — the rules of entry are decided there, and the gate itself is +somewhere else, held by someone else. That is exactly the split intended here. -> **Nothing crosses a protected boundary without deterministically established authority.** - -Humans and agents may decide what they want to attempt. Adaptive security systems may assess risk and recommend restrictions. Operations systems may know how to execute a change. Secret systems may know how to materialize credentials. - -**Gate House decides whether the requested authority exists, under which conditions, for which actor, on whose behalf, against which resource, for how long, and within which hard limits.** +> **Gate House does not stand in the gate. It decides what the gate is for, who +> may be asked to open it, and how we know it held.** --- -## Why Gate House Exists +## Where Gate House Sits -Agentic development and operations increase the rate, scope, concurrency, and duration of system change. +NetKingdom's IT security is layered by determinism and by the kind of artifact +each layer produces: -Two operating modes are particularly important: +| Layer | Character | Artifacts | Members | +|---|---|---|---| +| **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, access-engine | +| **Staff** | interactive, non-deterministic; management, operations, change, innovation, controlling | specifications, decisions, workplans, tasks | **gate-house**, ops-mason, ops-warden, kings-guard, whitehat-security | -### Agent Assistant Coding +Gate House is Staff. Its outputs are specifications, decisions, workplans, and +tasks, produced through interaction with assistants and autonomous agents. It +holds no state that anything else depends on at runtime. -A human developer or operator is actively engaged with a coding or operations agent and can observe, redirect, approve, or stop actions with human-scale latency. +The layer model carries one rule, and it is the architectural form of "no +privilege from cognition": -The human normally remains the principal and primary accountable operator. +> **Staff never touches tooling directly. It acts only through engine APIs.** -### Autonomous Agent Coding +This is why kings-guard — agentic, therefore Staff — may contain a threat only +by calling an engine, never by reaching into OpenBao itself. It is why an +autonomous coding agent gets no shortcut. And it is checkable: a Staff +repository holding a direct database or OpenBao client is violating the model. -Scheduled, triggered, event-driven, or machine-initiated agents act without continuous human supervision. +--- -They therefore require their own identities, mandates, access profiles, budgets, lifecycle controls, audit trails, and governance boundaries. +## Why Gate House Is Not the Decision Point -Both modes introduce more dynamic system change than human-only operation. Assistant-mode dynamics are partly bounded by human risk appetite and reaction speed. Autonomous-mode dynamics are bounded primarily by policy, organizational governance, runtime constraints, and resource budgets. +Gate House was seeded as a deterministic authority plane — a policy decision +point with an `/authorize` API, grant storage, and a revocation service. That +was wrong, and it was wrong by its own argument: -Neither mode can safely depend on the behavior of an LLM as the final security boundary. +> **A decision point inside Gate House would place the deterministic authority +> boundary inside the non-deterministic management layer, violating INV-02, "No +> Privilege from Cognition" — the first invariant this repository exists to +> defend.** -Gate House exists to provide the deterministic substrate underneath this increasingly dynamic environment. +The repository would have been the clearest available counterexample to the +canon it hosts. NetKingdom already has a policy decision point: `access-engine` +(currently `flex-auth`). It stays the only one. Gate House writes the doctrine +that decision point implements, and checks that it did. + +The boundary, in one line: + +> **The mandate and the operating mode are Gate House's. The decision is +> access-engine's. The credential is secrets-engine's. The perimeter is +> ops-mason's and ops-warden's.** + +--- + +## Responsibility Boundaries + +| Component | Layer | Primary responsibility | Relationship to Gate House | +|---|---|---|---| +| **info-tech-canon** | Taxonomy | semantic contracts, shared terminology | supplies the vocabulary discipline Gate House writes within | +| **net-kingdom canon** | Taxonomy | NetKingdom standards of record | receives Gate House's invariants as canon | +| **key-cape** | Tooling | IAM profile, authentication, federation | establishes authenticated identity | +| **OpenBao** | Tooling | secret storage, leases, PKI, dynamic engines | protects and issues credential material | +| **user-engine** | Engine | users, accounts, memberships | supplies subject context | +| **tenant-engine** | Engine | tenant and organizational boundaries | supplies tenancy context | +| **zone-engine** | Engine | zone identity and membership | supplies zone membership facts | +| **secrets-engine** | Engine | credential abstraction, custody, lifecycle | materializes authority as credentials | +| **access-engine** | Engine | the policy decision — may this actor do this | **the only decision point**; consumes Gate House's authority context and invariants | +| **ops-mason** | Staff | builds and tears down access routes and perimeters | implements the perimeter doctrine | +| **ops-warden** | Staff | operational access lanes, stewardship, runbooks | owns the lanes; Gate House owns the doctrine | +| **kings-guard** | Staff | adaptive defence, observation, containment | supplies posture; bound by the posture asymmetry | +| **whitehat-security** | Staff | offensive validation | executes Gate House's assurance specifications | + +A useful shorthand: + +```text +info-tech-canon names +key-cape authenticates +user/tenant/zone contextualize +access-engine decides +secrets-engine provisions +OpenBao protects +ops-mason builds +ops-warden operates +kings-guard defends +whitehat-security challenges + +gate-house establishes the doctrine all of the above are held to +``` + +Note the two words that must not drift: **ops-warden and ops-mason own access +lanes** — how a worker reaches a host. **access-engine owns access rules** — +whether they may. Gate House owns neither, and says so here because the word +"access" is used for both across the estate. + +--- + +## What Gate House Owns + +- **The doctrine.** The Active Secrets Management Canon, its invariants, and + the argument behind them. Invariants graduate into + `net-kingdom/canon/standards/` as they stabilize; the working canon lives here. +- **The authority context schema.** The vocabulary of an agentic authority + request — principal, actor, runtime identity, tenant, environment, mandate, + task, operating mode — defined here and consumed by access-engine as input + claims. Gate House defines what must be *sayable*; access-engine decides what + it *means* for a given request. +- **The agentic operating modes.** Assistant and autonomous as distinct + security regimes, with the requirements attaching to each. +- **Mandates, authority ceilings, and kill switches** for autonomous actors — + as a model and a governance obligation, not as a runtime service. +- **The Change Dynamics Envelope.** How much change the organization is + prepared to tolerate, expressed so that engines and Staff can bound it. +- **The MCP and tooling doctrine.** Tool availability is not permission. +- **The posture contract** with kings-guard, including the asymmetry. +- **Conformance review.** Whether an actor's authority in practice matches its + declared mandate and ceiling — the observability of governed authority. +- **The assurance specifications** T-01…T-10, executed by whitehat-security. +- **The security curriculum.** What operators, assistants, and autonomous + agents are expected to understand before they are trusted with authority. + +## What Gate House Does Not Own + +Gate House holds no runtime position. It does not own: + +- the authorization decision, policy evaluation, or any `/authorize` surface; +- policy engine selection, policy packages, or policy rollout; +- grant storage, credential issuance, leases, or revocation; +- identity, tenancy, zone, or user lifecycle; +- secret storage, PKI, or scanning; +- anomaly detection, threat intelligence, or behavioral risk inference; +- access lanes, SSH certificates, tunnels, or host hardening; +- deployment, reconciliation, or remediation execution; +- the workplans of other repositories. + +That last one matters. Work structure belongs to the repository doing the work. +Gate House sets doctrine and reviews conformance; it does not accumulate other +repositories' tasks, and an HQ that starts managing the estate's chores has +become a second decision point wearing management clothes. --- @@ -51,573 +171,234 @@ Gate House exists to provide the deterministic substrate underneath this increas > **Cognition proposes. Authority disposes. Infrastructure executes.** -Gate House belongs to the **Authority Plane**. +Read across the layers, that sentence is NetKingdom's layering rule, not only +its security maxim: Staff proposes, Engines dispose, Tooling executes. -It sits between probabilistic/adaptive systems and protected execution systems. +## The Core Security Question + +The doctrine Gate House maintains exists so that, for any privileged action, +the estate can answer: ```text - COGNITIVE PLANE - ┌───────────────────────────────┐ - │ humans │ - │ LLMs │ - │ coding agents │ - │ operations agents │ - │ MCP / A2A tool discovery │ - │ King's Guard risk signals │ - └──────────────┬────────────────┘ - │ requests action - ▼ -════════════════════════════════════════════════ - GATE HOUSE - DETERMINISTIC AUTHORITY PLANE - ┌───────────────────────────────┐ - │ identity context │ - │ principal / actor │ - │ tenant / environment │ - │ mandate / delegation │ - │ resource / action │ - │ policy │ - │ approval │ - │ posture constraints │ - │ TTL / quotas / budgets │ - │ authority ceiling │ - └──────────────┬────────────────┘ - │ grant / deny - ▼ -════════════════════════════════════════════════ - EXECUTION PLANE - ┌───────────────────────────────┐ - │ Git / CI/CD │ - │ Kubernetes │ - │ cloud APIs │ - │ databases │ - │ SaaS APIs │ - │ production services │ - └───────────────────────────────┘ +WHO principal, actor, runtime identity +WHERE tenant, environment, zone, resource +WHAT requested operation +WHY task, mandate, delegation +UNDER WHICH policy, approval, posture, quotas, budgets +UNTIL WHEN TTL / expiry +→ a deterministic decision, rendered by access-engine, reconstructable afterwards ``` ---- - -## Core Security Invariant - -> **No protected action succeeds merely because an intelligent system believes it should.** - -For every privileged action, Gate House should be able to evaluate a request equivalent to: - -```text -WHO - principal - actor - runtime identity - -WHERE - tenant - environment - resource - -WHAT - requested operation - -WHY - task - mandate - delegation - -UNDER WHICH CONDITIONS - policy - approval - security posture - quotas - budgets - -UNTIL WHEN - TTL / expiry - -→ deterministic GRANT or DENY -``` - -For the same authoritative input state, the decision must be reproducible and auditable. - -Deterministic does **not** mean static. Context may change continuously. Risk posture, approvals, resource ownership, incident state, tenancy, time, and quotas may all influence authorization. The rule is that the final privilege boundary is enforced by explicit policy rather than probabilistic model judgment. +Deterministic does not mean static. Context changes continuously. The rule is +that the final privilege boundary is enforced by explicit policy rather than +model judgment, and that the same authoritative input state yields the same +decision. --- -## Gate House Does +## Domain Vocabulary -Gate House should: +Gate House owns these terms. Other repositories should use them rather than +synonyms: -- receive authenticated identity and context from trusted upstream systems; -- distinguish **principal**, **actor**, and **runtime identity**; -- evaluate deterministic authorization policy; -- enforce authority ceilings; -- model delegation and attenuation; -- issue or represent narrowly scoped, time-bounded authority; -- bind authority to tenant, environment, resource, action, task, and conditions; -- require step-up or parameter-bound approval for sensitive operations; -- expose machine-verifiable grant/deny decisions; -- coordinate credential materialization through the Secrets Engine and secret backends; -- accept bounded security-posture inputs from King's Guard; -- support deterministic circuit breakers and emergency revocation; -- produce authoritative audit evidence; -- preserve policy and decision versioning; -- fail closed for security-critical ambiguity or unavailable authority state; -- provide reusable policy and execution interfaces for NetKingdom tools. - ---- - -## Gate House Does Not - -Gate House should deliberately **not** become a security super-system. - -It does not own: - -- primary human identity lifecycle; -- tenant lifecycle; -- identity-provider federation; -- password or secret storage; -- PKI implementation; -- secret scanning; -- anomaly detection; -- threat intelligence; -- behavioral risk inference; -- vulnerability scanning; -- penetration testing; -- infrastructure reconciliation; -- deployment execution; -- incident investigation; -- autonomous remediation; -- security learning or adaptive threat modeling. - -Those responsibilities belong elsewhere in NetKingdom. - ---- - -## Responsibility Boundaries - -| Component | Primary responsibility | Relationship to Gate House | -|---|---|---| -| **User Engine** | users, subjects, memberships, identity lifecycle | supplies subject context | -| **Tenant Engine** | tenant and organizational boundaries | supplies tenancy context | -| **Key Cape** | authentication, federation, identity assertions | establishes authenticated identity | -| **Gate House** | deterministic authority and delegation | decides what may happen | -| **Secrets Engine** | credential abstraction, dynamic issuance, rotation/revocation orchestration | materializes granted authority as credentials | -| **OpenBao** | secure secret storage, leases, PKI, dynamic secret engines | protects and issues credential material | -| **Ops Warden** | bounded operational execution | executes authorized operations | -| **Ops Mason** | construction, reconciliation, reconstitution | builds or restores authorized state | -| **King's Guard** | adaptive observation, risk assessment, containment coordination, security memory | supplies posture and defensive constraints | -| **Whitehat Security** | adversarial testing and attack simulation | challenges Gate House assumptions and controls | - -A useful shorthand is: - -```text -User Engine identifies -Tenant Engine contextualizes -Key Cape authenticates - -Gate House authorizes - -Secrets Engine provisions -OpenBao protects - -Ops Warden operates -Ops Mason constructs / restores - -King's Guard observes / defends / adapts -Whitehat Security attacks / validates -``` - ---- - -## Relationship to King's Guard - -King's Guard is intentionally more ambitious than Gate House. - -King's Guard is an adaptive security control system: - -```text -declare healthy intent -→ establish and attest identity -→ observe actual behavior -→ compare behavior with policy and intended scope -→ assess risk and confidence -→ respond within bounded authority -→ restore known-good operation -→ validate the outcome -→ retain governed security memory -``` - -Gate House is the deterministic boundary through which King's Guard's defensive intent must pass. - -A critical asymmetry applies: - -> **Adaptive systems may automatically reduce authority, require stronger authorization, or request containment. They must not probabilistically manufacture additional authority.** - -For example: - -```text -King's Guard posture = DEGRADED - │ - ▼ -Gate House policy: - deny production.write - allow production.read - require step-up for staging.write -``` - -King's Guard detects and reasons about risk. - -Gate House defines what that risk posture means for authority. - ---- - -## Relationship to Secrets Engine and OpenBao - -Gate House should separate **authority** from **credential material**. - -Example: - -```text -Agent: -"I need SELECT on orders-prod for task T" - │ - ▼ - Gate House - │ - deterministic decision - │ - GRANT: - action = SELECT - resource = orders-prod - ttl = 15m - │ - ▼ - Secrets Engine - │ - determine credential mechanism - │ - ▼ - OpenBao - │ - create / lease DB credential - │ - ▼ - execution gateway -``` - -**Gate House decides the authority.** - -**Secrets Engine determines how that authority is materialized.** - -**OpenBao securely protects and issues the credential material.** - -The credential is an implementation artifact of authority, not the source of authority. - ---- - -## Domain Concepts - -Gate House should keep a small, explicit domain model. - -- **Principal** — the human, organization, workload, or system on whose behalf authority originates. +- **Principal** — the human, organization, workload, or system on whose behalf + authority originates. - **Actor** — the entity directly attempting the action. - **Runtime Identity** — the concrete workload instance performing execution. -- **Mandate** — standing organizational authorization defining what an autonomous actor is intended to do. -- **Delegation** — a scoped transfer of authority without collapsing principal and actor identity. -- **Authority Ceiling** — the maximum authority an actor can obtain under deterministic policy. -- **Grant** — a positive authorization decision scoped by action, resource, context, and time. -- **Denial** — a negative authorization decision with machine-readable reason and evidence. -- **Approval** — an independent authorization artifact required for actions exceeding normal policy. -- **Posture** — a bounded security-state input, normally supplied by King's Guard or another trusted source. -- **Credential Binding** — the mapping from an authority grant to the technical credential required by the target system. -- **Decision Evidence** — the record explaining which policy, identities, inputs, and conditions produced the decision. - ---- - -## Preferred Authority Pattern - -A privileged action should be reconstructable approximately as: - -```text -principal: alice@example -actor: deploy-agent-22 -runtime: spiffe://netkingdom/prod/deployer/22 -tenant: tenant/acme -task: deploy release 7.2.1 -action: production.deploy -resource: cluster/payments -mandate: release-automation -approval: approval-9432 -policy_version: authz-2026-08-24 -authority_ttl: 20m -credential_type: aws-sts -decision: GRANT -``` - -Not every field must live inside a single token. The system must preserve enough linked evidence to reconstruct the authority chain. - ---- - -## Core Rules - -1. **No privilege from cognition.** -2. **Every privileged action crosses a deterministic authority boundary.** -3. **Tool availability is not permission.** -4. **Principal and actor remain distinguishable.** -5. **Assistant and Autonomous operation are different security modes.** -6. **Autonomous agents use independent identities and explicit mandates.** -7. **Authority is least-privileged, task-scoped, tenant-scoped, environment-scoped, and time-bounded wherever possible.** -8. **Delegation attenuates.** -9. **Security posture may reduce authority but must not probabilistically expand it.** -10. **Emergency revocation works without agent cooperation.** -11. **Agents do not casually modify the policies defining their own authority ceiling.** -12. **Credentials are preferably ephemeral implementation artifacts of authorization.** -13. **Audit evidence is protected from the actor being audited.** -14. **Failure of critical policy or authorization dependencies fails closed.** -15. **Production security guarantees must survive incorrect agent behavior.** +- **Mandate** — standing organizational authorization defining what an + autonomous actor is intended to do. +- **Delegation** — a scoped transfer of authority that does not collapse + principal and actor. +- **Authority Ceiling** — the maximum authority an actor can obtain. +- **Operating Mode** — assistant or autonomous; a security regime, not a + deployment detail. +- **Posture** — a bounded security-state input from a trusted source. +- **Change Dynamics Envelope** — the tolerated rate, scope, concurrency, and + duration of change. +- **Decision Evidence** — the record explaining which policy, identities, + inputs, and conditions produced a decision. --- ## Agentic Operating Modes -### Agent Assistant Profile +The distinction Gate House exists to keep sharp. -```text -human principal - ↓ -interactive assistant session - ↓ -agent actor - ↓ -Gate House - ↓ -restricted authority - ↓ -execution -``` +### Assistant -The human's credentials should not simply be dumped into the agent environment. Selective delegation, short-lived sessions, explicit tooling boundaries, and production-side controls remain required. +A human is actively engaged and can observe, redirect, approve, or stop actions +at human latency. The human remains the principal; the agent remains a visible +actor. The human's credentials are not dumped into the agent's environment. -Human disconnect must not silently transform the session into autonomous privileged operation. +**A human disconnecting must never silently promote the session into autonomous +privileged operation.** -### Autonomous Agent Profile +### Autonomous -```text -governance mandate - ↓ -agent identity - ↓ -task context - ↓ -Gate House - ↓ -time-bounded authority - ↓ -execution - ↓ -independent audit -``` - -Autonomous agents require unique identity, named owner, explicit mandate, authority ceiling, environment and resource bounds, time limits, concurrency limits, token/compute/tool budgets, independent kill switch, lifecycle termination, and audit reconstruction. +A scheduled, triggered, or event-driven agent acts without continuous +supervision. Bounded by policy and governance rather than by human reaction +time, it requires: unique identity; a named owner; an explicit mandate; an +authority ceiling; environment and resource bounds; runtime and concurrency +limits; credential TTL; token, compute, and tool-call budgets; an independent +kill switch; lifecycle termination; and audit reconstruction. --- ## Change Dynamics -Gate House should explicitly support a **Change Dynamics Envelope**. +Agentic systems change infrastructure faster than humans can review. The +envelope names what the organization will tolerate: concurrent mutating actors, +actions per grant, resources per task, task duration, credential TTL, agent +chain depth, deployment frequency, destructive-action quota, compute and token +spend, read/write separation, reversible versus irreversible action classes. -The envelope defines the maximum rate, scope, duration, and concurrency of system change the organization is prepared to tolerate while preserving required invariants. - -Possible constraints include: - -- maximum concurrent mutating agents; -- maximum resources per grant; -- maximum destructive actions; -- maximum deployment frequency; -- maximum task duration; -- credential TTL; -- maximum agent-chain depth; -- maximum tool calls; -- token and compute budgets; -- environment restrictions; -- read/write separation; -- reversible versus irreversible action classes. - -Economic budgets are useful blast-radius controls but never authorization substitutes. - ---- - -## Circuit Breakers - -Gate House should make autonomous degradation simple and deterministic. - -```text -NORMAL - ↓ -risk / anomaly / velocity threshold crossed - ↓ -AUTONOMOUS WRITE DISABLED - ↓ -READ / DIAGNOSE REMAINS AVAILABLE - ↓ -STEP-UP OR HUMAN INTERVENTION REQUIRED -``` - -Safe degraded mode should normally remove mutation authority before observability. - ---- +Economic budgets are useful blast-radius controls. **They are never +authorization.** ## MCP and Tooling Doctrine -MCP is a capability interface, not an authority system. +MCP is a capability interface, not an authority system. A declared tool means +the operation exists — nothing more. Invocation still requires a decision from +access-engine or equivalent resource-side enforcement. Token passthrough is to +be avoided; downstream authority is separately issued and bound to the correct +resource. -A tool declaration such as: +## Posture and King's Guard + +King's Guard observes, assesses, and publishes bounded posture. Gate House +defines what a posture *means* for authority, and access-engine renders it. + +> **Adaptive systems may automatically reduce authority, require stronger +> authorization, or request containment. They must not probabilistically +> manufacture additional authority.** + +## Authority and Credentials + +Authority and credential material are separate concerns. Gate House's doctrine +holds that a credential is an implementation artifact of an authorization, not +its source: access-engine decides, secrets-engine determines how the authority +is materialized, OpenBao protects and issues the material, and the raw +credential never enters model context. + +--- + +## Core Rules + +The doctrine, in fifteen lines. Gate House authors and maintains these; the +engines and Staff repositories implement them. + +1. **No privilege from cognition.** +2. **Every privileged action crosses a deterministic authority boundary.** +3. **Tool availability is not permission.** +4. **Principal and actor remain distinguishable.** +5. **Assistant and autonomous operation are different security modes.** +6. **Autonomous agents use independent identities and explicit mandates.** +7. **Authority is least-privileged, task-, tenant-, environment-scoped, and time-bounded.** +8. **Delegation attenuates.** +9. **Security posture may reduce authority but must not expand it.** +10. **Emergency revocation works without agent cooperation.** +11. **Agents do not casually modify the policies defining their own authority ceiling.** +12. **Credentials are ephemeral implementation artifacts of authorization.** +13. **Audit evidence is protected from the actor being audited.** +14. **Failure of critical policy or authorization dependencies fails closed.** +15. **Production guarantees must survive incorrect agent behavior.** + +--- + +## Reference Scenarios + +These are not implementation milestones. They are the situations the estate as +a whole must handle correctly, and the basis of the assurance specifications +whitehat-security executes. + +- **UC-01 — Human-assisted read.** A coding agent requests read-only + diagnostics. Human principal preserved, agent actor identifiable, no mutation + authority, tool use auditable. +- **UC-02 — Autonomous release.** A scheduled agent deploys an approved + artifact under an explicit mandate, with workload identity, short TTL, no + policy-modification rights, and full provenance. +- **UC-03 — Dynamic database access.** Temporary scoped access is authorized, + materialized as a leased credential, expires automatically, and never reaches + model context. +- **UC-04 — Containment.** King's Guard publishes degraded posture; write + authority is removed deterministically; ops-warden performs authorized + containment; the audit chain stays intact. +- **UC-05 — Self-escalation attempt.** An agent tries to widen the policy + constraining itself. The attempt is denied and becomes high-value security + telemetry. + +## The Conformance Loop + +Doctrine that no engine implements is fiction. Gate House is only real if the +loop closes: ```text -restart_service() -rotate_database_password() -delete_namespace() +gate-house asserts an invariant + ↓ +access-engine and the engines implement it + ↓ +whitehat-security tries to break it + ↓ +kings-guard observes it in operation + ↓ +findings return to gate-house as doctrine change ``` -means only that the operation exists. - -Invocation still requires Gate House policy evaluation or equivalent resource-side enforcement. - -Token passthrough should be avoided. Downstream authority should be separately issued or exchanged and bound to the correct resource. +Gate House's own health is measured by that loop turning, not by the volume of +documents it produces. --- -## Technical Direction +## What Would Make This Repository Wrong -Gate House should be designed as a small, composable control plane rather than a monolith. +Stated up front, because a repository re-cut on an argument should say what +would falsify it: -Likely implementation areas include: +- **It becomes a second decision point.** The failure would not announce + itself; it would arrive as a small convenience — a schema that starts + resolving, a conformance check that starts gating in-path. +- **It becomes a paper generator.** Doctrine accumulates, the conformance loop + never turns, and no engine's behavior can be traced to anything written here. +- **Nobody adopts the vocabulary.** If access-engine, ops-warden, and + kings-guard do not speak in principal/actor/mandate/mode, the model is a + preference rather than a contract. +- **The modes do not distinguish anything.** If assistant and autonomous + operation end up with the same controls in practice, the central distinction + was decoration. +- **It absorbs other repositories' work.** Workplans for engines start landing + here. -- canonical authorization request schema; -- policy-decision API; -- principal/actor/delegation model; -- policy-engine abstraction; -- grant representation; -- approval binding; -- posture input model; -- authority ceilings; -- quota and time constraints; -- credential-binding interface to Secrets Engine; -- execution-gateway integration; -- audit/event schema; -- decision replay and explainability; -- emergency revocation; -- agentic security test harness. +## Success Criteria -Potential policy backends may include OPA/Rego, Cedar, native policy evaluators, or multiple pluggable engines. Gate House should not make the conceptual model depend on one policy implementation. +Gate House is working when: ---- - -## First Reference Use Cases - -### UC-01 — Human-Assisted Read - -A human operates a coding agent that requests read-only Kubernetes diagnostics. - -Expected outcome: - -- human principal preserved; -- agent actor identifiable; -- time-bounded grant; -- no production mutation capability; -- decision and tool use auditable. - -### UC-02 — Autonomous CI Deployment - -A scheduled release agent deploys an approved artifact. - -Expected outcome: - -- independent workload identity; -- explicit release mandate; -- workload-federated authentication; -- environment-bound deploy authority; -- short TTL; -- no IAM/policy modification rights; -- full provenance from source to deployment. - -### UC-03 — Dynamic Database Access - -An agent requests temporary database read access. - -Expected outcome: - -- Gate House grants scoped authority; -- Secrets Engine maps authority to dynamic DB credentials; -- OpenBao issues leased credential; -- credential expires/revokes automatically; -- raw credential is not placed in model context. - -### UC-04 — King's Guard Containment - -King's Guard detects degraded posture for an autonomous actor. - -Expected outcome: - -- King's Guard publishes bounded posture; -- Gate House deterministically removes write authority; -- Ops Warden performs authorized containment; -- King's Guard validates outcome; -- audit chain remains intact. - -### UC-05 — Policy Self-Escalation Attempt - -An autonomous agent attempts to modify the policy constraining its own access. - -Expected outcome: - -- request denied or requires a separately governed authority path; -- event becomes high-value audit/security telemetry. - ---- - -## Initial Success Criteria - -Gate House is useful when it can demonstrate that: - -1. human and agent identities remain distinguishable; -2. Assistant and Autonomous sessions use different authority profiles; -3. a model cannot grant itself additional privilege; -4. protected operations are decided by reproducible policy; -5. authority can be narrower and shorter-lived than the actor identity; -6. secrets can be materialized only after authority exists; -7. security posture can deterministically restrict authority; -8. autonomous agents can be stopped independently; -9. policy self-modification is constrained; -10. every privileged action can be reconstructed from audit evidence; -11. the system remains secure under deliberately incorrect agent behavior. - ---- +1. human and agent identities remain distinguishable across the estate; +2. assistant and autonomous sessions demonstrably carry different authority; +3. no model can grant itself privilege; +4. protected operations are decided by reproducible policy in access-engine; +5. authority is narrower and shorter-lived than the actor identity; +6. secrets are materialized only after authority exists; +7. posture deterministically restricts authority and never expands it; +8. autonomous agents can be stopped independently of their own cooperation; +9. every privileged action can be reconstructed from audit evidence; +10. the estate remains secure under deliberately incorrect agent behavior; +11. the conformance loop turns, and doctrine changes as a result. ## Long-Term Direction -Gate House should mature from a reference Active Secrets Management Plane into NetKingdom's reusable **deterministic authority substrate**. +Gate House matures from a working canon into NetKingdom's standing security +council: the place where the security model is argued out, ratified into +net-kingdom canon, taught to everyone who operates in the kingdom, and +continuously tested against what the estate really does. -The mature system should make it natural to express: - -> Who or what is acting? -> On whose behalf? -> In which tenant and environment? -> Under what mandate? -> Against which resource? -> For which action? -> Under which constraints? -> Until when? -> According to which policy? -> With which evidence? - -and return a machine-enforceable answer. - -The end state is not a larger secrets manager. - -It is a system in which **standing secrets and standing authority progressively disappear**, while authorization becomes explicit, scoped, ephemeral, explainable, and governable. +The end state is not a larger secrets manager, and not a control plane. It is +an estate in which standing secrets and standing authority progressively +disappear, authorization is explicit, scoped, ephemeral, and explainable — and +in which someone is responsible for keeping it that way. --- ## Motto -> **Agents decide what to attempt. Gate House decides what may cross the boundary.** +> **Agents decide what to attempt. Engines decide what may cross the boundary. +> Gate House decides what the boundary is for.** From d9b52dfda1f5679f50c960404d487160d163198a Mon Sep 17 00:00:00 2001 From: repo-manager Date: Fri, 28 Aug 2026 21:15:15 +0200 Subject: [PATCH 4/6] repo.work.create_decision GH-DEC-2026-001 correlation_id: 7ac7bd1d-2de1-4158-997a-d7b4bb2fb0d5 reason: Ratify the three linked rulings from the 2026-08-28 security estate review source: repo-manager Assistant: claude-code Assistant-Model: opus Assistant-Process: 2564823@bnt-lap001 Assistant-Session: 2a7ed827-4928-4b9f-8613-9135c9cadfe9 --- decisions/decisions.md | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) create mode 100644 decisions/decisions.md diff --git a/decisions/decisions.md b/decisions/decisions.md new file mode 100644 index 0000000..fa2ae2c --- /dev/null +++ b/decisions/decisions.md @@ -0,0 +1,30 @@ +# Decision records + +## GH-DEC-2026-001 — NetKingdom security layer model, the gate-house re-cut, and the access-engine reframing + +```yaml +id: GH-DEC-2026-001 +kind: decision +title: NetKingdom security layer model, the gate-house re-cut, and the access-engine + reframing +status: open +owner: Bernd Worsch +repo: gate-house +standard: net-kingdom/canon/standards/security-layer-model_v0.1.md +source_note: history/2026-08-28-security-layer-model-and-gate-house-recut.md +requested_dispositions: +- approved +- revised +- rejected +affects: +- gate-house +- flex-auth +- ops-warden +- ops-mason +- kings-guard +- whitehat-security +- net-kingdom +- zone-engine +created: '2026-08-28T19:15:15.607849Z' +updated: '2026-08-28T19:15:15.607849Z' +``` From f861f45ca2d6def3ff1f30eb5f8218f20af36b76 Mon Sep 17 00:00:00 2001 From: repo-manager Date: Fri, 28 Aug 2026 21:16:01 +0200 Subject: [PATCH 5/6] repo.work.resolve_decision GH-DEC-2026-001 correlation_id: 18f20bc4-d273-4697-9bd0-c2e43536cd36 reason: Ratify the 2026-08-28 layer model rulings source: repo-manager Assistant: claude-code Assistant-Model: opus Assistant-Process: 2564823@bnt-lap001 Assistant-Session: 2a7ed827-4928-4b9f-8613-9135c9cadfe9 --- decisions/decisions.md | 135 ++++++++++++++++++++++++++++++++++++++++- 1 file changed, 133 insertions(+), 2 deletions(-) diff --git a/decisions/decisions.md b/decisions/decisions.md index fa2ae2c..7b7a020 100644 --- a/decisions/decisions.md +++ b/decisions/decisions.md @@ -7,7 +7,7 @@ id: GH-DEC-2026-001 kind: decision title: NetKingdom security layer model, the gate-house re-cut, and the access-engine reframing -status: open +status: resolved owner: Bernd Worsch repo: gate-house standard: net-kingdom/canon/standards/security-layer-model_v0.1.md @@ -26,5 +26,136 @@ affects: - net-kingdom - zone-engine created: '2026-08-28T19:15:15.607849Z' -updated: '2026-08-28T19:15:15.607849Z' +updated: '2026-08-28T19:16:01.456127Z' +rationale: 'Approved in session on 2026-08-28. The three rulings were taken interactively: + Staff as the layer name, net-kingdom canon as the model''s home, and access-engine + as the rename target with the lane/rule demarcation accepted as its cost. Approval + covers the doctrine and documents only; the flex-auth rename remains a separate + governed migration, and the standard stays proposed pending assent from flex-auth, + kings-guard, and ops-warden.' +decided_by: Bernd Worsch +decided_at: '2026-08-28T19:16:01.456127Z' ``` + +## Context + +The security estate acquired overlapping claims to the same responsibility, and +the overlap was invisible in each repository's own documents. `gate-house` was +seeded as a deterministic authority plane — a policy decision point with an +`/authorize` API, grant storage, and a revocation service — while `flex-auth` +already described itself as the authorization control plane and was actively +delivering `FLEX-WP-0017`, an approval contract binding approvals to action, +actor, target, and validity window. Neither repository's INTENT named the other. +`zone-engine` had already been ruled against on the same question. + +Full review and evidence: `history/2026-08-28-security-layer-model-and-gate-house-recut.md`. + +## Decision requested + +Ratify three linked rulings. They are one decision because the second does not +hold without the first, and the third is the first applied to the repository +that was already right. + +### Ruling 1 — Adopt the NetKingdom security layer model + +The estate is layered **Taxonomy → Tooling → Engines → Staff**, distinguished by +determinism and by the kind of artifact each layer produces. The top layer is +named **Staff** — the general-staff sense of plans and doctrine without +execution — not "Helpers", which undersold a layer holding architecture, +controlling, and change. + +The model is published as `net-kingdom/canon/standards/security-layer-model_v0.1.md`, +owned by gate-house, status `proposed`. It belongs in net-kingdom canon rather +than info-tech-canon because it is NetKingdom-flavored security architecture, +not general semantic contract. + +It carries two normative rules: + +- **Staff never touches Tooling directly. It acts only through Engine APIs.** +- **`access-engine` is the only policy decision point**, generalizing to the + whole estate the ruling first drawn in `zone-engine/INTENT.md` §5. + +### Ruling 2 — Re-cut gate-house as the doctrine council + +Gate House is Staff: the council where NetKingdom's security and defence +doctrine is established, documented, taught, and supervised. It holds no +runtime position. + +The decisive argument is gate-house's own: **a decision point inside gate-house +would place the deterministic authority boundary inside the non-deterministic +management layer, violating INV-02 — the first invariant the repository exists +to defend.** The repository would have been the clearest available +counterexample to the canon it hosts. + +Boundary: *the mandate and the operating mode are gate-house's; the decision is +access-engine's; the credential is secrets-engine's; the perimeter is +ops-mason's and ops-warden's.* + +gate-house keeps what no other repository owns — the operating modes, the +principal/actor/runtime triple, mandates and authority ceilings, the change +dynamics envelope, the MCP doctrine, the posture asymmetry, the assurance +specifications, and the curriculum. It gives up `/authorize`, policy evaluation, +policy engine selection, grant storage, and revocation. + +### Ruling 3 — Reframe flex-auth as an Engine and rename it access-engine + +`flex-auth` is Engine-layer and remains the only policy decision point. It is +renamed **`access-engine`**. `auth-engine` was rejected: key-cape owns +authentication, and `auth-` preserves the ambiguity the rename exists to remove. +`permission-engine` was rejected as ageing badly against a future `role-engine`. + +The name's one cost is that "access" is already spoken for operationally by +ops-warden and ops-mason. It is paid by a demarcation, now normative in §8 of +the standard: **ops-warden and ops-mason own access lanes — how a worker reaches +a host; access-engine owns access rules — whether they may.** + +Sequence is binding: **reframe the INTENT first, rename second**, as a governed +migration. The rename touches `FLEX-WP` prefix ownership, State Hub identifiers, +ops-warden's routing tables, zone-engine's binding boundary text, and +secrets-engine integrations. + +The reframing also splits a responsibility flex-auth currently holds whole: +**authoring and governing policy is Staff work (gate-house); evaluating it +deterministically and in-path is access-engine's, exclusively.** This is the +constructive resolution of the `FLEX-WP-0017` overlap — gate-house designs the +approval contract, access-engine validates approvals at decision time. + +## What approval authorizes + +- Publication of the layer model as a proposed net-kingdom standard. +- The gate-house INTENT re-cut, already applied at `7f13f72`. +- The layering review notes placed at the top of twelve estate INTENT files. +- Starting the flex-auth INTENT reframe. +- Retiring the gate-house artifacts that describe an engine: ADR-003 (policy + engine selection), milestones M0, M3, and M4, and `GH-WP-0001-T04` + (`/authorize` skeleton). `GH-WP-0001` is rewritten against the re-cut before + it is promoted to active. + +## What approval does not authorize + +- The `flex-auth` → `access-engine` rename itself. That is a separate governed + migration with its own record, and it must not begin before the INTENT + reframe lands. +- Any change to `zone-engine`'s 2026-08-23 disposition. +- Promoting the standard from `proposed` to `accepted`. +- Any change to another repository's workplans. Work structure stays with the + repository doing the work. + +## Assent still required + +Two adaptations move vocabulary away from repositories that currently use it, +and follow the estate's precedent that a boundary is drawn on review by the +other side rather than asserted — as flex-auth did to zone-engine: + +1. **flex-auth** — Engine framing, the rename, and the authoring/evaluation split. +2. **kings-guard** and **ops-warden** — releasing "control plane" and the + security curriculum respectively to the layers that own them. + +## Reversal + +The rulings are documents; nothing executable depends on them yet, and no code +exists in gate-house. Reversal is reverting the INTENT and standard commits. +The falsifiers that should trigger reconsideration are in +`gate-house/INTENT.md` § "What Would Make This Repository Wrong" — principally +gate-house becoming a paper generator whose conformance loop never turns, or +the estate declining to adopt the authority vocabulary. From a7d11914d7ea3d286ba8679102f62b2d51d3a203 Mon Sep 17 00:00:00 2001 From: tegwick Date: Fri, 28 Aug 2026 21:16:19 +0200 Subject: [PATCH 6/6] Ignore local repo-manager index .repo-manager/index.json is a rebuildable local cache written by rmgr, not repository state. repo-manager gitignores its own; match that. Co-Authored-By: Claude Opus 5 Assistant: claude-code Assistant-Model: opus Assistant-Process: 2564823@bnt-lap001 Assistant-Session: 2a7ed827-4928-4b9f-8613-9135c9cadfe9 --- .gitignore | 1 + 1 file changed, 1 insertion(+) create mode 100644 .gitignore diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..bf80165 --- /dev/null +++ b/.gitignore @@ -0,0 +1 @@ +.repo-manager/