Threat Model Trust Boundary
The line across which data or control passes from a less trusted context to a more trusted one, and where validation and authorisation must occur.
Trust boundaries are where security controls belong, and drawing them correctly is most of what threat modelling achieves. Every other question — what can go wrong here, what mitigates it — becomes answerable once the boundaries are on the diagram.
The boundaries that get missed are the informative ones. Between the browser and the server is obvious. Between two internal services is one that many architectures deny exists, on the assumption that the internal network is trusted — which is precisely the assumption zero trust rejects and lateral movement exploits. Between an application and its database. Between tenants in a shared system. Between the control plane and the data plane. And, increasingly, between a model's context window and the tools it can invoke, since retrieved content is untrusted input crossing into a privileged execution context.
The practical use in review is to trace each data flow across each boundary and ask three questions: what authenticates the caller here, what authorises this specific action against this specific resource, and what validates the content of what is being passed.
The most common finding is authorisation performed only at the outermost boundary, with everything inside trusting that it happened — which fails the moment any component can be reached by another path, and there is always another path eventually.