TL;DR: Trace one real request end to end, box everything each party controls, and mark every arrow that crosses a box: those crossings are the trust boundaries. For each one ask who can control what crosses and what checks it, on which side. Start there because vulnerabilities live at unchecked crossings, so the boundary list is the list of places a control can matter.
How to approach it
Say out loud that you will map before you judge. Ask two clarifying questions: what the system is for (which tells you the assets) and who uses it (which tells you the adversaries and their starting capability). Then pick one concrete request, such as "a customer uploads an invoice and gets a summary", and follow it through every component it touches. A real path keeps the sketch honest; an abstract architecture diagram hides the crossings.
A strong answer
Draw the components the request touches: client, edge, application servers, queues, data stores, third-party APIs, and for an AI feature the model provider, retrieval index and tools. Draw a box around each set of components controlled by one party with one level of trust. Every arrow that crosses a box edge is a trust boundary.
For each boundary write one line with three parts:
| Boundary | Who controls what crosses | What checks it, and where |
|---|---|---|
| Browser to API | Any internet user | Session auth and per-object authorization, server side |
| API to database | Our code, shaped by user input | Parameterised queries |
| Uploaded invoice to model | Whoever made the file | Nothing yet, which is the finding |
| Model to email tool | The model, influenced by the invoice text | Recipient policy enforced in the tool |
The third column is where the review happens. Three rules make it productive.
- The check belongs to the side that needs protection. A browser-side check protects nothing because the attacker owns the browser. A rule written into a system prompt is not enforcement because other text in the same context can override it.
- "Who can write to this?" beats "is this internal?" A ticket in your own database was written by a customer. A document in your index was written by whoever uploaded it. Internal storage does not make content trusted.
- Rank crossings by what is on the trusted side. A crossing that leads to a payment API, a signing key or another tenant's data outranks one that leads to a log line.
Only after the list exists do controls make sense, and each control is then tied to a crossing and an adversary. That is why you start here: it turns "add security" into a finite list of places where a specific check stops a specific attacker.
Upload
Invoice PDF
API
Auth + authz
Summariser
LLM call
Email tool
Sends results
Mark the crossings
Three arrows cross a box edge. Each is a question: who controls what crosses, and what checks it?
What interviewers probe next
- "The system is all internal microservices on one network. Are there still boundaries?" Yes. Services differ in what they may do; a crossing exists wherever a less privileged service can influence a more privileged one, network position notwithstanding.
- "How do you know you found them all?" You do not on the first pass. Walk a second request with a different actor, such as an admin or a background job, and compare; missing boundaries show up as arrows with no line in the table.
- "Where does the language model sit?" Inside your box for compute, but its output is shaped by every author in its context, so treat its output as crossing back from untrusted.
What if?
What if · interview follow-ups
Hold your answer as the constraints change
You are shown a diagram: a mobile app calls an API gateway, which calls an internal orders service and a third-party payments API, and writes to a database.
Start here
How do you find trust boundaries?
Who controls each component?
Trace one real request end to end, box everything each party controls, and mark every arrow that crosses a box. Those crossings are the trust boundaries.
Carry it forwardBoundaries are where control changes hands.
Weak answerTreating the whole system as one trust zone.
Constraint changes
What do you ask at each crossing?
What validates data entering each box?
Who can control what crosses, and what checks it, on which side. Vulnerabilities live at unchecked crossings, so each one needs a named check.
Carry it forwardAsk who controls the data and who checks it.
Weak answerAssuming the other side validated it.
Constraint changes
Which boundary is easiest to forget here?
Who controls the mobile app?
The mobile app to gateway crossing: the app runs on devices users control, so everything it sends is untrusted, including fields the app 'never changes', such as prices or user IDs.
Carry it forwardClient devices are untrusted.
Weak answerTrusting fields set by your own app.
Constraint changes
What about the payments API response?
Could the response be forged or wrong?
It crosses from a third party into your system. Verify signatures or call back to confirm status, handle failures safely, and do not trust amounts or statuses blindly.
Carry it forwardThird-party responses are inbound crossings.
Weak answerTrusting webhook or API responses without verification.
Constraint changes
What about internal calls?
Does the orders service check who is calling?
The gateway to orders service call crosses a boundary too: if the orders service trusts any internal caller, a compromised gateway or neighbour can do anything. Authenticate and authorise internal calls.
Carry it forwardInternal crossings need authentication.
Weak answerTrusting traffic because it is internal.
Now defend it
How would you analyse the diagram?
Trace a request, box each party's control and mark crossings: app to gateway (untrusted client data), gateway to orders service (internal authentication and authorisation), gateway to payments API and back (verify responses), and services to database (least-privilege accounts); then check what validates each crossing and on which side.
How it's scored
Weak: Lists controls (encryption, MFA, WAF) before naming any asset, adversary or data path.
Hire: Traces a real request, identifies the boundaries, and places checks on the server side with the right mechanism for each crossing.
Strong Hire: Also asks who can write to stored and retrieved content, treats model output as untrusted, ranks crossings by what sits behind them, and explains why a prompt rule is not a check.
Common mistakes
- Treating data in your own database as trusted because it is stored internally, when a customer wrote it.
- Drawing the network diagram instead of the trust diagram: one subnet can hold many trust levels.
- Proposing a check on the client side, or in the system prompt, for a rule that must hold against an attacker.
- Stopping at the inbound boundaries and forgetting outbound ones, where model output becomes an email, a query or a payment.