gate-house/INTENT.md

---
# NetKingdom security layer declaration — §11.
#
# This is the declaration. The prose "**Layer:** Staff" below is not, and has not
# been since §11 required a machine-readable form; it is exactly what §11's
# declaration-form paragraph says does not count, written by the repository that
# wrote the paragraph. Raised by access-engine (FLEX-WP-0030, B2) and ruled in
# GH-DEC-2026-017 §6.
#
# No layer.yaml accompanies this file, by GH-DEC-2026-017 §1: INTENT.md governs
# and a sidecar is a derived artifact. No standard version appears here, by
# GH-DEC-2026-017 §5: the declared layer is a standing property and does not
# change when the standard is revised. Version-scoped state belongs in the
# derived conformance record.
layer: Staff
role: —
repository: gate-house
declared_by: INTENT.md
declared_at: "2026-09-21"
ruling: GH-DEC-2026-017
# §5 — Staff MUST NOT hold a direct Tooling client. Empty is a claim, not an
# omission: gate-house holds no OpenBao, key-cape or cluster client. Its
# artifacts are specifications, decisions, workplans and tasks.
tooling_contacts: []
# §11 — non-Tooling clients recorded so the check is total.
non_tooling_clients:
  - target: state-hub
    layer: not-catalogued
    rationale: >-
      Work records, intakes, decisions and progress events. Outside §5 by the
      v0.5 scope rule — "Tooling-layer system" means a §4 Tooling row, and
      state-hub is not one. Recorded, not policed.
declared_shapes:
  "5.1": []
  "5.2": []
  "5.3": []
---

# Gate House — INTENT

**Repository:** `gate-house`
**Project family:** NetKingdom
**Layer:** Staff
**Status:** Re-cut as the security and defence doctrine council
**Version:** 0.3
**Date:** 2026-09-10
**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 is the council where NetKingdom's security and defence doctrine is established, documented, taught, and supervised.**

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.

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.

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

---

## Where Gate House Sits

NetKingdom's IT security is layered by determinism and by the kind of artifact
each layer produces:

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

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.

The layer model carries one rule, and it is the architectural form of "no
privilege from cognition":

> **Staff never touches tooling directly. It acts only through engine APIs.**

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.

---

## Why Gate House Is Not the Decision Point

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:

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

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.

---

## Foundational Principle

> **Cognition proposes. Authority disposes. Infrastructure executes.**

Read across the layers, that sentence is NetKingdom's layering rule, not only
its security maxim: Staff proposes, Engines dispose, Tooling executes.

## The Core Security Question

The doctrine Gate House maintains exists so that, for any privileged action,
the estate can answer:

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

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.

---

## Domain Vocabulary

Gate House owns these terms. Other repositories should use them rather than
synonyms:

- **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 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

The distinction Gate House exists to keep sharp.

### Assistant

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.

**A human disconnecting must never silently promote the session into autonomous
privileged operation.**

### Autonomous

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

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.

Economic budgets are useful blast-radius controls. **They are never
authorization.**

## MCP and Tooling Doctrine

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.

## 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 seventeen 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.**
16. **Where one appearance is reachable by two routes, the record says which route** — and A-16 is only as strong as the marker-writer's independence from what the marker asserts.
17. **A transitional deviation is admissible only where it fails closed on the case that distinguishes it from the conformant state** — and where that case is not observable, making it observable is a precondition rather than an outcome.

**On rules 16 and 17, which are newer than the rest.** Both were derived in
September 2026 from rulings that kept arriving at the same shape, and they are
stated here because a property recorded only against the instance that produced it
is found by accident or not at all — the failure this repository has now corrected
in other repositories three times.

**Rule 16** is the more load-bearing. Its instances so far: a stance map where
`unknown` and `absent` fail closed identically but mean different things
(`GH-DEC-2026-011`); a `tenant` claim that reads the same whether the directory
asserted it about the person or a client registration supplied it
(`GH-DEC-2026-013`); an evidence path where *erased* and *never held* both present
as a blank (`GH-DEC-2026-014`); and a decision envelope that looks identical
whether `access-engine` issued it or a responder forged it (`GH-DEC-2026-010`).
In each, a sound check is read as establishing a property it does not carry,
because the appearance the check produces is reachable two ways. The rule is not
that the two routes must behave differently — usually they must behave identically,
and safely. It is that the **record** must distinguish them, or the safer reading of
the appearance becomes unavailable to every later reader.

**The rider matters as much as the rule.** Where the route marker is written by the
party whose conduct the route describes, rule 16 constrains a defect but not an
adversary. `informed-decision` raised this against its own instance — the weakest
of the four, an *erased*-versus-*never-held* marker written by the party the
evidence is about — and it is the difference between a rule and a reassurance.

**Rule 17** governs what may enter a declared-gap register. It exists because two
requests for transitional relief arrived in one week and had to be answered
oppositely without the answers looking arbitrary: `ops-warden`'s dated transitional
`unknown: fail_open` was declined (`GH-DEC-2026-011`) and `key-cape`'s
registration-bound tenant was granted (`GH-DEC-2026-013`). The distinguishing
question is not how careful the design is or how long the transition lasts, but
which way it fails on the case that separates it from the conformant state. A
promise that fails open is a permission; a promise that fails closed is a gap; only
the second is a thing a register can hold.

**Rule 17 depends on rule 16**, which was not noticed when either was written. The
question *"which way does it fail"* is unanswerable where the case cannot be seen,
so an unobservable distinguishing case must be made observable before rule 17 is
applied at all — otherwise the rule admits anything merely invisible, which reads
as failing closed because nothing visibly fails. Raised by `informed-decision`
from the instance it bears, which is also the instance where this repository
manufactured a failure direction while believing it had tested one.

Neither rule has graduated to `net-kingdom/canon/standards/`. They are Gate House
doctrine at repository level until they have been argued by a repository that bears
a cost under them — which is how `security-layer-model` earned its acceptance and is
the bar these have not yet met.

**A bound on rule 13, and on every claim that rests on audit.** An append-only
archive with a verified hash chain proves records were not *altered or truncated
after arrival*. It cannot prove a record was never sent. A suppressed event
leaves the chain intact and verification reports intact — and the event an
adversary most wants missing is the negative one: a revocation, a denial, a
containment action.

So *"the audit record proves it happened"* is unsound. The sound form is *"the
archive proves the records it holds were not altered or truncated after
arrival"*. Completeness is the emitting system's obligation, discharged by making
emission atomic with the state change; no archive can retrofit it. See
`net-kingdom/canon/standards/security-layer-model_v0.7.md` §9.6, raised by
`audit-core` against its own principle.

This bound is not yet reflected in the Active Secrets Management Canon — control
§27 and tests T-08 and T-09 are written as though reconstruction from evidence
were unconditional. Correcting the Canon is outstanding doctrine work.

---

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

Gate House's own health is measured by that loop turning, not by the volume of
documents it produces.

---

## What Would Make This Repository Wrong

Stated up front, because a repository re-cut on an argument should say what
would falsify it:

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

## Success Criteria

Gate House is working when:

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 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 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. Engines decide what may cross the boundary.
> Gate House decides what the boundary is for.**