System and boundary
A data flow shows what moves between components, in which direction, and through which interface. A trust boundary marks a change in control, identity, privilege, tenancy, integrity, or assurance assumptions. It does not mean that one side is safe. It means the crossing needs an explicit validation or protection decision.
Map one request
Draw the client, identity provider, name resolution, listener, proxy, policy information sources, decision point, enforcement point, upstream, application, data store, and evidence sink. Add protocols, credentials, assertions, identifiers, and cached facts to each edge. Include administration and recovery paths.
Attach a rule to each crossing
For each boundary, state what the receiver validates, which authority it trusts, what freshness it needs, and what happens on failure. Examples include TLS peer validation, token issuer and audience checks, schema validation, route policy, application permissions, and log access control.
Failure domains and residual risk
Diagrams often omit alternate ingress, asynchronous work, shared control planes, and human operations. A line labeled "internal" is not a control. Shared identity, network, or policy dependencies can make several boundaries fail together.
Pomerium boundary
Pomerium forms an enforcement boundary only for traffic that reaches its listener and cannot reach the upstream by another path. A signed identity assertion creates a verifiable message, but the upstream must validate its issuer, audience, signature, and lifetime. Application permissions remain a separate boundary.
Evaluation checklist
- Does the diagram include every ingress, administration, and recovery path?
- Does each edge name the data, authority, protocol, and direction?
- Does each trust-boundary crossing have a validation rule and failure result?
- Are shared dependencies and caches visible?
- Can a test show that a direct path or forged identity is rejected?
