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

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:

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:

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.