Network diagrams are useful, but they frequently describe connectivity more accurately than trust. A firewall symbol between two segments proves that traffic crosses a device. It does not prove that the policy reflects the intended security model.
What a trust boundary represents
A trust boundary exists wherever a request, identity, administrative action or data object moves into an environment governed by different assumptions.
Common examples include transitions from public access to an edge proxy, from an employee device to an internal application, or from an application service to a privileged management interface.
Questions worth asking
- Which component authenticates the caller?
- Where is authorization performed?
- Can the destination verify the original identity?
- Which headers or attributes are trusted?
- What happens when the upstream control is bypassed?
- How is administrative access separated?
The bypass problem
An edge service can enforce excellent controls while the origin remains directly reachable. In that case, the architecture contains two paths: the reviewed path through the control and the forgotten path around it.
Internet | +--- Edge proxy --- Application | +------------------ Origin IP
The security model is defined by the weaker path. Restricting the origin to trusted upstream systems is therefore part of the control, not an optional enhancement.
Document assumptions explicitly
A useful architecture record should state which component validates identity, which network paths are allowed and what evidence exists when the design fails.
Diagrams should remain. They simply need an accompanying explanation of trust, privilege and failure modes.