gate-house/INTENT.md

# Gate House — INTENT

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