Four repositories returned text reviews. Every substantive finding was about a rule that read as satisfied by a check that did not satisfy it, which is the failure mode this repo is structurally prone to: doctrine is graded on whether it is right and consumed on whether it is checkable, and only the implementers can tell those apart. GH-DEC-2026-010 — attribution is not identity. Obligation 1 said a PEP must hold a decision from access-engine; obligation 2 supplied a digest test emphatic that it was mechanical rather than a matter of judgement. That test establishes which request a decision is for and nothing about who issued it, and it cannot: every input to it is either sent by the caller or published, so a responder knowing a published package id and version returns a well-formed allow. Fail-closed protects against a decision point that is absent, not against one that lies. Section 9.4 required authenticated entries of the approval object and nothing required it of the decision, so obligation 5 was written over a pair a PEP could only half validate. The mechanism is access-engine's under section 17 and it is not the standard's to choose, so the condition is a declared section 13 gap rather than a rule invented here. Raised by access-engine against its own artifact, which had already recorded it as its own defect before reading our text. GH-DEC-2026-011 — ops-warden assented to GH-DEC-2026-009 on the falsifier's own terms, went looking for the section 5.1 escape hatch the reversal clause predicted, and reported it does not have one. Then it priced adoption: 0 of 3 signing targets and 3 of 21 routing lanes resolve to a zone, so the cell adopted today fails closed on nearly every certificate it issues whenever the engine is unreachable — including the continuity path an operator needs to repair that unreachability. Its ask for a dated transitional unknown: fail_open is declined; it is indistinguishable at runtime from the stance the rule forbids and would make the rule optional at the only moment it costs anything. Its second preference is adopted instead: 13.1 records a dated coverage figure beside each stance, so a strict consumer and an unclassified one stop reading alike. Coverage is disclosure and does not soften the stance — the record says so, and says what would make the column come out again. The round record is closed and carries the rest: totality by catch-all, absent versus unknown (closing the section 16 question this version opened), the drift test promoted to MUST, ops-mason marked, and approval-engine's four editorial-but-load-bearing findings. Its own finding ids are used rather than renumbered. kings-guard and audit-core did not return a review. Section 14 records that as not claimed rather than counting silence as assent, and names the sections that therefore carry no assent from the repository best placed to test them. Standard amended at net-kingdom@64394e9; it stays proposed, and publication and the acceptance flip are net-kingdom's. 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 |
||
|---|---|---|
| decisions | ||
| docs | ||
| history | ||
| intakes | ||
| spec | ||
| workplans | ||
| .custodian-brief.md | ||
| .gitignore | ||
| .repo-classification.yaml | ||
| AGENTS.md | ||
| ArchitectureBlueprint.md | ||
| CLAUDE.md | ||
| INTENT.md | ||
| README.md | ||
| SCOPE.md | ||
| WORK-RECORDS.md | ||
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.
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
- No privilege from cognition.
- Every privileged action crosses a deterministic authority boundary.
- Tool availability is not permission.
- Principal and actor remain distinguishable.
- Assistant and autonomous operation are different security modes.
- Autonomous agents use independent identities and explicit mandates.
- Authority is least-privileged, scoped, and time-bounded.
- Delegation attenuates.
- Security posture may reduce authority but must not expand it.
- Emergency revocation works without agent cooperation.
- Agents do not casually modify the policies defining their own ceiling.
- Credentials are ephemeral implementation artifacts of authorization.
- Audit evidence is protected from the actor being audited.
- Failure of critical policy or authorization dependencies fails closed.
- 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:
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 |
why this repository exists; the re-cut in full |
SCOPE.md |
in scope / out of scope |
spec/ActiveSecretsManagementCanon_v0.3.md |
the working canon — invariants, controls, profiles, assurance tests |
docs/contracts/authority-context.md |
normative authority-context vocabulary consumed by access-engine |
docs/assurance/asm-t01-t10-executable-targets.md |
executable assurance targets handed to whitehat-security |
docs/conformance/ |
Gate House dispositions for returned assurance and posture reports |
docs/adr/ |
architecture decisions for Gate House doctrine and contracts |
ArchitectureBlueprint.md |
current doctrine architecture and responsibility contracts |
decisions/decisions.md |
decision records — start with GH-DEC-2026-001 |
history/ |
reference notes; the 2026-08-28 review is the origin of the current shape |
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.