2 min lesson
Threat-model a system live
Explain the order in "Threat-model a system live", then say how you would verify the result.
Step 1 of 3
Expect a threat-modeling round that hands you a prompt and a whiteboard and watches how you reason about trust. Two prompts are worth drilling for this role: design just-in-time cloud access or design a safe agent-execution sandbox. Pick one, set a 30-minute timer and work it through trust boundaries, attacker goals, mitigations and the friction tradeoff.
There's no diagram tool in your head, so work the structure explicitly. A threat model is four questions in order: what are we building, what can go wrong, what do we do about it and did the mitigations hold. It's easy to jump to mitigations and skip the boundaries, and the boundaries are where your reasoning shows.
Learn more
Advanced table
Worked example: just-in-time cloud access
Worked example: just-in-time cloud accessTrust boundaries and the controls that fit
- Trust boundary
- Engineer → cloud IAM
- Attacker goal
- Use standing admin creds found on a laptop
- Systemic mitigation
- No standing access; JIT grant, scoped role, auto-expires in hours
- Trust boundary
- Approval flow → grant issuance
- Attacker goal
- Self-approve or replay an old approval
- Systemic mitigation
- Approver ≠ requester; grants are single-use and time-boxed
- Trust boundary
- Granted session → cloud APIs
- Attacker goal
- Pivot from one service to the whole account
- Systemic mitigation
- Role scoped to the one resource/action; deny by default
- Trust boundary
- Audit → detection
- Attacker goal
- Act without leaving a trace
- Systemic mitigation
- Every grant + API call logged immutably, alert on anomalies
| Trust boundary | Attacker goal | Systemic mitigation |
|---|---|---|
| Engineer → cloud IAM | Use standing admin creds found on a laptop | No standing access; JIT grant, scoped role, auto-expires in hours |
| Approval flow → grant issuance | Self-approve or replay an old approval | Approver ≠ requester; grants are single-use and time-boxed |
| Granted session → cloud APIs | Pivot from one service to the whole account | Role scoped to the one resource/action; deny by default |
| Audit → detection | Act without leaving a trace | Every grant + API call logged immutably, alert on anomalies |
Each row pairs a boundary with the control that shrinks blast radius there.
The least-privilege story is the spine of this answer. Standing permissions are a constant liability: every credential that exists is a credential that can leak. JIT flips the default: zero standing access, a scoped grant when you prove you need it, automatic revocation when the window closes. The blast radiusHow much breaks if a change goes wrong; the scope of potential damage. Press Enter for the full definition. of a stolen laptop drops from "the whole account, forever" to "one resource, for two hours, fully logged."