"Is this secure?" is a question with no answer, because secure against whom? A locked front door is plenty against a curious neighbour and useless against a person with a crowbar. A is how you replace the vague question with a specific one. It is the most useful habit in this whole course, and you can do it on paper in fifteen minutes.
The four questions
- What are we protecting? The valuable things, called : data, accounts, money, uptime, reputation.
- Who might attack it, and why? The threat actors and their motives.
- How could they get at it? The paths from them to the asset.
- What will we do about it? The controls, chosen in order of payoff.
Last lesson gave you the vocabulary for question 1: for each asset, which of confidentiality, integrity and availability matters?
Assets: start with what hurts to lose
List the things whose loss would hurt, not the things that are merely interesting to you. For a small online shop that might be customer emails and addresses (confidentiality), the price list (integrity, since a changed price is a direct loss), and the checkout page (availability). Rank them. You cannot protect everything equally, and pretending to is how you protect nothing well.
Actors and motives
A is anyone who could cause harm on purpose. What they want shapes what they try:
| Actor | Typical motive | Typical behaviour |
|---|---|---|
| Opportunist running automated scans | Money, at low cost | Tries known weak spots on every address it can find; not targeting you in particular |
| Criminal group | Money | Steals data to sell, or locks systems for ransom |
| Insider or former employee | Grievance, gain | Already has some access |
| Competitor or state-backed group | Information, disruption | Patient, well resourced; rare for small targets |
| A curious or careless user | None | Not an attacker, but a frequent cause of incidents |
Be honest about who is realistic. For the shop above, the opportunist and the careless user matter most. Designing against a nation state while leaving a password as shop123 is a classic misallocation.
Paths and trust boundaries
Draw the system as boxes and arrows: the visitor's browser, your website, your database, a payment provider. Now draw a dashed line wherever the level of trust changes. That line is a .
Data crossing a trust boundary is the important moment. Text typed by a visitor is untrusted when it enters your website, so your site must check it before using it. The path from website to database is inside your boundary, so it can be trusted more, but only as long as the website itself behaves.
Most attacks you will study cross a boundary in a way the designer did not expect: an input treated as an instruction, a low-trust account reaching high-trust data, a file from outside executed inside. The earlier lesson on how programs run applies: the question at every boundary is who is allowed to make this thing run.
Choosing what to do
For each plausible path, you have four honest options:
- Reduce it: add a control (stronger login, narrower permissions, input checks).
- Remove it: delete the feature or the data that creates the path.
- Accept it: decide the harm is small or unlikely and write that down.
- Transfer it: for example, buy insurance, or let a payment company hold card numbers so you never do.
Rank by two things: how likely and how bad. A likely, severe path comes first. An unlikely, mild path may be accepted. That ranking, informally, is : likelihood combined with impact. The skill is writing a small list and being honest about the order.
Your shop stores customer emails. Name one asset, one realistic threat actor and one path.
Asset: the customer email list. Actor: a criminal group that buys and sells contact lists. Path: an admin page with a weak password, or a database backup left in a publicly readable folder. Any consistent triple like this is a fine answer.
A tiny worked threat model
Take a personal notes app that you host on a rented server for yourself and two friends.
- Assets: the notes (confidentiality), their continued existence (availability), the server login (if stolen, everything is exposed).
- Actors: automated scanners that try common passwords on any server they find; a friend whose laptop gets infected.
- Paths: the login page facing the internet; a friend's saved password; an unpatched server program.
- Choices: require long unique passwords and a second factor (reduce), close any port nobody uses (remove), accept that a state-level attacker is out of scope (accept, noted), keep a weekly backup elsewhere (reduce availability risk).
That is four lines per question, and it already tells you what to do on Saturday morning.
How AI changes this
An AI agent changes the model in two ways, and one of them is genuinely new.
New actor and new asset. A coding agent on your laptop is a program that acts with your permissions: it can read your files, run shell commands and use whatever credentials are lying around. In a threat model it appears twice. It is an asset to protect (its access is valuable), and it is a path (if someone steers it, they inherit that access). Microsoft's treat AI agents as insiders piece argues for exactly this framing: model an agent like a new employee with broad access, not like a tool.
New trust boundary. The agent reads text from places you do not control: web pages, issue comments, documents, tool descriptions. It cannot reliably tell instructions from data. So every piece of untrusted text it reads is a boundary crossing into something that can act. A useful quick test is to ask whether one agent session combines three things: it reads untrusted text, it can reach private data, and it can send things out. When all three are true, injected text can turn into a leak (see and ). Remove any one and the risk drops sharply.
Attackers have AI too. Automated scanning was already common; AI makes writing convincing phishing and adapting known attack steps cheaper. That raises the likelihood of the opportunist actor, not the existence of new kinds of attacks. For your threat model it means: assume more attempts, sooner, at lower cost to the attacker.
Defenders can use it. A model can help you draft the first pass of a threat model, enumerate paths you forgot, and sort alerts. Treat that as a brainstorming partner. It does not know your system's real trust boundaries unless you tell it, and it will happily produce a plausible, wrong diagram.
Try it
Pick something you own: a home Raspberry Pi, a side project, or your laptop with a coding agent installed. In a text file, answer the four questions in no more than a page. Use this skeleton:
ASSETS (and which of C / I / A matters)
-
ACTORS (realistic ones, and their motive)
-
PATHS (where does untrusted input or access cross into the thing?)
-
DECISIONS (reduce / remove / accept / transfer, in priority order)
-
Then do the one item at the top of your DECISIONS list today. Nothing here touches anyone else's systems; it is an exercise on your own.
Check yourself
Why is 'we need to be secure' not a threat model?
It names no asset, actor, path or action, so it cannot guide a decision. A threat model is specific: which thing, against whom, through what route, and what we will do.
Where would you draw the trust boundary for a form on your website that saves what visitors type?
Between the visitor's browser and your server. Everything arriving from the browser is untrusted until your server checks it.
A coding agent reads a web page containing hidden text that says to upload your SSH key. Which part of a threat model does this illustrate?
A trust boundary crossing: untrusted text from the web enters a system that can act with your permissions, and the agent cannot reliably tell the text is data rather than a command. The mitigation is to remove a leg of the risk, for example by keeping the key out of the agent's reach or blocking its outbound connections.
Next
A threat model lists paths in. Next we measure them: what is an attack surface, and how do you shrink it?