Why is tenancy a trust boundary on a data-flow diagram even when both tenants share one subnet?

## What a trust boundary actually is On a data-flow diagram (DFD) you draw four kinds of thing - external entities, processes, data stores and data flows - and then one more: a **trust boundary**, a line crossing the flows at every point where the level of trust changes. The word *trust* is doing all the work. The test is not *does traffic change network segment*, it is: **on one side of this line, is a different principal authorised to do different things?** If the answer is yes, there is a boundary, whatever the topology looks like. Tenancy is the purest instance of that test. Two tenants of the same system are, by definition, mutually unauthorised: nothing about tenant A's identity entitles it to tenant B's data. That is a trust change of the strongest kind, and it exists whether the tenants are separated by continents or are two rows in one table. ## Why the network keeps fooling people The habit of drawing boundaries at firewalls and subnets comes from a perimeter era where the network *was* the authorisation model. It fails in two directions at once: - **Same network, different trust.** The shared CI runner pool: two business units, one VPC, one pool of runners, one artifact cache. Nothing on a network diagram distinguishes them. But unit A's build must not read unit B's source, and unit B's cached deploy credentials must not be reachable from unit A's job. There is a boundary between those two jobs, and it is invisible on any network drawing. - **Different network, same trust.** A service and its own replica in another region cross a WAN link and change nothing about who is authorised to do what. Drawing a boundary there produces noise: you will spend the session enumerating threats against a line no attacker cares about. A useful discipline: after you draw a candidate line, say out loud *the privilege that changes here is ___*. If you cannot finish the sentence with an authorisation statement - a different principal, a different set of rights, a different owner of the data - erase it. And conversely, walk the diagram looking for privilege changes with no line on them; that is where missed threats live. ## What appears once the tenancy line is drawn A boundary is not decoration; it is the input to enumeration. With the line between unit A's job and unit B's job on the page, the categories fall out naturally: - **Information disclosure** (confidentiality): unit A's job reads unit B's checked-out source or build artifacts from a shared workspace that was not wiped. - **Elevation of privilege** (authorisation): unit A's job harvests a deploy credential left in the runner's cache or environment and then acts with unit B's rights. - **Tampering** (integrity): unit A poisons a shared dependency or layer cache that unit B's build later consumes. - **Repudiation** (non-repudiation): both units' jobs run as the same machine identity, so an action cannot be attributed to the unit that caused it. - **Denial of service** (availability): one unit saturates the pool and starves the other. None of those threats can even be phrased on a diagram whose only line is the internet edge. That is the practical cost of confusing topology with trust: not a wrong answer, an *absent* question. ## Boundary versus control Keep the four words separate. A **threat** is what could go wrong (unit A reads unit B's source). A **vulnerability** is the flaw that permits it (the workspace is not cleaned between jobs). A **risk** is the rated consequence. A **control** is what you do about it (per-tenant runners, ephemeral workspaces, scoped short-lived credentials, per-tenant identities). Adding a control does **not** move or delete the boundary. If you give each business unit its own runner pool and its own subnet, the line stays exactly where it was - it now simply has a mitigation attached. Teams that erase the line once they segment lose the record of *why* the segmentation exists, and the next refactor quietly re-merges the pools with nobody able to say what that broke. ## Single-tenant deployments do not remove it A common rebuttal is *we deploy a separate stack per customer, so there is no tenancy boundary*. The boundary moves rather than disappears: something provisions, upgrades and operates all those stacks, and that control plane touches every tenant. The shared element is now the pipeline and the operator identity, so the tenancy boundary is drawn there. In threat modeling terms you have not removed a trust change, you have relocated it to a place with more privilege than the one you started with.