Trust boundaries and data flows

What a trust boundary represents

A trust boundary is a place where the assumptions, authority, identity, policy, or level of control changes. Crossing a network segment may create a boundary, but boundaries also occur between users, tenants, identity domains, administrative teams, data classifications, build stages, and human approval states.

The purpose of a boundary diagram is not visual decoration. It should reveal where validation, authorization, inspection, evidence, or explicit acceptance is required.

Map flows, not just boxes

For each flow, record:

• Source and destination.
• Data or artifact type and classification.
• Initiating identity and delegated identity.
• Protocol or transfer mechanism.
• Required policy decision.
• Encryption and key authority.
• Logging and evidence produced.
• Failure, retry, and rejection behavior.

Number important flows so controls and evidence can refer to the diagram precisely.

Boundaries in the knowledge-assistant example

The SAI-100 running example contains at least these boundaries:

1. User to application: authenticate the user, establish context, and constrain input.
2. Application to retrieval: propagate identity and enforce document permissions.
3. Retrieval to model: provide only approved context and prevent unapproved egress.
4. Model to application: inspect output, preserve citations, and handle unsupported answers.
5. Connected import to internal artifact store: scan, verify, approve, and record imported artifacts.
6. Build environment to runtime: promote only approved, identified releases.
7. Runtime to evidence store: protect and retain events needed for investigation and assurance.
8. Operator to platform: constrain privileged actions and preserve administrative evidence.

Draw four complementary views

One diagram rarely serves every audience. Use:

• A system context view for actors, external systems, ownership, and major flows.
• A trust-zone view for control changes and permitted connections.
• A deployment view for runtime, storage, networks, and administrative planes.
• A lifecycle or supply-chain view for artifact movement from source to approval and operation.

Keep component names and flow identifiers consistent across views.

Boundary review questions

• Does every external dependency appear?
• Can administrators bypass the application’s policy path?
• Where can information leave the approved environment?
• Where do public artifacts enter, and who approves them?
• Does user identity survive retrieval and tool execution?
• Which flow produces evidence when a request is blocked?
• Can an update change behavior without a new approval?
• What remains operational if an external control plane is unavailable?

Output

Produce a diagram plus a boundary register:

Boundary ID:
Source and destination:
Trust change:
Allowed flows:
Control owner:
Required controls:
Evidence:
Known gap or accepted dependency:

SAI-110 expands this shared foundation into threat scenarios, misuse cases, attack surfaces, and control verification. It should reference this chapter rather than duplicate it.