tegwick
8cb7250230
Assistant: codex Assistant-Model: gpt-5.6-sol Assistant-Session: 01a05e30-2884-71b0-98d7-7edd16ae737b
190 lines
8.7 KiB
Markdown
190 lines
8.7 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 fifteen 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.
|
|
|
|
## 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.**
|