gate-house/ArchitectureBlueprint.md

Gate House — Architecture Doctrine Blueprint

Repository: gate-house Project family: NetKingdom Artifact: ArchitectureBlueprint.md Status: Current — doctrine architecture; no runtime role Version: 0.3 Date: 2026-09-10 Decision: decisions/decisions.md GH-DEC-2026-001

---

1. Purpose and authority

This document describes the architecture of NetKingdom security doctrine: the responsibility boundaries, semantic contracts, invariants, and conformance loop Gate House maintains. It does not specify a Gate House service. Gate House has no request-time position, stores no runtime state, and renders no authorization decision.

The v0.1 Blueprint described Gate House as a deterministic authority plane. That design was withdrawn by GH-DEC-2026-001 because it put the deterministic decision point inside a non-deterministic Staff repository. Its disposition is recorded in history/2026-09-01-authority-plane-blueprint-retirement.md, and the complete historical text remains available at Git object 75ce372:ArchitectureBlueprint.md.

This document is subordinate, in order, to:

1. decisions/decisions.md;
2. spec/ActiveSecretsManagementCanon_v0.3.md;
3. INTENT.md;
4. the accepted NetKingdom security-layer standard.

Where they conflict, the higher artifact wins and this Blueprint must be corrected.

The architectural maxim is:

Cognition proposes. Authority disposes. Infrastructure executes.

2. Architectural shape

NetKingdom separates security responsibilities by determinism and artifact:

Taxonomy  names the concepts and semantic contracts
    ↓
Tooling   holds consistent, performant, scalable state
    ↑
Engines   expose deterministic APIs over modeled concepts
    ↑
Staff     proposes doctrine, plans, changes, and supervision

The arrows are dependency direction, not authority flow. Staff acts through Engine APIs and never reaches Tooling directly.

For a protected action, the architecture is:

human / agent / workload proposes an action
    ↓
identity and context engines supply authoritative facts
    ↓
access-engine renders a deterministic decision
    ↓ GRANT only
secrets-engine materializes target-specific authority when needed
    ↓
ops-warden / resource-side enforcement executes within the grant
    ↓
evidence sources emit records; audit-core protects accepted records
    ↓
kings-guard observes posture and findings; whitehat-security challenges controls

Gate House is outside this runtime path. It specifies what each boundary must mean and reviews whether the path conforms.

2.1 Responsibility boundary

Component	Architectural responsibility
info-tech-canon / NetKingdom canon	shared terminology and standards of record
key-cape	authentication, federation, and identity tooling profile
user-engine	authoritative user, account, and membership facts
tenant-engine	authoritative tenant and organizational facts
zone-engine	authoritative zone identity and membership facts
access-engine	the only policy decision point; evaluates access rules
secrets-engine	credential abstraction, custody, and lifecycle
OpenBao	protects and issues secret, lease, and PKI material
ops-mason / ops-warden	construct and operate access lanes and perimeters
kings-guard	observation, bounded posture, findings, and containment requests
whitehat-security	adversarial execution of assurance specifications
Gate House	doctrine, authority context, invariants, conformance, and curriculum

Two boundaries are lexical as well as architectural:

• an access lane says how a worker reaches a host and belongs to ops-mason and ops-warden;
• an access rule says whether an action may occur and belongs to access-engine.

3. Core domain model

Gate House fixes the following meanings. Owning engines choose storage and wire representations without changing the semantics.

Term	Meaning
Principal	Human, organization, workload, or system on whose behalf authority originates.
Actor	Entity directly attempting the action.
Runtime Identity	Concrete workload instance performing execution.
Tenant	Security and organizational domain in which the action occurs.
Environment	Governed operational environment containing the target.
Mandate	Standing organizational authorization defining what an autonomous actor is intended to do.
Delegation	Scoped transfer of authority that preserves principal and actor and does not widen authority.
Authority Ceiling	Maximum authority an actor can obtain.
Operating Mode	Assistant or Autonomous security regime.
Task	Bounded unit of work for which authority is requested.
Action	Canonical operation requested of a protected resource.
Resource	Canonical target of an action.
Posture	Bounded security-state input from a trusted source.
Decision Evidence	Record of the identities, inputs, policy, conditions, and result that produced a decision.
Credential Binding	Mapping from granted authority to the mechanism a target accepts.

A mandate is not a credential, a task is not a mandate, identity is not authorization, and a credential is not the source of authority.

Access-engine renders GRANT, DENY, REQUIRE_APPROVAL, or DEFER. Gate House defines the vocabulary and invariants of those outcomes but neither evaluates nor emits them.

4. Authority context contract

The normative logical contract is authority-context.v1, recorded by ADR-001 and ADR-002.

Every agentic authority request must be able to express:

principal
actor
runtime identity
tenant
environment
mandate
task
operating mode

These are input claims alongside verified identity claims, requested action and resource, authoritative resource facts, policy, approval, posture, and limits. No field grants authority by being present. Caller assertion must remain distinguishable from authoritative evidence.

Principal, actor, and runtime identity are separate semantic roles. They may resolve to the same subject in a legitimate direct operation, but a consumer must not copy one into a missing role or use one generic identifier to erase delegation and runtime attribution.

Missing, conflicting, stale, or unresolvable security-critical context fails closed. DEFER is reserved for non-security-critical enrichment and is not a substitute for evidence needed to decide a protected operation.

5. Agentic operating modes

Operating mode is a security regime, not a deployment label.

5.1 Assistant

A human is actively engaged and can observe, redirect, approve, or stop at human latency.

• the human remains principal;
• the agent remains an identifiable actor;
• the concrete agent session or workload remains identifiable as runtime;
• privileged authority is bound to active supervision and short lifetime;
• the human's reusable credentials are not copied into agent context;
• interruption and confirmation remain available for high-impact actions.

Human disconnect, session timeout, or loss of supervision must not silently convert an Assistant workflow into privileged Autonomous operation.

5.2 Autonomous

A scheduled, triggered, or event-driven actor runs without continuous human supervision.

It requires:

• a unique actor identity and concrete runtime identity;
• a named governance owner;
• an explicit, current mandate and bounded task;
• an authority ceiling and tenant, environment, resource, and action bounds;
• runtime, concurrency, tool-call, token, compute, and credential-TTL bounds;
• an independent kill switch and lifecycle termination path;
• protected evidence sufficient for reconstruction;
• no borrowed human credential.

5.3 Transition

A transition from Assistant to Autonomous is a governed change. It requires a new authority request under the Autonomous requirements; it is not a mutation or fallback of an in-flight Assistant context.

6. Mandates, delegation, and ceilings

A mandate is a governed declaration of why an autonomous actor exists. A logical mandate includes, at minimum:

id: mandate:release-automation
revision: 7
owner: team:platform-release
purpose: deploy approved releases
operating_mode: autonomous
lifecycle:
  starts_at: 2026-09-01T00:00:00Z
  expires_at: 2026-12-01T00:00:00Z
  termination_ref: kill-switch:release-automation
authority_ceiling:
  tenants: [tenant:platform]
  environments: [production]
  actions: [release.deploy]
  resources: [k8s://cluster-a/ns/payments/*]
constraints:
  max_runtime: 30m
  max_concurrency: 1
  max_mutations_per_task: 1

This is a logical governance shape, not a Gate House storage schema. Access-engine owns how the authoritative mandate reference becomes policy input.

Delegation attenuates:

child authority ⊆ delegated authority ⊆ principal authority ⊆ authority ceiling

No agent reasoning, tool availability, approval, posture, budget, or child delegation may widen the ceiling.

7. Deterministic authority boundary

Every privileged action crosses an access-engine or resource-side deterministic authority boundary. The same authoritative input state and policy version must produce the same decision.

The decision must be able to account for:

WHO          principal, actor, runtime identity
WHERE        tenant, environment, zone, resource
WHAT         action and normalized parameters
WHY          task, mandate, delegation
UNDER WHICH  policy, approval, posture, quotas, budgets, ceiling
UNTIL WHEN   expiry and credential TTL

Evaluation is monotonic toward restriction: after application of the authority ceiling, no later input may create authority beyond it. This is a property Gate House specifies and access-engine implements; it is not a prescribed policy algorithm or evaluation order.

Approval is an independently governed, actor/action/resource/parameter/time binding. It can satisfy an explicit approval requirement but cannot exceed the authority ceiling or compensate for invalid identity, mandate, tenant, or environment context.

8. Posture and containment contract

King's Guard publishes bounded posture observations. Access-engine maps trusted posture to deterministic restrictions. Gate House owns the asymmetry:

Posture may reduce authority, require stronger authorization, or request containment. It must not probabilistically manufacture additional authority.

Accepted direction:

King's Guard observes DEGRADED / SUSPICIOUS / CONTAIN
    ↓ bounded posture with source, subject, freshness, and reason
access-engine applies a versioned deterministic rule
    ↓
authority stays equal or becomes narrower

Forbidden direction:

adaptive system says “looks safe”
    ↓
new or wider authority

A containment request does not authorize containment. Access-engine decides whether it may occur; ops-warden or the responsible Engine performs the authorized action. If posture is unavailable or stale, configured fallback must not expand authority over the last authoritative state or baseline policy.

9. Authority, credentials, and execution

The responsibility chain is:

access-engine   decides whether authority exists
secrets-engine  selects how granted authority is materialized
OpenBao         protects and issues credential material
ops-warden      operates the access lane or trusted execution path
resource        independently enforces the presented authority

Credential invariants:

• credentials are issued only after authority exists;
• credential scope and audience do not exceed the grant;
• credential lifetime does not exceed the authority lifetime;
• revocation and expiry semantics remain linked;
• raw reusable credentials do not enter model context;
• trusted brokered execution is preferred to disclosing credentials to an agent;
• Gate House never accesses OpenBao or another Tooling system directly.

An unavailable credential mechanism means execution cannot proceed. It does not cause another component to invent authority or silently substitute a broader credential.

10. MCP and tooling doctrine

MCP is a capability interface, not an authority system. Tool discovery means that an operation exists; it does not mean the actor may invoke it.

A sensitive tool definition should provide enough stable metadata for a PEP to construct a normalized request:

tool: restart_service
action: kubernetes.deployment.restart
resource_schema: k8s-resource.v1
parameter_schema: restart-service.v1
risk_class: privileged-write
reversible: true

The enforcement path is:

agent selects tool
    ↓
MCP server / resource PEP constructs normalized request
    ↓
access-engine decision
    ↓ GRANT only
separately issued, resource- and audience-bound authority
    ↓
tool execution and evidence emission

Inbound-token passthrough is forbidden by default. The downstream resource must receive authority intended for that resource, not whatever ambient token the caller happened to possess.

11. Change Dynamics Envelope

Agentic systems can exceed human review speed even while each individual action looks ordinary. The Change Dynamics Envelope bounds the cumulative rate, scope, concurrency, and duration of change.

Dimensions include:

• concurrent mutating actors and actions per grant;
• resources per task and mutations per resource;
• task duration, credential TTL, and agent-chain depth;
• deployment frequency and destructive-action quota;
• tenant, environment, repository, and resource-class boundaries;
• read/write and reversible/irreversible action separation;
• token, compute, tool-call, and external-service spend.

Hard limits such as authority ceilings, production concurrency, destructive quotas, and environment boundaries are deterministic enforcement inputs. Soft signals such as cost warnings and anomaly recommendations may ask for review or reduce authority, but do not grant it.

Economic budgets are useful blast-radius controls. They are never authorization.

11.1 Independent stop paths

Autonomous write authority must be stoppable without actor cooperation. Depending on the owning Engine, the deterministic mechanisms may suspend an actor or mandate, revoke grants and credentials, restrict an environment to read-only, or require approval for mutations.

Degradation moves toward restriction:

NORMAL → RESTRICTED → READ_ONLY → BLOCKED

Diagnostic visibility should remain available longer than mutation authority where policy can safely separate them.

12. Tenant isolation and policy self-modification

Tenant context is explicit for protected actions. An omitted tenant is not a wildcard, and a platform actor does not receive implicit cross-tenant authority. Tenant, environment, resource, and action bounds compose by intersection.

Changes to authority ceilings, policy packages, identity trust, tenant mapping, approval rules, posture mapping, audit configuration, credential bindings, or kill switches require stronger and independently governed authorization than ordinary workload changes.

An actor must not have routine authority to widen the policy that constrains itself. An attempted self-escalation is denied and emitted as high-value security evidence.

13. Decision evidence and audit

Decision evidence must support reconstruction of:

• principal, actor, runtime identity, tenant, environment, task, and mandate;
• action, resource, and normalized-parameter digest;
• operating mode, approval, and posture inputs;
• authority ceiling, quotas, budgets, and expiry;
• policy identifier and version;
• decision, reason, grant or approval references, and credential binding;
• execution target, result, and relevant state transition.

The actor being audited must not be able to alter or erase authoritative evidence. Each owning system emits evidence for its own state transitions; Gate House is not a central runtime audit writer.

13.1 Completeness bound

An append-only archive with a verified hash chain proves that records it holds were not altered or truncated after arrival. It cannot prove a record was ever sent. Therefore:

• completeness is the emitting system's obligation;
• load-bearing evidence emission is atomic with the state change, normally by a local transactional outbox;
• heartbeat and reconciliation make silent omission detectable where required;
• no conformance claim says merely that “the audit record proves it happened.”

The approval evidence contracts are the reference application:

• approval-outbox.md;
• approval-emission-detection.md;
• approval-consumption.md.

14. Failure semantics

Security-critical ambiguity fails closed.

Failure	Required architectural outcome
access-engine or required policy unavailable	Protected operation denied.
identity, tenant, environment, mandate, or delegation unresolved	Denied when the fact is security-critical.
posture unavailable or stale	Configured restrictive fallback; never additional authority.
approval unavailable, invalid, revoked, consumed, or mismatched	Approval-dependent operation denied.
credential materialization unavailable	No credential-dependent execution; the decision is not widened or replaced.
protected evidence cannot be durably coupled to a state change	That state change does not commit.
evidence archive unavailable after a local outbox commit	Retry asynchronously; do not roll back the committed safety action.
stale cache conflicts with newer restriction or revocation	New authority denied; caches must not outlive their safe staleness policy.

Fail closed does not mean one global availability rule. Each state owner must make the safety transition and its evidence atomic locally so an unavailable archive cannot block emergency revocation.

15. Architectural invariants

These stable identifiers retain the v0.1 Blueprint's invariant lineage, now stated against the correct ownership boundary.

A-01 — No probabilistic privilege

No LLM or statistical component is the final source of privilege.

A-02 — Explicit actor

Every privileged action resolves to an explicit actor.

A-03 — Autonomous mandate

Every autonomous privileged action resolves to an explicit current mandate.

A-04 — Attenuating delegation

Delegated authority does not exceed parent authority or the authority ceiling.

A-05 — Explicit tenant scope

Every protected action has explicit tenant or estate-defined non-tenant scope.

A-06 — Deterministic protected boundary

Production mutations cross deterministic access-engine or resource-side policy enforcement.

A-07 — Bounded lifetime

Authority and its credential material do not outlive their configured expiry.

A-08 — Independent revocation

Emergency reduction or revocation does not depend on the affected actor cooperating.

A-09 — Restrictive posture

Adaptive posture may restrict authority but cannot probabilistically create new authority.

A-10 — Credential separation

Credentials represent granted authority; they are not its source.

A-11 — Protected ceiling

Actors cannot ordinarily modify the controls defining their own authority ceiling.

A-12 — Actor-resistant evidence

Authoritative evidence is protected from the actor being audited, subject to the completeness bound in §13.1.

A-13 — Restrictive failure

Failure of a security-critical dependency does not silently expand authority.

A-14 — No accidental autonomy

Assistant sessions do not silently become Autonomous sessions.

A-15 — Incorrect-agent tolerance

Deterministic boundaries continue to hold when every agent behaves incorrectly.

A-16 — Distinguishable routes

Where one observable state is reachable by two routes that differ in security meaning, the record distinguishes which route produced it.

The two routes usually behave identically, and must — unknown and absent both fail closed, and should. A-16 is not a requirement that they diverge; it is a requirement that a later reader can tell them apart. Where they cannot, a sound check gets read as establishing a property it does not carry, and the safer reading of the appearance becomes unavailable to everyone.

Instances: GH-DEC-2026-010 (a decision envelope reads identically whether access-engine issued it or a responder forged it), GH-DEC-2026-011 (unknown versus absent in a stance map), GH-DEC-2026-013 (a tenant claim directory-asserted about the principal versus registration-supplied about the client, and — key-cape's own extension — a third route where nobody asserted a zone and a profile default supplied it), GH-DEC-2026-014 (erased versus never held on an evidence path).

Rider — who writes the marker. A-16 is only as strong as the independence of the party that writes the route marker from what the marker asserts. Where the marker is written by the party whose conduct the route describes, A-16 constrains a defect but not an adversary, and MUST NOT be read as establishing the distinction against a compromised source.

The four instances are not equally strong and the register should say so: a signature by the issuer is independent of the party relying on it; a PEP labelling its own input gains nothing by mislabelling; a tenant provenance written by the issuer is independent of the consumer; and an erased-versus-never-held marker written by the party the evidence is about is a self-attestation. The last reduces to the residual informed-decision has twice been refused credit for closing, and GH-DEC-2026-014 §4 narrows it — non-production becomes attributable — without removing it, because the attribution still rests on that party's own marker.

Without this rider A-16 becomes the thing it exists to prevent: a sound check read as establishing a property it does not carry. Raised by informed-decision against its own instance, which is the weak one.

A-17 — Fail-closed transitions

A transitional deviation from an invariant is admissible only where it fails closed on the case that distinguishes it from the conformant state.

This governs what may enter the declared-gap register rather than what a system does at runtime. The admitting question is not the quality of the design or the length of the transition, but the direction of failure at the distinguishing case. A promise that fails open is a permission; a promise that fails closed is a gap.

Precondition — the distinguishing case must be observable first. A-17 asks which way a case fails, and that question is unanswerable where the case cannot be seen. Where the distinguishing case is not observable, making it observable is a precondition of applying A-17, not an outcome of it. Otherwise A-17 admits anything whose distinguishing case is merely invisible, which reads as failing closed because nothing visibly fails.

A-17 therefore depends on A-16. One cannot ask which direction a case fails in until the record can distinguish that case from its neighbours.

Instances: GH-DEC-2026-011 (a dated transitional unknown: fail_open declined — its distinguishing case is exactly where it fails open, so the transition licenses the forbidden thing and dates it), GH-DEC-2026-013 (a registration-bound tenant granted — registration and directory disagreeing refuses issuance rather than picking a winner), GH-DEC-2026-014 (commitment-only evidence granted — but only after §4 made the case observable; as proposed it had no failure direction at all, because a reviewer receiving a blank could not tell erased from withheld from lost from never held).

The third instance is why the precondition is stated. GH-DEC-2026-014 §4 did not test the direction of failure; it manufactured one, by requiring an existence assertion that turns non-production into a finding. That was the right outcome reached without noticing it was a different operation from the one A-17 describes. Raised by informed-decision, from the instance it bears.

A-16 and A-17 are newer than A-01…A-15 and are not yet estate doctrine. They are stated here because a property recorded only against the instance that produced it is found by accident or not at all. Graduation to net-kingdom/canon/standards/ waits on a repository bearing a cost under them having argued them, which is the bar security-layer-model met and these have not.

16. Conformance architecture

Gate House doctrine is real only when the loop turns:

Gate House asserts an invariant or contract
    ↓
owning Engines and Staff repositories implement it
    ↓
whitehat-security executes the assurance specification
    ↓
kings-guard observes behavior and findings
    ↓
findings return to Gate House as doctrine change

The Canon's T-01…T-10 are specifications owned by Gate House and executed by whitehat-security. They cover malicious-model behavior, credential exfiltration, human disconnect, policy self-modification, confused-deputy behavior, approval replay, circuit breakers, evidence reconstruction, audit failure, and revocation closure.

Their executable handoff is asm-assurance-targets.v1. Results return under conformance-reporting.v1, and the kings-guard observation half follows posture-findings-return.v1.

The reference scenarios are:

• UC-01 — human-assisted read;
• UC-02 — autonomous release;
• UC-03 — dynamic database access;
• UC-04 — containment;
• UC-05 — self-escalation attempt.

Passing prose review is insufficient. A conformance report names the invariant, owning implementation, test or observation, evidence bound, result, and finding return path.

17. ADR disposition and remaining doctrine work

ADR	Disposition
ADR-001	Accepted — canonical authority-context contract.
ADR-002	Accepted — principal / actor / runtime identity model.
ADR-003	Lapsed — policy-engine selection belongs to access-engine.
ADR-004, ADR-005, ADR-008, ADR-011, ADR-012	Engine implementation decisions; no Gate House runtime ADR. Their doctrine survives in invariants and contracts.
ADR-006	Still meaningful — posture input contract with kings-guard.
ADR-007	Credential separation is doctrine here; materialization implementation belongs to secrets-engine.
ADR-009	Still meaningful — Assistant session binding.
ADR-010	Still meaningful — Autonomous mandate model.
ADR-013	Still meaningful — MCP authorization integration.
ADR-014	Still meaningful — policy self-modification protection.

Future ADRs in Gate House decide doctrine and responsibility boundaries. They must not select an Engine's implementation technology or create a Gate House runtime surface.

18. Blueprint summary

Gate House establishes the security doctrine that makes the runtime chain coherent. It does not join that chain as a service.

agent decides what to attempt
    ↓
engines establish identity and context
    ↓
access-engine decides what may cross
    ↓
secrets-engine materializes bounded authority
    ↓
the perimeter and resource enforce it
    ↓
evidence and adversarial review show whether the doctrine held

The mandate and 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.