Published August 23, 2026 · one of the RedMirror role playbooks
A triage that ends in "looks exploitable" is not a triage. This playbook shows how to use RedMirror Reflection to confirm or refute a suspected report with a kernel-verified attack path: you state the security rule, the kernel searches every reachable state, and it returns the exact call a non-privileged user makes to break it — or a proof that none can.
Everything below is a real run. We handed Reflection a suspected privilege-escalation report against a small user-admin module, driven by a cheap model through a coding agent, and let the kernel settle it.
Your queue is full of "possible" findings: a scanner alert, a developer's worry, a pentester's note. The expensive part is separating the real ones from the plausible ones, and a confirmation that rests on your own reading is only as strong as your reading. Reflection gives triage a hard output: a reachable attack path when the report is real, a bounded proof when it is not. Either way, the next person does not have to re-derive your judgement.
The report claims a non-admin can change another user's account status. The module has two lifecycle actions; one guards the caller's role, the other was added later and does not.
// admin.js function suspendUser(caller, target) { if (users[caller].role !== 'admin') throw new Error('forbidden'); // guarded status[target] = 'suspended'; } function banUser(caller, target) { status[target] = 'banned'; // no role check }
The agent modelled the module as a state machine (the caller's role, the target's status, and whether an authorization check ran) and stated the rule: any change to a non-active status must have been preceded by an authorization check, i.e. auth_checked || target_status == 'active'. The kernel refuted it.
$ docker run -e ROLE=security-analyst ... reflection-playbooks == PHASE 2 — reflect: find + prove (deepseek/deepseek-v4-flash) == claim REFUTED and answer matches — GROUNDED, stamp c98abd6920d2e44b The kernel's attack path (2 steps): 1. <init> caller_role=admin, target_status='active', auth_checked=false 2. banUser target_status='banned', auth_checked=false # no guard == PHASE 3 — gate == reflection: finding(s) grounded, nothing left open. audit exit: 0
The kernel picks one concrete value from the domain; caller_role='user' works identically — the step has no guard at all.
Expressed against the code: mallory (role user) calls banUser('mallory', 'alice'). Because banUser performs no authorization check, it sets status['alice'] = 'banned' and succeeds. The report is confirmed, and the confirmation is a reproduction.
This is the part that makes the confirmation trustworthy: the kernel rejects sloppy claims. In this run the model's first attempt referred to fields it never declared, and the kernel refused to ground it.
REVISE: your claim came back INVALID: undeclared name(s): suspended, banned. The kernel reads an undeclared identifier as 0, which can fake a proof. Fix it and re-submit — an INVALID/INCONCLUSIVE claim verifies nothing.
Only after the claim was corrected did the kernel run its search and refute the rule. A finding is grounded when a faithful claim is refuted by exhaustive search — not when a model sounds confident. That is the difference between a triage you can forward and an opinion you have to defend.
| What the kernel returned | Value |
|---|---|
| Verdict | REFUTED (kernel gate: GROUNDED) |
| Attack path | <init> → banUser (reaches 'banned' with auth_checked=false) |
| Rule broken | auth_checked || target_status == 'active' |
| Concrete | mallory (role user) bans alice |
| Gate stamp | c98abd6920d2e44b |
| Weakness | Missing authorization, CWE-862 / CWE-863 |
# the published playbook harness docker run --name pb-security-analyst \ -e OPENROUTER_API_KEY="$OPENROUTER_API_KEY" \ -e REFLECT_LICENSE="$REFLECT_LICENSE" \ -e ROLE=security-analyst reflection-playbooks # or on the code under triage, on your own machine: redmirror-reflect init claude # or cursor, codex, pi, ...
It runs locally and the kernel uses no tokens, which matters when the report is against someone else's codebase. Where this sits in the workflow: security triage spans the whole AI-native SDLC, and Reflection is the step that turns a "possible" into a proof. See the reference on proving a vulnerability is exploitable.
It turns a suspected report into a confirm-or-refute with a reproduction. You state the security rule the code must keep and the kernel searches every reachable state; if a non-privileged caller can reach the privileged action, it returns the exact call that does it. Your triage outcome is a kernel-verified attack path, not a judgement call.
That a non-administrator can change another user's account status. In a user-admin module, suspendUser checks the caller's role but its sibling banUser does not. The kernel refuted the rule that any status change must be preceded by an authorization check, with the path: banUser reaches a 'banned' status with auth_checked still false. Concretely, mallory (role user) bans alice. That is missing authorization, CWE-862 / CWE-863.
Because the kernel decides, and it rejects sloppy claims. In this run the model's first claim used undeclared fields; the kernel returned REVISE — 'an undeclared identifier reads as 0, which can fake a proof' — and refused to ground it until the claim was corrected. A finding is grounded only when a faithful claim is refuted by the kernel's exhaustive search.
No. RedMirror Reflection runs as a single binary on your own machine and the kernel search uses no tokens. You point it at your own model, local or hosted, and the code under triage stays with you — which matters when the report is against a customer's or a partner's codebase.
Triage with a reproduction, not an opinion. Install the binary, point it at the code under review and your own model, and forward confirmations that carry a kernel-verified attack path. First month free, then $4.99/month, cancel any time.