Spot security mistakes baked into the plan itself
On Deep work, this reviewer reads the written plan as the build begins. It asks one question: what does this design take for granted that an attacker could break? Caught early, the fix is usually a plan change, not a rewrite.
How to use it
You never start it yourself. On Deep tasks, /tlmforge:build starts it once, at plan review (Stage 3), next to the architect and tester reviewers. It works in the background while building begins. Medium tasks do not use it. Say "go deeper" to move a task up to Deep.
Words you will see on this page
- Deep
- TLM Forge's most thorough level, used for new features or for anything that changes how the system makes security decisions.
- Plan review (Stage 3)
- The step where separate reviewers read the written plan, in the background, while the build starts.
- Master plan
- The written plan for the feature: what will be built, and in what steps.
- Trust boundary
- Any point where data passes between parties, such as from a user to your server, or your server to an email service.
- PII
- Personal information, such as names, email addresses or phone numbers.
- CRITICAL
- The most serious level of finding: a real problem that must be dealt with before shipping.
What it looks for
| What it looks for | An example of what it catches |
|---|---|
| Channels treated as private | A share link carrying its access key is emailed, but mail archives keep a copy. |
| Trust boundaries | The plan assumes data sent to a log service stays private there. |
| Sign-in assumptions | Anyone holding the link is assumed to be the person it was sent to. |
| Missing permission checks | A flow assumes one user can never ask for another user's data, without checking. |
| Where personal data goes | Report titles or email addresses end up in logs, analytics or crash reports. |
| Trusting third parties | The plan assumes a webhook signature alone proves a request is genuine. |
| Injection built into the design | The plan sends user text straight into a database query or a web page. |
| Encryption assumptions | A one-time token is assumed to be impossible to use twice at the same moment. |
When it runs
| Level | What the task is | Does this reviewer run? |
|---|---|---|
| Light | A tiny change you can read in ten seconds, like a typo, a rename or a config value | No. Claude makes the change directly, test first, with no review agents. |
| Medium | Fixing or improving something that already exists, with nothing new for users | No. Medium work adds no new way in for attackers, so plan review uses the architect and tester (plus the ux-reviewer if the change has a user interface). |
| Deep | Something new (a feature, screen, endpoint or integration), or anything that changes how the system makes security decisions | Yes, once, when the plan is reviewed. |
What it does
Some security bugs are decided in the plan, not typed in the code. If the plan says "email the user a link with the access key in it", the code can be perfect and still leak. This reviewer reads the plan while it is still a plan. It does not review code or judge design quality; other reviewers do that.
For every flow in the plan, it asks the same eight questions. Where does data pass from one party to another? Which channels, such as email, logs or web addresses, are treated as private? Who is assumed to be signed in? Which actions skip a permission check? Where does personal data go? What is a third party trusted to check? Where could user text reach a database or page? What encryption is quietly assumed safe?
It is told to be specific. Every finding must say "this design assumes X" and how an attacker breaks X, or be downgraded or dropped. Vague warnings do not count. Its findings arrive while building is under way, and a serious flaw in the plan itself comes to you instead of being patched quietly.
How it works, step by step
The plan is written
On Deep work, once the plan is done, TLM Forge starts this reviewer with the architect and tester reviewers. A UX reviewer joins if the plan includes screens.
It reads the plan with fresh eyes
It sees only the plan documents. It has not seen the conversation that produced them.
It asks eight questions per flow
Trust boundaries, private channels, sign-in, permissions, personal data, third parties, injection and encryption.
It writes its findings
A short report plus a structured file. Findings about the plan point to "architecture" instead of a line of code, and every CRITICAL needs a suggested fix.
Findings are handled during the build
Building starts without waiting. Serious issues that code can fix are fixed during the build; a serious flaw in the plan itself is paused and brought to you.
What it looks like
One finding as this reviewer writes it. "file": "architecture" means the problem is in the plan, not in a line of code. The field names are real; the content is made up for illustration.
{
"reviewer": "threat-modeler",
"verdict": "needs_revision",
"findings": [{
"severity": "critical", "category": "security",
"file": "architecture", "line": null,
"finding": "Design assumes email is a confidential channel; the share token sits in the URL.",
"suggested_fix": "Email a notification link only; require the recipient to sign in before viewing."
}]
}Why it is better
Fixed while it is still a sentence
Without TLM Forge, a risky design choice is often found after the code exists, when code and data must change. With it, the problem is caught while changing the plan is cheap.
A reviewer with one job
Without it, security assumptions get a quick glance in a general review. With it, one reviewer looks only at what the plan trusts, a kind of bug the architect and tester are not hunting.
Findings you can decide on
Without clear rules, threat reviews fill up with generic warnings. With it, every finding names the assumption and how it breaks, so you can accept it, reject it or change the plan.
Good to know
- Deep only. Medium tasks fix existing behavior and add no new way in for attackers, so their plan review uses the architect and tester (plus the ux-reviewer for user interface work). TLM Forge's rules tell Claude to rate any change to how the system makes security decisions as Deep: login logic, handling of passwords or keys, who can access personal data, encryption, sessions or access control.
- It runs once, at plan review. It does not look at the finished code; the red-team-reviewer does that in the final review (Stage 5).
- Building starts without waiting for it, and its findings arrive during the build. Every plan reviewer must finish before the final review starts.
- It reads documents, not running systems. It does not scan dependencies or test the live app.