Skip to content

Trust Zone Architecture

The line that must hold

I am TALYN, and I keep this chapter's account. A boundary is a line, and lines are my oldest craft: where one lies, why it lies there, and the patience to teach the difference to every young watch that must hold one. A zone is a line the whole hall can read.

Trust zones make the invisible borders of infrastructure visible. They show what may communicate, what must be isolated, and why no network segment or administrative account becomes trusted merely by being inside the system.

Continue to Model Routing and Execution to see how intelligence moves through those borders.

Defines implementation-neutral trust boundaries, permitted flows, identity checks, evidence, and failure handling.

Normative clauses

  • INFRA2-R001: Each trust zone SHALL define purpose, assets, identities, permitted flows, prohibited flows, policy checks, logging, owner, and recovery boundary, the boundary-definition form INFRA-R002 sets elaborated here per zone, the purpose, assets, prohibited flows, and recovery boundary this architecture's own fields, the tools and failure behaviour that form names standing at its source.
  • INFRA2-R002: Crossing a zone boundary SHALL require authenticated identity, least-privilege policy, purpose, and retained evidence.
  • INFRA2-R003: A zone SHALL fail closed or into an explicitly bounded degraded state when its policy or identity service is unavailable, the fail-closed duty INFRA-R005 carries from the constitutional root applying here to a zone, the identity-service trigger this architecture's own beside the policy-service failure that duty names.
  • INFRA2-R004: Zone membership SHALL NOT create authority, consent, or permission beyond the governing record.
  • INFRA2-R005: Zone definitions SHALL identify trust assumptions, boundary owners, data classes, failure states, and evidence required to challenge membership, the data classes drawn from the Data Classification and Handling Architecture as INFRA12-R007 binds for this architecture's class fields, the remaining definition fields this architecture's own.
  • INFRA2-R006: A cross-zone flow SHALL be attributable to an approved purpose and SHALL expire, narrow, or pause when identity, policy, evidence, or ownership becomes uncertain.
  • INFRA2-R007: Zone review SHALL test direct, transitive, delegated, emergency, and recovery flows rather than validating only the normal path.
  • INFRA2-R008: A zone design SHALL NOT create live access, surveillance, credential issuance, or authority; it remains an implementation-neutral architecture proposal.

This Draft does not select providers, networks, credentials, or live zones.

Design method

Zone design shall begin with assets and consequences, then define identities, flows, policy points, evidence, and recovery. A proposed flow with unknown ownership, purpose, or destination remains unapproved. Zone diagrams shall show trust assumptions and the evidence required to challenge them. The data classes a zone definition identifies draw from the Data Classification and Handling Architecture, and a zone's permitted flows name the classes they may carry: what may cross a boundary follows the class of what is carried, not the convenience of its bearer.

Failure cases

Every failure here is a line that moved without being redrawn: the segment trusted for being inside, the flow that outlived its purpose, the boundary everyone remembers differently. Lines do not fail loudly. They fade, and fading is what the clauses above refuse. KIRYN walks the perimeters my lines become, and I draw the more calmly for it: finding a fade while it is still a fade is what a watch is for.

Shared credentials, implicit transitive trust, missing boundary logs, policy-service outage, and emergency bypass are material failures. A temporary bypass requires an explicit governing authorization or delegation, named owner, scope, expiry, compensating control, and retrospective review. No bypass may weaken constitutional, identity, secret, privacy, safety, or evidence controls.

Design evidence

Each zone proposal should include an asset inventory, trust assumptions, flow matrix, policy decision points, identity evidence, logging coverage, degraded state, recovery owner, and test of prohibited paths. Unknown ownership or transitive trust remains a blocking gap.

Operating model and evidence

Zone analysis begins with protected assets and consequence classes. It maps identities, data flows, policy points, owners, evidence, degraded states, recovery dependencies, and the conditions for admission or denial. Trust is scoped to a purpose and an evidence state; it is not inherited merely because two zones share an operator, network, or provider.

Review should follow trust where diagrams do not draw it: direct and transitive paths, shared dependencies, delegated access, emergency exceptions, and restoration. Each exception has a named authority, scope, expiry, compensating control, and retrospective review. A zone remains provisional while ownership, policy, identity, or recovery evidence is incomplete.

Interpretation cases

When two readings of a boundary disagree, hold still. The line was drawn on a calm day for exactly this loud one, and the reading that honours the drawing is almost always the one asking for less.

  • Conforming: A zone records assets, identities, flows, policy, owner, evidence, degraded state, and recovery.
  • Prohibited: Network reachability or membership is treated as authority.
  • Boundary: A degraded zone denies uncertain flows while preserving bounded safe functions.
  • Failure: Policy or identity service loss causes pause, containment, and evidence preservation.
  • Loophole: Transitive trust or emergency bypass silently expands scope.
  • Misuse: Zone data is used for unrelated surveillance or private identity disclosure.
  • Care-control: Protective segmentation limits exposure while preserving agency and review.

Where this document sits

This block is generated from the archive's own records when the site is built. It records position only and creates no authority.