In threat modeling, what is an actor assumption and how does it bound the threats you keep?
answer
- the who, not the what
- no threat is in scope on its own
- three dials on the adversary
- capability, resources, access
- unwritten ones still bind the model
basics
~20 sAn actor assumption is a written statement of the adversary you defend against: their capability, resources and access. It bounds the model, because a threat stays in scope only if that assumed actor could reach and carry it out.
solid answer
~50 sAn actor assumption records who the model defends against, on three dials: **capability** (what they can technically do), **resources** (time, money, patience) and **access** (where they already stand — anonymous on the internet, an authenticated tenant, a colleague with credentials, someone holding the hardware, a package maintainer inside your build). It matters because no threat is in or out of scope on its own; it is in or out relative to an assumed actor, and every triage decision and every claim that a control is sufficient silently depends on that bound. Refusing to bound it does not make the model safer — an unlimited actor leaves nothing triageable. Every model already has these assumptions; the discipline is writing them down, with an owner and a revisit trigger, so they can be challenged and so you know which findings to re-examine when one moves.
go deeper
Be ready to say that a threat model states who it defends against, and that whether a threat counts depends on that choice. Knowing the three dials by name — capability, resources, access — is enough at this level.
Explain the mechanics: how each dial changes which threats survive triage, and why an unbounded adversary makes a model useless. Expect to be asked for a concrete example of a threat that is in scope for one actor and out for another.
Show the production habit: assumptions written into the model with owners, ratings carrying rationale so you can tell which ones were assumption-dependent, and a bounded re-model when a dial moves rather than a rewrite.
Own the framing that bounding the actor decides what the organisation leaves untreated, so it is a business call needing an accountable owner and a revisit trigger — and that the more irreversible the design decision it justifies, the less weight the bound should carry.
## What an actor assumption is A threat model has three anchoring choices: what you are protecting (the asset), what would count as harm (the security goal), and **who you are defending against** (the actor). An *actor assumption* is the third one, written down: an explicit statement of the adversary's **capability**, **resources** and **access** that the rest of the model is allowed to rely on. It is not a character sketch and it is not a motive. It is a bound. Everything downstream — which threats you enumerate, which ones you triage out, which controls you call sufficient — is only meaningful relative to that bound. "This flow is protected" is not a statement about the flow; it is a statement about the flow *and* an assumed adversary. Change the adversary and the same sentence can become false without a line of the design changing. ## The three dials - **Capability** — what the actor can technically do. Read traffic on a shared network? Write a malicious build step? Develop a bespoke exploit for a bug nobody has published? Coerce a person? - **Resources** — what the actor can spend: time, money, headcount, patience. An opportunist who moves on after ten minutes and a funded group that can pay a call-centre agent for a verification bypass have the same technical menu and produce very different surviving threat sets. - **Access** — where the actor already stands. Anonymous on the internet, an authenticated tenant on the platform, a colleague with legitimate credentials, someone holding the physical device, a maintainer of a package you build against, an operator at your cloud provider. Access is the dial people under-set most often, because a model drawn as a data-flow diagram invites you to think of the attacker as arriving from the outside edge. An insider and a compromised dependency both start **inside** a boundary you already drew as trusted, which is exactly why they break models that were never wrong about the mechanics. ## Why an unbounded actor is useless Teams sometimes try to be conservative: "assume an attacker with unlimited time, money and access." That is not conservative, it is inert. Under that actor no threat can be triaged out, every control is insufficient, and the model produces a list you cannot act on. Bounding is what makes triage possible, and triage is the point of modeling. The honest move is to pick a bound you can defend and to record what you chose *not* to treat, rather than to pretend you treat everything. ## An unstated assumption is still an assumption Every model already has actor assumptions; the only question is whether they are written down. When a team says "an admin would never do that" or "our dependencies are fine" or "nobody gets unsupervised time with the hardware", they have set a dial. Unwritten dials cause three specific failures: they cannot be challenged in a review, they cannot be tested against reality, and when the world changes nobody knows which findings need re-examination — because nobody recorded which findings rested on what. The practical fix is small: a short section in the model listing the assumed actors, one line each for capability, resources and access; an owner; and a revisit trigger for each. ## How a changed assumption propagates The useful discipline is that changing one dial does **not** invalidate the whole model. It invalidates the threats whose *reachability* depended on the dial you moved. A worked pass looks like this: 1. State the change precisely: which actor, which dial, from what to what. 2. Mark the elements — processes, stores, flows, external entities — the new actor can now touch. 3. For each existing threat on those elements, re-ask whether it was triaged out *because of* the old assumption. Those come back. 4. Enumerate the threats that only make sense for the new actor at all (authorised misuse, attribution loss, tampering at build time). 5. Re-check controls: any control whose strength came from the old assumption is now unsupported, even though nothing about it changed. Step 5 is where the surprises live. Supervision, "only staff can reach this network", "the package registry gives us what we asked for" — these are load-bearing assumptions dressed as background facts, and when one moves, several controls quietly stop working at once. ## Bounding is a choice with an owner Because an actor assumption decides what goes untreated, it is a business decision wearing an engineering hat. The engineer drawing the diagram can propose the bound; the person who owns the consequence if it is wrong should agree to it. Recording that agreement, with a date and a trigger for revisiting, is what separates a bounded model from a model with a blind spot. ## Common failure modes - Naming actor types with no dials attached, so the label does no work in triage. - Assuming insiders and dependencies are out of scope by default, without saying so. - Setting the actor after enumerating threats, so the bound is chosen to keep the list short. - Never revisiting: the assumption was true at launch and nobody re-opened it when the customer base, the data or the deployment surface changed.
- A team says it assumes an attacker with unlimited time, money and access. What is wrong with that?It looks conservative and is actually inert. Under an unbounded actor no threat can be triaged out and no control is ever sufficient, so the model yields a list with no priority and no decisions. Bounding is what makes triage possible. The honest version is a bound you can defend plus a written record of what you are consciously not treating.
- Where should an actor assumption live so it actually gets revisited?In the threat model document itself, as a short list: each assumed actor with one line each for capability, resources and access, a named owner, the date, and a trigger that would force a review. Ratings should carry their rationale too, so when a dial moves you can tell which findings rested on it instead of re-deriving the whole model.
- Why do insider and compromised-dependency actors break models that were otherwise correct?Both start inside a boundary the diagram already drew as trusted, so the model's mechanics are right while its bound is wrong. The insider does not cross the perimeter you drew, and a compromised package arrives inside a process you labelled as yours. Threats then appear on flows nobody diagrammed, and edge-facing controls do nothing about them.
Specifying a lock is meaningless until you say who is meant to fail at it: a lock rated for a passer-by and one rated for a locksmith with an hour alone are different products. The actor assumption is that sentence, written before you choose the lock.
saying these in an interview costs you the question
- Assumes an omnipotent attacker, so nothing can be triaged out
- Names actor types but never states capability, resources or access
- Treats insiders and dependencies as out of scope without saying so
- Leaves the assumption implicit in one engineer's head
- Confuses the assumed actor with the asset being protected
- Picks the actor after enumerating threats, to keep the list short