Trust boundaries, explained: where your assumptions change

Every component in a system makes assumptions about what reaches it. A handler assumes the caller is signed in. A query assumes the tenant identifier belongs to that caller. A worker assumes a message on its queue was put there by your own code. A trust boundary is any point where one of those assumptions is no longer guaranteed by the thing on the other side.

That definition matters because the common picture, a firewall between "outside" and "inside", hides most real boundaries. Two services in the same private network still trust each other differently. A support tool and a customer share a database but not a privilege level. A pipeline runner and a production cluster may sit in different clouds yet one controls the other. NIST's zero trust architecture makes the same point from the other direction: network location alone should never be treated as a reason to trust a request.

So the useful question is not "where is our perimeter?" but "at each hop, what does the receiver assume, and what makes that assumption true?"

Most boundaries fall into a handful of kinds. Naming them gives you a checklist to walk a design with.

• Exposure. Where traffic from a less trusted network arrives: the internet edge, a partner VPN, a public bucket, an open port on a build agent.
• Identity and privilege. Where the acting principal or its permissions change: a user request handled by a service account, a token exchanged for a broader one, an operator assuming an admin role.
• Tenant. Where one customer's data or actions must stay separate from another's, often inside the same process and the same table.
• Execution. Where code you didn't write, or input you don't control, gets to run or decide: plug-ins, user-supplied templates, third-party SDKs, a language model choosing a tool.
• Administrative domain. Where a different owner sets the rules: another cloud account, a vendor's SaaS, a partner's API, a separate team's platform.
• Data sensitivity. Where data moves into a place with weaker protection or a wider audience: production records copied to analytics, secrets written to logs, files exported to a customer.

A single hop can cross several at once. A webhook from a payment provider crosses exposure, administrative domain and, once you process it, tenant boundaries.

Boxes on a diagram show what exists. Requests show what crosses. To map boundaries, pick an entry point and follow one real request all the way to the data it touches, then follow the asynchronous work it causes.

At each hop, ask four questions and write the answers next to the arrow:

1. Who sent this, and how do we know? A session, a signature, a workload identity, or nothing at all.
2. What does the receiver assume? That the caller may see this record, that the amount is positive, that the event is new.
3. What checks that assumption, here? Not "somewhere upstream". If the check lives in another component, the receiver is trusting that component, which is itself a decision to record.
4. What happens if the check is missing or wrong? This tells you which boundaries deserve depth.

Teams that do this for their five most important flows usually find more boundaries in an afternoon than their diagrams show in total.

A boundary without a control is just an observation. For each crossing, name the mechanism that enforces the receiver's assumption, and make it the receiver's job wherever you can.

• Internet to edge: TLS, authentication, rate limits, request size limits and schema validation before anything reaches business logic.
• Edge to service: the service authorises every request for the specific object, using claims it can verify. Authentication at the gateway answers who, never may they.
• Service to service: mutual authentication with workload identities, and authorisation on the callee, so a compromised neighbour cannot call everything.
• Into a tenant: derive the tenant from the verified identity, never from a request field, and enforce it again at the data layer with row-level security or per-tenant keys.
• From another owner: verify signatures on inbound webhooks, reject replays, and allow-list outbound destinations so a bug cannot send your data anywhere.
• Into a weaker data zone: classify before copying, mask or tokenise what the destination does not need, and keep secrets out of logs entirely.

A few crossings appear in incident reports far more often than on architecture diagrams.

• Queues and event buses. A message is input. If anything can publish to a topic, everything that consumes it sits behind a boundary.
• Internal and support tools. Admin consoles and impersonation features cross the tenant boundary by design. They need the strongest authentication you have, and their use should land in an audit log.
• Batch jobs and migrations. They often run with broad database roles and skip the API's authorisation entirely.
• Build and deploy runners. A runner that can deploy to production is part of production's boundary, wherever it runs. See securing CI/CD and deployment paths.
• Language models and agents. Text a model reads can carry instructions. Treat a model's output, and any tool call it proposes, as untrusted input crossing an execution boundary.
• Observability pipelines. Logs and traces leave the protected data zone by design. If secrets or personal data reach them, the boundary has moved without anyone deciding it.

Boundaries change whenever the system does: a new integration, a new queue consumer, a new region, a new vendor. A boundary map that is not refreshed becomes a list of the boundaries you used to have.

Treat the map as a living artefact. Keep it close to the code and infrastructure that define it, review it whenever a change adds an entry point, identity, data flow or dependency, and prefer a model rebuilt from evidence over a drawing maintained by hand. For how boundaries feed path analysis and blast radius, read deriving trust boundaries and blast radius from architecture evidence.