diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..bf80165 --- /dev/null +++ b/.gitignore @@ -0,0 +1 @@ +.repo-manager/ 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.** diff --git a/decisions/decisions.md b/decisions/decisions.md new file mode 100644 index 0000000..7b7a020 --- /dev/null +++ b/decisions/decisions.md @@ -0,0 +1,161 @@ +# 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: resolved +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: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. 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..43730a6 --- /dev/null +++ b/history/2026-08-28-security-layer-model-and-gate-house-recut.md @@ -0,0 +1,242 @@ +# 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.