A trust boundary is a line in a system where data or calls pass between parts that trust each other differently: the public internet and your API, your service and the customer’s database, an uploaded spreadsheet and your parser, a language model’s output and the tool it calls. Whatever crosses it must be authenticated, authorized and validated at that line, because the far side cannot be assumed honest or correct. OWASP’s threat modeling process draws these boundaries on data flow diagrams, where they mark the change of trust level as data flows through the application.
In FDE interviews
Trust boundaries belong in any design answer where a system takes in customer data: a bulk import service that accepts spreadsheets, a notebook model moving into production inside the customer’s environment. Ask what the customer’s security team needs before go-live, as the lesson Enterprise system design is not ‘design a social network’ recommends; the answer tells you where the boundaries are. A strong candidate draws the boundaries before the components and says what is checked at each: “Uploads cross from the customer’s browser into our service here, so this is where we authenticate the user, take the tenant from their token and never from the form, cap the file size and validate every row before anything is written. There’s a second boundary here: the model’s output crosses into the tool that writes to their system, so it gets the same checks as user input.” Our design rubric scores trust boundaries and identity as a dimension of its own.
The lesson Walking skeleton and trust boundaries first shows how to design the thinnest deployable version with its boundaries marked, then the path to production.