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.

The tellings of the clauses

This non-normative section gives each clause of this document its telling: the clause, quoted exactly as it stands above with its cross-reference links reduced to their plain text, and one paragraph on what the clause means, why it exists, and how it assures that what it orders is done, not done, adhered to, followed, or protected. A telling describes its clause and never becomes it: the clause's own words govern wherever a telling and its clause could be read differently, and nothing in this section adds to, narrows, or amends any requirement.

INFRA2-R001

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.

Each trust zone is defined by nine fields: purpose, assets, identities, permitted flows, prohibited flows, policy checks, logging, owner, and recovery boundary. The clause states its own lineage: this is the boundary-definition form INFRA-R002 sets, elaborated here per zone; the purpose, assets, prohibited flows, and recovery boundary are this architecture's own fields, and the tools and failure behaviour that form names stand at its source rather than being restated. Permitted flows and prohibited flows are both required elements of a zone definition. The architecture's failure cases name the slow loss this answers, the boundary everyone remembers differently, and its design evidence holds unknown ownership as a blocking gap. Because the nine fields are required of every zone, a definition silent on any of them is incomplete and refusable, a flow can be judged against the zone's declared permissions and prohibitions rather than against habit, and each zone definition can be checked for its owner and recovery boundary.

INFRA2-R002

INFRA2-R002: Crossing a zone boundary SHALL require authenticated identity, least-privilege policy, purpose, and retained evidence.

Crossing a zone boundary costs four things: authenticated identity, least-privilege policy, purpose, and retained evidence. Being inside does not replace the crossing requirements, nothing crosses with more access than the crossing needs, every crossing has a reason, and every crossing leaves a trace. The Book's Trust Zones section puts a like demand on movement across zones, and the architecture's failure cases name the decay this refuses, the segment trusted for being inside, with the prohibited interpretation case putting it flatly: network reachability or membership treated as authority. Because the four requirements bind, a crossing can be challenged on each: an unauthenticated flow, an over-broad grant, a purposeless transfer, or a crossing that left no evidence is each a nameable breach, and the line stays readable because every legitimate crossing retains evidence.

INFRA2-R003

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.

When a zone's policy or identity service goes unavailable, the zone fails closed or into an explicitly bounded degraded state. The clause names its descent: the fail-closed duty is the one INFRA-R005 carries from the constitutional root, applied here to a zone, and the identity-service trigger is this architecture's own, standing beside the policy-service failure that duty names. The architecture's boundary interpretation case shows the conforming shape, a degraded zone denying uncertain flows while preserving bounded safe functions, and its failure interpretation case illustrates a response, policy or identity service loss causing pause, containment, and evidence preservation. Because the clause binds, a zone whose policy or identity service is unavailable can be checked for whether it has failed closed or entered an explicitly bounded degraded state.

INFRA2-R004

INFRA2-R004: Zone membership SHALL NOT create authority, consent, or permission beyond the governing record.

Membership alone grants no authority beyond the governing record: zone membership creates no authority, no consent, and no permission beyond the governing record. Being placed inside a zone is an implementation fact, and the clause stops that fact from creating authority, consent, or permission beyond the governing record. The architecture's prohibited case names the exact breach, network reachability or membership treated as authority, and its operating model states the principle underneath: trust is scoped to a purpose and an evidence state, not inherited merely because two zones share an operator, network, or provider. Because the clause binds, a claim that zone membership creates authority, consent, or permission beyond the governing record is refusable, and membership cannot itself ground a claim beyond the governing record, which lets a membership-based claim be tested against the governing record.

INFRA2-R005

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.

Five more things every zone definition identifies: its trust assumptions, its boundary owners, the data classes relevant to the zone and its permitted flows, its failure states, and the evidence required to challenge membership. The clause names its borrowing: the data classes are drawn from the Data Classification and Handling Architecture as INFRA12-R007 binds for this architecture's class fields, and the remaining definition fields are this architecture's own. The design method explains the first field: zone diagrams show their trust assumptions and the evidence required to challenge them; it adds that what may cross a boundary follows the class of what is carried, not the convenience of its bearer. The design evidence holds unknown ownership as a blocking gap. Because the five identifications bind, a zone's assumptions can be revisited when the ground shifts, its membership can be contested with named evidence rather than suspicion, and a definition missing any field is refusable.

INFRA2-R006

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.

A flow across zones lives on two conditions: it is attributable to an approved purpose, and it expires, narrows, or pauses when identity, policy, evidence, or ownership becomes uncertain. The first condition means no flow exists for its own sake; the second means uncertainty acts on the flow rather than being absorbed by it, with three permitted responses and continuation unchanged not among them. The architecture's failure cases name the decay this refuses, the flow that outlived its purpose, and the loophole case names the expansion, transitive trust or emergency bypass silently widening scope. Because the clause binds, every cross-zone flow can be asked for its approved purpose and refused without one, and a flow still running at full width after its identity, policy, evidence, or ownership went uncertain is a breach nameable against this clause rather than an operational judgement call.

INFRA2-R007

INFRA2-R007: Zone review SHALL test direct, transitive, delegated, emergency, and recovery flows rather than validating only the normal path.

Zone review tests direct, transitive, delegated, emergency, and recovery flows rather than validating only the normal path. The architecture's operating model recommends that review follow trust where diagrams do not draw it, and the loophole case names what hides on the untested paths, transitive trust or emergency bypass silently expanding scope; the failure-cases section adds that a temporary bypass itself requires an explicit governing authorization or delegation, a named owner, scope, expiry, a compensating control, and retrospective review. Because the five flow kinds are enumerated, a zone review's coverage is checkable against the list: a review that validated only the normal path is incomplete on its face, and coverage of each named flow kind can be checked.

INFRA2-R008

INFRA2-R008: A zone design SHALL NOT create live access, surveillance, credential issuance, or authority; it remains an implementation-neutral architecture proposal.

The design keeps its hands off the world: a zone design creates no live access, no surveillance, no credential issuance, and no authority; it remains an implementation-neutral architecture proposal. The host's own Draft prose repeats the limit, selecting no providers, networks, credentials, or live zones, and the misuse interpretation case shows why surveillance is barred by name, zone data used for unrelated surveillance or private identity disclosure. Because the clause binds, anyone citing a zone design as the warrant for live access or surveillance cites it falsely, refusably on the design's own text, and the proposal stays what the architecture intends: a line drawn on paper, awaiting the separate authority that could ever make it real.

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.