gate-house/README.md
tegwick a5a1bcf537 State two properties once, and repair SCOPE.md's withdrawn framing
Two things this week's rulings left owed, both the failure mode those
rulings were about.

A-16 and A-17, and Core Rules 16 and 17. Two general properties had
been stated three times each, always against the instance that produced
them and nowhere in general — which is how a property gets found by
accident or not at all. That is the defect gate-house corrected in
three other repositories this month while carrying it here.

A-16, distinguishable routes: where one observable state is reachable
by two routes differing in security meaning, the record must say which.
Four instances, and they only look like one rule once they are next to
each other — an envelope identical whether access-engine issued it or a
responder forged it (GH-DEC-2026-010), unknown versus absent in a
stance map (-011), a tenant claim directory-asserted versus
registration-supplied (-013), erased versus never held on an evidence
path (-014). The rule is not that the routes must diverge; usually they
must behave identically and safely. It is that a later reader can tell
them apart, or a sound check gets read as carrying a property it does
not have.

A-17, fail-closed transitions: a transitional deviation is admissible
only where it fails closed on the case distinguishing it from the
conformant state. Written because two requests for transitional relief
arrived in one week and were answered oppositely, and the answers would
otherwise read as arbitrary rather than as one rule.

Both are marked repository-level and explicitly not estate doctrine.
Graduation waits on a repository that bears a cost under them having
argued them, which is the bar security-layer-model met and these have
not.

SCOPE.md was still the withdrawn authority-plane framing. It opened by
saying gate-house "decides whether a requested action is authorized"
and listed deterministic authorization decisions as in scope — the
design retired by GH-DEC-2026-001, surviving in a derived document a
reader would take as current, with a dead pointer to Blueprint section
3 non-goals that the re-cut removed. Rewritten from current INTENT,
including what is not owned here and what would put the repository out
of scope.

The irony is noted rather than hidden: a derived artifact contradicting
its source, in the repository that generalised that failure into
statute section 12 after finding six instances in one week elsewhere.

rmgr conform clean.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012viPor8WJNCbV64ipwewrm

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1754332@bnt-lap001
Assistant-Session: 9c8ac536-ff5e-46a3-8ab1-a548bde25fc0
2026-09-10 07:57:35 +02:00

198 lines
9.3 KiB
Markdown

# Gate House
**The council where NetKingdom's security and defence doctrine is established, documented, taught, and supervised.**
Gate House is a NetKingdom **Staff**-layer repository and the home of the
Active Secrets Management (ASM) Canon. It is the headquarters of the
operational staff that does the chores of IT security in NetKingdom.
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 held
by someone else.
> **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.**
Its artifacts are specifications, decisions, workplans, and tasks. It holds no
runtime position, renders no authorization decision, and stores no state that
anything depends on at runtime.
---
## Where it sits
NetKingdom's IT security is layered by determinism and by the kind of artifact
each layer produces — see
[`net-kingdom/canon/standards/security-layer-model_v0.7.md`](../net-kingdom/canon/standards/security-layer-model_v0.7.md).
```text
Taxonomy cross-cutting language info-tech-canon, net-kingdom canon
Tooling deterministic state key-cape (authelia, lldap, privacy-idea), OpenBao
Engines deterministic APIs user / tenant / zone / secrets / access-engine
Staff interactive, non-deterministic gate-house, ops-mason, ops-warden,
kings-guard, whitehat-security
```
Read by determinism, those layers reproduce the Canon's three planes — which is
the point:
> **Cognition proposes. Authority disposes. Infrastructure executes.**
The rule that binds every repository:
> **Staff never touches Tooling directly. It acts only through Engine APIs.**
## Why Gate House is not the decision point
Gate House was seeded as a deterministic authority plane — an `/authorize` API,
grant storage, a revocation service. That was withdrawn on 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.**
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.**
---
## What Gate House owns
- **The doctrine** — the ASM Canon, its invariants, and the argument behind
them. Invariants graduate into `net-kingdom/canon/standards/`.
- **The authority context** — principal, actor, runtime identity, tenant,
environment, mandate, task, operating mode. Defined here, consumed by
access-engine as input claims.
- **The agentic operating modes** — assistant and autonomous as distinct
security regimes.
- **Mandates, authority ceilings, and kill switches** for autonomous actors, as
a model and a governance obligation.
- **The Change Dynamics Envelope** — how much change the organization tolerates.
- **The MCP doctrine** — tool availability is not permission.
- **The posture contract** with kings-guard, including its asymmetry.
- **Conformance review** — whether authority in practice matches the declared
mandate and ceiling.
- **The assurance specifications** T-01…T-10, executed by whitehat-security.
- **The security curriculum.**
## What Gate House does not own
The authorization decision or any `/authorize` surface; policy engines,
packages, or rollout; grants, credentials, leases, or revocation; identity,
tenancy, zone, or user lifecycle; secret storage or PKI; anomaly detection or
threat intelligence; access lanes, SSH certificates, or host hardening;
deployment or remediation execution; and other repositories' workplans.
| Component | Layer | Responsibility |
|---|---|---|
| info-tech-canon | Taxonomy | ecosystem-wide semantic contracts |
| net-kingdom | Taxonomy | NetKingdom standards of record |
| key-cape | Tooling | packaged identity tooling; IAM profile; authentication |
| OpenBao | Tooling | secret storage, leases, PKI |
| user-engine | Engine | users, accounts, memberships |
| tenant-engine | Engine | tenant-as-an-entity facts |
| zone-engine | Engine | zone identity and membership |
| secrets-engine | Engine | credential abstraction, custody, lifecycle |
| **access-engine** | Engine | **the decision — the only decision point** |
| **gate-house** | **Staff** | **doctrine, authority context, conformance, curriculum** |
| ops-mason | Staff | builds and tears down access routes and perimeters |
| ops-warden | Staff | operational access lanes, stewardship, runbooks |
| kings-guard | Staff | adaptive defence, observation, containment |
| whitehat-security | Staff | offensive validation |
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.
---
## The doctrine in seventeen lines
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, 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 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.
17. A transitional deviation is admissible only where it fails closed on the case that distinguishes it from the conformant state.
The last two are September 2026 and are repository-level, not estate doctrine. 16
is why an `unknown` and an `absent` stance cell must be told apart in the record
even though both fail closed, and why a decision envelope that looks authentic is
not therefore attributable. 17 is why one request for transitional relief was
granted and another declined in the same week. See `INTENT.md` § Core Rules.
## Agentic operating modes
The distinction Gate House exists to keep sharp.
**Assistant** — a human is engaged and can redirect or stop at human latency.
The human remains the principal; the agent remains a visible actor. *A human
disconnecting must never silently promote the session into autonomous
privileged operation.*
**Autonomous** — a scheduled or triggered agent acts without supervision, and
therefore requires unique identity, a named owner, an explicit mandate, an
authority ceiling, runtime and concurrency limits, budgets, an independent kill
switch, and audit reconstruction.
## The conformance loop
Doctrine that no engine implements is fiction. Gate House is only real if this
turns:
```text
gate-house asserts an invariant
→ the engines implement it
→ whitehat-security tries to break it
→ kings-guard observes it in operation
→ findings return to gate-house as doctrine change
```
---
## Repository map
| Path | What it is |
|---|---|
| [`INTENT.md`](INTENT.md) | why this repository exists; the re-cut in full |
| [`SCOPE.md`](SCOPE.md) | in scope / out of scope |
| [`spec/ActiveSecretsManagementCanon_v0.3.md`](spec/ActiveSecretsManagementCanon_v0.3.md) | the working canon — invariants, controls, profiles, assurance tests |
| [`docs/contracts/authority-context.md`](docs/contracts/authority-context.md) | normative authority-context vocabulary consumed by access-engine |
| [`docs/assurance/asm-t01-t10-executable-targets.md`](docs/assurance/asm-t01-t10-executable-targets.md) | executable assurance targets handed to whitehat-security |
| [`docs/conformance/`](docs/conformance/) | Gate House dispositions for returned assurance and posture reports |
| [`docs/adr/`](docs/adr/) | architecture decisions for Gate House doctrine and contracts |
| [`ArchitectureBlueprint.md`](ArchitectureBlueprint.md) | current doctrine architecture and responsibility contracts |
| [`decisions/decisions.md`](decisions/decisions.md) | decision records — start with GH-DEC-2026-001 |
| [`history/`](history/) | reference notes; the 2026-08-28 review is the origin of the current shape |
| [`workplans/`](workplans/) | work in flight |
**Status.** Specification-only; no code, by design. `INTENT.md`, the decision
record, the canon standard, and `ArchitectureBlueprint.md` reflect the current
shape. The withdrawn authority-plane design is preserved under `history/` and
in Git, not in the working architecture.
---
> **Agents decide what to attempt. Engines decide what may cross the boundary.
> Gate House decides what the boundary is for.**