A last check that attacks your code like a hacker would
On Deep work, this reviewer reads your finished code as a malicious user who knows it well. It looks for real ways in, such as one customer reading another customer's data. Every top-severity finding must name the exact file, the line and how the attack works.
How to use it
You never start it yourself. When you run /tlmforge:build and TLM Forge rates the task Deep, it starts this reviewer once during the final review (Stage 5), alongside the other reviewers. Medium tasks skip 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.
- Final review (Stage 5)
- The review that runs once all the code is built and every test passes.
- Diff
- The exact lines of code that were added, changed or removed.
- CRITICAL, HIGH, MEDIUM, LOW
- How serious a finding is: CRITICAL blocks shipping, HIGH must be fixed before launch, MEDIUM should be fixed, LOW is nice to fix.
- IDOR
- A bug where changing an ID in a request lets you see or change someone else's data.
- Residual list
- A written list of smaller known issues left for you to decide on later.
What it looks for (8 of its 12 attack types)
| What it looks for | An example of what it catches |
|---|---|
| Reading data that is not yours (IDOR) | Changing the invoice number in a link shows another customer's invoice. |
| Timing races | A balance is checked, then changed by a second request before the money is spent. |
| Checks in the wrong order | The code logs or counts something before it checks who you are. |
| Injection (SQL, shell, HTML) | User text is pasted straight into a database query. |
| Reusing a copied token | A login token with no expiry check keeps working forever once copied. |
| Prompt injection | User text flows into an AI model's system message. |
| Leaking personal data | Logs print whole user records, or an error returns a stack trace. |
| Clues that reveal accounts | Different errors for "no such user" and "wrong password" tell an attacker who has an account. |
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. The final review uses two other reviewers (three 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, in the final review. |
What it does
Most reviewers ask whether your code works for an honest user. This one asks how someone could abuse it. Its instructions tell it to act as a malicious user who knows the code, the live setup and what the system can do. That finds a different kind of bug: the kind that can pass every normal test.
It reviews the finished code, not the plan. First, TLM Forge gives it a short brief listing the risky parts of the change, such as login code or steps that cannot be undone. It reads those files in full and tries its attack ideas in its own separate copy of the repo. Attack review of the plan happens earlier, by a different reviewer, the threat-modeler.
It is told to stay quiet unless it is confident. A CRITICAL needs a real attack, from input to damage, at an exact file and line. About 70% sure means HIGH, about 50% means MEDIUM, and anything less is not reported. Its instructions say a noisy red-team reviewer is worse than none, because a false alarm costs a round of fixes.
How it works, step by step
The feature is built and tests pass
On Deep work, once every part is built and all tests pass, TLM Forge starts the final review. Five reviewers run side by side, plus a UX reviewer if screens changed.
It reads a short brief
The brief lists what changed and which parts are risky. Risky files are read in full.
It tries twelve kinds of attack
They range from reading other people's data to timing races, injection and token reuse. It tests its ideas in its own copy of the repo.
It rates each finding
How sure it is sets how serious the finding is. Code that looks risky but is made safe elsewhere is not flagged.
Serious issues get fixed
CRITICAL and HIGH findings are fixed, each with a failing test written first. Smaller ones go on the residual list, and a CRITICAL that cannot be fixed comes to you.
What it looks like
One finding as this reviewer writes it. It says the code should not ship, points to line 18 of billing/routes.py, explains the attack and suggests a fix. The field names are real; the content is made up for illustration.
{
"reviewer": "red-team-reviewer",
"verdict": "do_not_ship",
"findings": [{
"severity": "critical", "category": "auth",
"file": "billing/routes.py", "line": 18,
"finding": "Invoice.get(id) checks login, not ownership: any user reads any invoice (IDOR).",
"suggested_fix": "Load by (id, owner=current_user) and return 404 for both missing and foreign ids."
}]
}Why it is better
Catches the bugs normal tests miss
Without TLM Forge, your tests check that the code works for honest users. With it, one reviewer is told to assume the opposite and hunts the abuse cases those tests never try.
Fresh eyes on the code
Without it, the session that wrote the code reviews its own work and shares its blind spots. With it, the reviewer starts fresh, with only the brief and the changes.
Alarms you can act on
Without clear rules, security reviews fill up with maybe-problems. With it, a CRITICAL must name the file, the line, the attack and a fix, so a failing test can be written right away.
Good to know
- Deep only. Medium tasks get a smaller final review with no attacker pass. 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 per task. After the fixes, there is at most one short re-check, and only when the fixes changed more than 150 lines or touched a risky area. You can ask for another review; TLM Forge will not start one on its own.
- It is a reviewer, not a security scanner. It does not replace dependency audits, penetration tests or a security team.
- If it fails to hand in its result, TLM Forge records that as a CRITICAL, so a silent reviewer never looks like a clean pass.
- After the review, a check built into the plugin blocks commit, push and merge if the code changes again (other than docs), until that new change is re-reviewed or you accept the residual list. Set TLMFORGE_HOOKS=0 to turn these checks off for one session.