How to derive trust boundaries and blast radius from architecture evidence

A trust boundary is where identity, privilege, data sensitivity, ownership, network exposure, or execution control changes. It is not limited to a box drawn around a subnet. A public endpoint entering a private workload is a boundary. A CI identity publishing to production is a boundary. An AI agent moving from retrieved context to a state-changing tool is a boundary.

To derive boundaries consistently, the architecture model needs typed entities and relationships. It also needs evidence for the attributes that create the boundary: exposure, authentication, authorization, environment, data classification, and administrative domain.

Blast radius describes the components, data, identities, and capabilities that could be affected after a component is compromised or behaves unexpectedly. It cannot be calculated from a CVE score alone. It depends on reachable paths and the privileges carried across them.

An evidence-backed graph can support path questions without claiming perfect runtime knowledge. Code may show a client dependency. Infrastructure may permit a connection. Deployment configuration may bind an identity. Each observation contributes a different kind of reachability evidence and should remain distinguishable.

A useful structural review walks from an entry point through workload, identity, data, and operational dependencies. Each hop needs provenance. Missing evidence becomes a coverage gap, not an invisible assumption.

Confidence should explain source agreement, not create false mathematical precision. A relationship observed in code, IaC, and deployment configuration is usually stronger than one inferred from naming. Runtime evidence may confirm that a permitted path is actively used, while its absence does not necessarily prove the path is impossible.

Show the sources and the confidence breakdown together. Let the reviewer distinguish observed, permitted, declared, and inferred relationships. That vocabulary is more useful than colouring every arrow as equally true.

Once the path is inspectable, remediation can address structure rather than only the vulnerable line. A team may remove an unnecessary network route, split an over-privileged identity, introduce an approval boundary, or constrain an agent tool—changes that reduce the consequence of future defects as well as the current one.