Repository navigation
Priority Board
📖 Canonical version: read this page on the official docs site — https://www.redamon.org/docs/priority-board. The GitHub wiki is a mirror.
A finished scan hands you hundreds of findings and no order to work them in. A malicious dependency sits in the same flat list as a missing DMARC record. The Priority Board scores every finding out of 100 (how likely it is to be real, how likely it is to be exploited, how bad that would be, and how reachable it is) and puts it in one of four tiers: Act now, Act soon, Plan, Track. Mute then lets you take a finding out of the picture entirely once you have decided it is not worth looking at.
The two halves are deliberately separate. The ranking is computed for you. Muting is a decision by you.
The ranking is done in code, not by an AI guessing. A model is used at one step, and only to check the findings that already rose to the top against their own evidence. Set the review budget to 0 and run it with no model at all, and you still get a correct, complete ranking.
- The mental model (read this first)
- What a triage run actually does
- How the ranking works
- What the AI actually does
- What "muted" actually means
- Where to find it
- Reading the board
- Running the Priority Board
- Triage from an external agent (MCP)
- Safety properties worth knowing
- Scans and versions
- FAQ
- See also
-
A rank orders a finding. It never hides one. Every finding gets a 0-100 score, the four factors behind it, the facts each factor came from, and (for the ones the AI reviewed) a verdict and the exact evidence it quoted. Everything stays visible.
-
Muting is the only thing that hides. It is a human action, one click plus a confirm, and always reversible.
-
A muted finding is invisible to the AI agent. Not de-prioritised, not filtered in the UI: genuinely unreachable. No question you can ask the agent will surface it.
-
Nobody writes a score. A finding's score has three stored layers: the rules, a review (the built-in AI's, or an external agent's), and your own decision. RedAmon computes the final score from them; the higher layer wins.
The third point is the one worth internalising, and the "What muted actually means" section explains why it is stronger than it sounds.
One run, in this order. Everything up to the publish happens in memory; the publish is the only step that writes findings. (Scoring does refresh the shared CVE intelligence cache, which is not project data.)
| Step | What happens | AI? |
|---|---|---|
| 1. Score | Every open finding is read out of the graph with the project's facts (which hosts are live, which ports an active scan found, which packages are actually served, what the agent proved) and scored 0-100. This is the rules layer. | No |
| 2. Read what is already decided | The reviews and your decisions already on each finding. A review whose evidence has not changed is kept, not paid for again. | No |
| 3. Group | Findings that share one fix become one group: the same CVE on three hosts, or every advisory on one package. | No |
| 4. Review | Findings with no still-valid review whose evidence can be judged are sent to the model in batches, with the request, the response, the file path and the validation result. It corrects the factors; it never produces a score. | Yes |
| 5. Combine | Rules, review and your decision become the final score. The groups are then scored again from the result, so a false positive found in this run no longer lifts its group. | No |
| 6. Fix items | One remediation per group, in the board's order, written into CypherFix. | Partly |
| 7. Publish | The result is written in batches. Your decisions and any review an agent wrote while the run worked are read again at this moment, so they win. | No |
Because nothing about a finding is written before step 7, a run you Stop or one that is refused leaves the previous ranking exactly as it was. Once the run is publishing, Stop is refused: the publish takes moments, and stopping halfway would leave the board half new and the fix list old.
A real run on a 536-finding project, for scale: scored in about a second, 97 groups, 150 findings reviewed in 13 model calls, the whole thing in 9 minutes, producing 88 fix items. The next run over the same evidence reviews only what changed.
What the AI is not allowed to do: it never sets a score, never mutes anything, never overrules your decision, never replaces a still-valid review an external agent wrote, and never talks down a finding something proved. It has no tools bound at all, so an instruction hidden in scanner output has nothing to reach for.
For every open finding, RedAmon estimates four things, each between 0 and 1:
| Factor | The question it answers | Where it comes from |
|---|---|---|
| Real | How likely is this finding to be true? | How it was detected: an exploit that ran, a matcher that captured proof, a version guess from a banner |
| Exploit | If it is real, how likely is it to be exploited? | The strongest signal available: CISA KEV, EPSS, a public proof of concept, a usable credential, the CVSS exploitability metrics |
| Impact | How bad would that be? | The CVSS impact metrics, else the severity, else what kind of thing it is |
| Reach | How does an attacker get to it? | A live endpoint, an open port an active scan found, a package actually served, a login wall, a local-only vector |
Those four are multiplied, not added:
risk = real x exploit x impact x reach
score = 25 x tier + 25 x risk -> 0 to 100
Multiplying is the whole point. Risk is likelihood times impact, so something harmless can never outrank something devastating just by being easy, and a finding nobody can reach cannot outrank one sitting on the open internet.
The score is not a band applied afterwards. Fixed rules put each finding in a tier from its facts, and the tier is built INTO the score, so a bigger number always means more urgent:
| Tier | What it means | Rule |
|---|---|---|
| Act now | Proven, or known-exploited and reachable | Something demonstrated it; or it is in CISA KEV, confidently detected and reachable; or it is a credential that was tested and works |
| Act soon | Likely real, likely exploited, real impact, reachable | All four factors above their thresholds |
| Plan | Credible, with impact worth scheduling | Plausibly real, with some impact |
| Track | Everything else | Real facts, but not where your time goes |
On a row, the score reads as a sentence:
real 95% · exploit 70% · impact 0.75 · reach 1.0. Every one of those numbers
names the fact it came from, so you can disagree with a specific input rather
than with the conclusion.
A finding that is fixed, gone or inactive leaves the ranking altogether rather than being demoted to a small number that still sorts above something real:
| State | What it means |
|---|---|
| Fixed | The scanner confirmed it is patched, or a completed scan no longer reports it |
| Gone | The host has no live endpoint and no open port left |
| Inactive | A credential that was tested and does not work |
They keep all their facts and come back to the ranked list if a later scan finds them again.
The board is always in the same four sections: Ranked, Not triaged yet, Likely false positive and Resolved. Each is described, with every column and every value, under Reading the board.
RedAmon reads its own agent's results back out of the graph: the exploit modules GVM executed, the attack-chain outcomes the agent recorded, validated credentials, and malicious packages OSV confirmed. A proven finding is always Act now, and the AI cannot talk it down.
Every finding stores three layers, each with who wrote it, how and when:
| Layer | Who writes it | How long it lasts |
|---|---|---|
| Rules | Every triage run, from the facts in the graph | Until the next run |
| Review | The built-in AI during a run, or an external agent over MCP. Every correction quotes the evidence | Until the evidence changes, or a newer review replaces it |
| Decision | You: Real or False positive (in the board, or an agent using your token over MCP) | Until a person changes it |
The final score is computed from them, and nobody writes it directly. The rules
are the base; a review that still describes the evidence corrects its factors; your
decision wins over both. Real sets the finding's real factor to 100%, so it
rises. False positive moves it to the third section at once. Each decision
rescores its finding immediately; group scores and the fix list follow at the next
run.
A review's evidence is the same capped, secret-redacted text the model is shown:
for a nuclei finding, the matcher, the request it sent and the response it got;
for a GVM finding, the port and the solution type too. Keys, tokens,
Authorization values, every cookie value and any header whose name marks a
credential (X-Api-Key, X-Session, ...) are masked to their first four
characters, because nuclei replays your own session in its requests. Volatile
headers (Date, ETag, Set-Cookie, request ids) are dropped before it is
fingerprinted, so a rescan that only moves the time keeps the review, and a rescan
that changes what the target said makes it out of date: it stays on the finding,
marked so, and stops counting.
A detector that is right everywhere is still wrong on somebody's estate. The GitHub secret hunt flags private IP addresses as secrets, which on a network full of internal ranges is a hundred rows of pure noise, all of them scoring exactly what they would score anywhere else. Muting them worked, and then the next scan brought them back.
So every Real / False positive click is counted against the detector that produced the finding, and the Real factor for that detector moves towards what you actually found:
| What you have told it | What happens to Real for that detector |
|---|---|
| Nothing yet | The detection rule alone decides, exactly as before |
| One or two clicks | Almost nothing. A single unlucky click cannot re-rank your board |
| Ten clicks | About halfway between the rule and your verdicts |
| Thirty clicks, all noise | Near the bottom, but never off |
The detector is the rule that fired, not the finding: a nuclei template, a
TruffleHog detector, a GVM test. So marking one tech-detect row false teaches
it about the next tech-detect row and about nothing else. Advisories are the
exception and deliberately learn per source rather than per CVE, because a
verdict on one CVE says nothing about another.
Four things it will not do:
- It only learns from you, in the app. A verdict an agent records with your token over MCP does not teach your detectors, and neither do the decisions that came with an imported project.
- It never crosses users. Your clicks change your board. They are never pooled with anyone else's, on any plan.
- It never silences a detector. Real is floored at 0.1. A detector you can no longer see is one you can never discover was right after all.
- It never talks down a proven finding. An exploit ran. That is the same rule the AI review obeys.
-
It never hides why. Hover the factor line and it tells you:
real 34%; detected by github_hunt; you judged 2 of 30 of these real.
It does not produce a score, a severity or a priority. Those come from the rules above.
Its job is the one thing rules cannot do: read the evidence a scanner captured (the request and the response, the file path, the validation result) and say whether the four factors match it. A nuclei "exposed .env" whose stored response is the site's own homepage is a false positive, and nothing about the graph's shape reveals that. The response body does.
Everything it says is checked in code before it counts:
- Every quote must really appear in the evidence it was sent. A correction it cannot point at becomes "no change". This is the main defence against an invented reason.
- Saying nothing costs nothing. "Unclear" with no disputes changes nothing at all, so an unsure model is never pushed towards a guess.
- It can only correct named things. A verdict, an impact multiplier between 0.5 and 1.5, and one of eight named facts it can dispute. Nothing else.
- A multiplier needs its own quote. Without a quote showing why the impact is worse or milder, the multiplier is ignored, so no correction moves a score unquoted.
- The rules decide the outcome. After its corrections, the tier and the score are recomputed by the same rules as before, so it can never move a finding somewhere the facts do not support.
- A proven finding cannot be talked down. Proof came from an exploit that ran; a sentence in a response body does not outweigh it.
- Your own decisions are never touched, and a finding you decided is never sent for review.
- Its review lasts until the evidence changes. The next run keeps it rather than asking again, even a run with no model at all. Switch the Triage review model, or ship a new review prompt, and it reviews its own reviews again, once. It never reviews over a still-valid review an external agent wrote.
Findings it cannot usefully judge never reach it at all: a missing security header is a fact, and a dependency advisory's evidence is the advisory text rather than anything about your target. On a real project that is most of the graph, which is where the cost would otherwise go.
When you mute a finding, RedAmon adds a marker to that node in the graph. From that moment:
| Where | What you see |
|---|---|
| The graph view | Gone |
| The AI agent | Gone, and it cannot be asked about |
| RedZone panels | Gone |
| Insights & analytics | Gone, including the node counts |
| Reports | Gone |
| Recon Delta | Not reported as "resolved" (see below) |
| Muted Nodes (All Nodes menu) | Visible: the only place it still is |
The agent side is enforced at the single point every graph query the AI writes must pass through, the same place that stops one project reading another project's data. Every query the model emits gets the exclusion added automatically, whatever shape it is written in: labelled, unlabelled, or a bare "give me everything". The agent also has no vocabulary for mute at all: a query that even names the marker is refused outright rather than answered. So there is no phrasing, and no prompt, that gets a muted finding back out.
A finding is muted in one of four ways, and the difference matters:
- By a person, with the Mute button on this board. That is a judgement of that one finding.
- By a person in bulk, with Multi mute: the person confirmed it, but chose it together with others from AI suggestions of findings like one they were muting, so it is not a judgement of each one.
- By a mute rule, from Mute Rules, for example "every informational nuclei template". That is a policy over a whole class of findings, not a judgement of any one of them. Such a mute is marked with the rule that applied it, and disabling the rule and applying again brings those findings back.
- By an external agent over the MCP server, with one of your access tokens and a permission you ticked. It is marked as the agent's.
All of them hide the finding in exactly the same places. Muted Nodes lists them all and says which is which, and the client report counts them on separate rows.
Why a mute is not reported as "fixed". Recon Delta compares two scans and lists what disappeared. A finding you muted disappeared without being fixed, so it is excluded from both sides of the comparison rather than being counted as resolved. Muting never makes your remediation numbers look better than they are.
The Priority Board tab sits on the Red Zone, next to Recon Delta and Scans. It lives with the graph it ranks, rather than as a separate page.
Its order and CypherFix's fix list are produced by the same run, so the two never disagree. The board tells you what to deal with first; CypherFix turns each group on it into a fix item, and can open the pull request. One button on either page runs both.
The server decides which section a finding is in, so the board cannot disagree with the ranking.
| Section | What is in it |
|---|---|
| Ranked | Open findings the last run scored, most urgent first. This is the working list. |
| Not triaged yet | Found since the last run, or never triaged. They have no score yet. Run triage to rank them. |
| Likely false positive, check me | You, the built-in AI's review or an external agent's review judged these not real. They are not muted and not deleted, and one click puts one back. |
| Resolved | Fixed, gone, or a credential that no longer works. Kept, so they can come back if a scan finds them again. |
Above the table, one chip per tier (Act now, Act soon, Plan, Track) filters every section at once. Its count is the ranked findings in that tier: a finding with no score yet is not counted as Track.
| # | Column | What it holds |
|---|---|---|
| 1 | Node ID | The finding's graph id, pinned leftmost. Click to copy, then hand it to the agent or an MCP client. Not stable across rescans; see Node ID and Mute columns. |
| 2 | # | Rank within its section, so the first row of Ranked is 1. Not a stable id. |
| 3 | Finding | Its name, or its id when it has no name. A from <date> tag appears here when the row was scored by an older run than the newest one on the board, which is how you spot a finding a scan added after the last triage. |
| 4 | Type | The node label: Vulnerability, Secret, GithubSecret, GithubSensitiveFile, MultiscannerFinding, JsReconFinding, MalPackageFinding, ExploitGvm. |
| 5 | Score | The 0-100 number, its tier chip, the four factors underneath, and the rules-only score when a review or a decision moved it. Detailed below. |
| 6 | Decided by | Your decision, the review and who wrote it, or Rules only. Detailed below. |
| 7 | Signals | The named facts behind the factors, as chips. - when none applied. |
| 8 | Where | The host the model actually scored against. Falls back to the finding's location, then -. |
| 9 | Why | Your reason when you decided it, else the review's one-sentence reason, plus a fix lever chip naming what would resolve it. - when there is none. |
| 10 | (actions) | Real, False, Reset (on a finding you decided), Mute, Multi. |
A cell reads like this:
62.5 [Act soon]
real 95% · exploit 70% · impact 0.75 · reach 1.00
When a review or your decision moved it, a muted second line shows the rules-only
score and the difference, for example rules 30.1 · Plan +32.4, and the factors
the review or decision changed are highlighted. Hover the line and it names the
layer that moved it.
Where the number comes from. The four factors are multiplied, and the tier is added on top:
risk = real × exploit × impact × reach each 0 to 1, so risk is 0 to 1
score = 25 × tier_level + 25 × risk T1=3 T2=2 T3=1 T4=0
Worked through for the cell above: 0.95 × 0.70 × 0.75 × 1.00 = 0.50 risk, and
the tier is Act soon (level 2), so 25 × 2 + 25 × 0.50 = 62.5.
That gives each tier its own 25-point band (Track 0-25, Plan 25-50, Act soon 50-75, Act now 75-100), with the position inside the band set by the risk. So a bigger number is always more urgent, and sorting by it is exactly "tier first, then risk". One decimal is shown.
The multiplication is the part that matters: risk is likelihood times impact, so something harmless can never outrank something devastating just by being easy to exploit, and a finding nobody can reach cannot outrank one on the open internet. If any one factor is near zero, the score is near the bottom of its tier whatever the other three say.
-
The tier chip is one of four. Hover it and it names the rule that put the finding there, not a threshold:
Chip Tier The rule that assigns it Act now T1 proven·KEV-listed, confidently detected and reachable·a validated credentialAct soon T2 likely real, likely exploited, real impact, reachablePlan T3 credible, with impact worth planning forTrack T4 nothing here has any impact·no rule placed this higher -
The factor line is the four probabilities that were multiplied together. Hover it and each one names the fact it came from, for example
real: detected by github_hunt; you judged 2 of 30 of these real.Factor Shown as Means real a percentage How likely the finding is to be true, from how it was detected and from your own Real / False positive clicks on that detector exploit a percentage How likely it is to be exploited if it is real: the single strongest signal, never a sum impact 0.00 to 1.00 How bad it would be: the CVSS impact metrics, else the severity, else its class reach 0.00 to 1.00 How an attacker gets to it A row with no factors stored shows math only here instead, which is explained next.
A finding is in one of three states, and the Score cell tells you which.
| What you see | What it means | What produced it |
|---|---|---|
- |
No score at all. Triage has never scored this finding. | Nothing. There is no number to calculate yet |
34.4 + tier + factor line |
Fully scored by the current model | The last triage run, score model v3 |
540.0 + tier + math only |
A leftover from the old scorer. It has a number but no breakdown | A run from before score model v3 |
This is worth being plain about: nothing computes a score in the background.
A scan finds a finding and writes it to the graph, and that is all. Until you
press Rank Findings, the finding has no score, no tier and no factors. It
sits in Not triaged yet with a -.
There is no partial or provisional number. The board is ranked only by a run you asked for.
math only is not a kind of score. It is the board telling you the
breakdown is missing: this row has a number, but not the four factors that
should explain it.
That happens for one reason: the row was scored by the old points formula, which RedAmon replaced. The old scorer added points per signal and stored a bare number. It never stored the factors, the tier, or a model version.
Those numbers are on a completely different scale and are not comparable to
the new ones. In one real database, rows still carrying old scores ranged from
-100 to 640, with dozens above 100, while every v3 score is between 0 and
100. A 540 next to a 34.4 does not mean it is fifteen times more urgent; it
means the two were produced by two different systems.
Because the old rows carry no stored tier either, the chip beside them is a rough guess the interface makes from the number alone, not the rule-based tier the current model assigns.
Re-run triage and they are replaced. One run rewrites every finding in the
project with a v3 score, a rule-assigned tier and the full factor line. math only is a sign the project is overdue a run, and nothing more.
Two numbers are stored per finding:
| Stored as | What it is |
|---|---|
triage_math_score |
The score from the rules alone, from the facts in the graph |
triage_priority_score |
The final score, after a still-valid review and your decision. This is what the board shows and sorts by |
They are identical for every finding no review or decision moved, which on a
typical project is most of them. When they differ, a review disputed a factor
against the evidence, or you decided the finding, and the same rules were
re-run on the corrected factors. Nobody edits a score directly: a review can only
move real, exploit, impact or reach, and the arithmetic is redone from
those. triage_decided_by records which layer set the final one: rules,
review or person.
It shows up to two chips: your decision, and the review.
| Chip | Meaning |
|---|---|
| You: Real | Your decision. The finding's real factor is 100%, and no run or review changes it |
| You: False positive | Your decision. The row is in the third section, and it is not muted |
| You via MCP · rdmn_mcp_…: Real | Your decision, recorded by an agent using that access token of yours |
| AI: Real / Doubtful / False positive / Unclear | The built-in AI's review. Hover it to see the model. Unclear deliberately changes nothing |
| Agent: Doubtful (and the other verdicts) | An external agent's review over MCP. Hover it to see the token prefix |
| out of date | Beside a review chip: the evidence changed since the review was written, so it no longer counts |
| Rules only | No review or decision moved the score |
A finding you Reset shows no You: chip at all. Under the chips, when a review gave one, sits the exact quote it took from the evidence. Every quote is verified to be a real substring of what the reviewer was shown, so it cannot invent one.
| Chip | What it means |
|---|---|
| proven | Something demonstrated it: an exploit ran, a credential validated, or OSV lists the package as malicious |
| KEV | The CVE is in the CISA Known Exploited Vulnerabilities catalogue |
| EPSS 0.94 | The CVE's exploit-prediction score, 0 to 1 |
| public PoC | A public proof of concept exists |
| live endpoint | Its host answered an HTTP probe |
| hot host | The agent already compromised that host |
| sensitive asset | The host exposes a database port, a login, an admin vhost, MCP or GraphQL |
| origin exposed | It sits behind a CDN whose origin is reachable directly |
| CVSS v3 | A CVSS vector was parsed, and which version it was (v2, v3, v4) |
| a class name | What kind of thing it is: dependency, credential, generic secret, exposure, misconfig, hardening, info disclosure, cdn bypass, identifier, rate limit, spoofing
|
| Button | What it does |
|---|---|
| Real | Records your decision. The finding's real factor becomes 100% and it is rescored at once. No run or review changes it |
| False | Records it as a false positive. It moves to the third section at once. It is not muted and not deleted |
| Reset | Only on a finding you decided. Removes your decision: the finding is ranked from its rules and any review again. It also releases the protection a decision gives: a Mute Rule may then mute it, and a scan that stops reporting it removes it. A confirm names both |
| Mute | The only action that hides anything. Confirm required. See below |
| Multi | Mute in bulk: finds the other findings of the same kind you would mute for the same reason, and lets you mute them with this one. See Multi mute |
Every decision replaces its row in place with the rescored one; the board does not reload. Real and False positive also teach the board: each click is counted against the detector that produced the finding, and shifts the real factor for that detector on your future runs.
Click a row to open its detail panel: everything behind its place on the board.
| Section | What it shows |
|---|---|
| Result | The final score, tier, factors and which layer decided it |
| Rules | The rules-only score, the four factors with the fact each came from, the signals, the tier inputs (proven, KEV), and the detector line (you judged 2 of 30 of these real) |
| Review | The review's verdict, who wrote it (the model, or the agent's token prefix), whether it still describes the evidence, its corrections and its reason |
| Decision | Real, False positive and Reset, with an optional reason that is recorded with it |
| Evidence | The evidence a reviewer reads, loaded when you open it, shown as untrusted text. It notes when the finding's reviews do not survive a rescan |
| Group | The other findings the same fix resolves |
A finding that has never been scored says Not triaged yet, and you can still decide it. One scored before this breakdown existed shows its score and says the breakdown comes with the next run. If the finding is gone (a rescan replaced it), the panel says so and the row drops from the board. On a narrow screen the panel opens as a full-width sheet.
The Decided by menu filters the board by the layer that set the final score (you, a review, the rules), by who reviewed it (the built-in AI, an external agent, nobody) and by whether that review is current or out of date. Each option shows its count over the whole project, and picking one asks the server again, so the list and its total are exact even on a project larger than the board shows at once.
The board's Mute is not the only one. The same button sits in the Node Drawer and as the rightmost column of every node table (All Nodes, Node Inspector, JS Recon and the Red Zone tables); see Node ID and Mute columns. It asks for the same confirmation and does the same thing, so a finding muted anywhere shows up in Muted Nodes. Multi sits next to it everywhere, the board included; see Multi mute.
The board no longer lists muted findings. They live in Muted Nodes, in the All Nodes menu, which pages them, filters them by kind, by who muted them and by rule, and unmutes them one at a time or in bulk. After you mute a finding here, the confirmation offers View muted to jump straight there.
The move is deliberate: a mute rule can mute thousands of findings at once, and the board used to load every muted row on each visit.
One button, on the Priority Board and on CypherFix, runs one job. Its results become the board's order and the CypherFix fix list, so the two always agree.
Before it starts, a dialog tells you what this run will do with your project's own numbers in it: how many findings are in scope and how many are new, when the last run was and with which model, the review budget it will actually use, how many reviews are still valid and will be kept (and how many of those an external agent wrote), roughly how many AI calls it will cost, how many fix items are pending and how many someone is already working on.
The steps are the ones in What a triage run actually does. Nothing about a finding is written until the publish. Until then, the previous ranking is still what you see, so a run you stop, or one that is refused, has changed nothing at all. Once it is publishing, Stop is refused and the run finishes in moments.
The run is a background job: it outlives the tab that started it. Leave the page mid-run and it keeps going; come back and it re-attaches, on the Priority Board or on the CypherFix page. Every open tab follows the same run, so both pages side by side see its progress and its end. A run started by an external agent shows a Started over MCP · rdmn_mcp_… banner; a tab that was already open when the agent started it shows it after a reload. Only Stop cancels it, and only one run per project at a time. A new run started right after a Stop may be told the previous run is still finishing: retry a minute later.
While it runs, version activation, project import and project delete wait for it. Scans do not: they can keep running, and any finding a scan changes mid-run is left for the next run rather than being published with facts that have since moved.
The project owner's Triage review model, on the owner's own keys. It belongs to the account, not the project: it is set once in Global Settings → LLM Providers → Models by feature, or in Project Settings → CypherFix Settings, where the same picker is marked Applies to all your projects. It never falls back to the agent's model.
Priority Board: findings the AI reviews caps what a run costs (at most 1,000, whatever is stored), and decides whether a model is needed at all:
- Above 0, a run needs the model. If there is none, pressing the run button asks for one first, then the dialog names the model that will review.
- At 0, no model is needed: the board is fully ranked, with no AI review, and the fix items get their standard wording. If a model is set anyway, it still words the fix items.
A review lasts while its evidence is unchanged, so the next run keeps it and it costs nothing, even a run with no model at all. Switch the Triage review model and the next run reviews the built-in AI's reviews again, once. A run never reviews over a still-valid review an external agent wrote.
Press Real or False positive on a finding and that decision is yours. Later runs never overwrite it, no review overrides it, and Real raises the score.
What runs do keep updating are the facts and the four rules factors, because those are measurements. A finding you judged last month should not still be ranked on last month's graph: if the host has since gone away, or a CVE it carries has since entered CISA KEV, you want to know. Your decision about whether it is real stays exactly as you left it.
A decision you made in the app cannot be changed or reset over MCP, even by an agent holding your token. A decision an agent recorded over MCP can be changed by you, or by an agent, and Reset removes either.
Mute, the one action that hides something, always survives a re-run.
An agent connected to the MCP server with one of your access tokens can work the Priority Board with you, within the permissions you ticked:
| It can | With | What bounds it |
|---|---|---|
| See why a finding ranks where it does, and read its evidence | triage:read |
The evidence is secret-redacted; review text comes back only when asked |
| Review a finding: correct its factors with quotes from the evidence | triage:review |
Every quote is checked; RedAmon recomputes the score; the review is labelled Agent on the board, expires when the evidence changes, and never overrides your decision. It is refused on a finding you decided, and on a proven finding when it would lower anything |
| Record, change or reset its own decisions | triage:write |
Never one you made in the app. It does not teach your detectors |
| Start or stop a run |
triage:run (opt-in) |
At most one start per 30 minutes per project and 12 a day, at most 1,000 reviews per run. It cannot stop a run that is publishing; its stop shows in every tab that has the board open |
Its reviews and verdicts are written during a run just as safely as yours: the run re-reads them when it publishes. Filter the board by Decided by → Agent review to see everything agents have reviewed, and open a row to see which token. Text an agent writes (its reason, its fix lever) never reaches the CypherFix fix list, so it never reaches the CodeFix agent; and an agent's False positive keeps its finding in the fix group, so an external review can never quietly remove a fix item.
Reviews live on the finding. TruffleHog findings and GVM exploits are recreated at every scan of their source, so their reviews go with them; a finding the scanner stops reporting and nobody decided is removed with its review.
These are enforced in code, not by asking the model nicely:
- A run cannot mute anything. There is no code path from a triage run to the mute label, and there never must be. Scanner output (response bodies, evidence strings, matched URLs) is attacker-influenced text, and the worst it can achieve is a visible, reversible verdict on the finding whose own evidence carried it.
- The AI has no tools. The review and the fix-item calls bind none, so an injected instruction has nothing to reach for. It cannot query the graph, search the web, reach another project, or write anything but the handful of validated fields listed above.
- A failed run leaves findings visible. If the model is unreachable, the ranking still publishes and the findings keep whatever review they had; one with none is marked "Not reviewed". The system fails towards showing you too much, never towards hiding something.
- Nobody writes a score, including an external agent. A review corrects factors with quotes; RedAmon computes the score.
- A review expires when the evidence changes, or when the scanner recreates the finding.
- Decisions and reviews written during a run are honoured. The run re-reads them when it publishes.
- A stopped run changes nothing, and a Stop never half-publishes. Everything happens in memory until the publish, and a Stop is refused once the publish has begun. A batch that fails to publish marks the run as partially completed rather than claiming a board it only half wrote.
- A scan during a run cannot corrupt it. Any finding a scan changes while a run is working is skipped at publish time and picked up by the next run, rather than being written with facts that have since moved.
- A decision is refused during a version switch. A switch replaces the live graph, so a decision or review arriving mid-switch is refused (or, if the switch began while it was being saved, reported as needing a re-check) rather than silently lost.
- Only findings can be muted. Hosts, ports, domains, endpoints and certificates cannot: muting an IP would orphan the real findings attached to it.
- Mute survives a re-scan, and so does everything else you decided. A scan no longer deletes its findings and re-creates them: it refreshes the ones it still reports and removes the ones it does not. A finding you muted or judged is never removed, even when the scanner stops reporting it: it moves to Resolved and says so. A finding you Reset is no longer your decision, so it is removed like any other. A finding a mute rule muted is not your decision about it, so it is removed like any other finding its scanner stopped reporting. You do not re-mute the same noise after every scan, and a fix item never ends up pointing at a finding that no longer exists.
- Unmute is lossless. Restoring gives you the finding back with every relationship and property intact.
- Only the project owner can mute, or start a run. Enforced on every Priority Board endpoint, and re-checked when a run is authorised. Neither check can be relaxed by the log-only access mode that exists for other routes, because both change what the agent can see rather than what a page displays.
Everything triage produces (the score, the tier, the factors, the AI's verdict, your Real / False positive decisions and the mute) is stored on the graph nodes themselves, not in a separate table. So it is versioned exactly like the rest of the graph, and it travels with a project export and comes back on import.
A scan version is a frozen copy of the graph at one moment. Whether it contains a ranking depends only on when it was made:
- A version created or frozen after a triage run contains that run's scores.
- A version snapshotted before any run has no scores at all. Activate it and
its findings appear under Not triaged yet with a
-.
This surprises people, so it is worth stating plainly: you do not triage a version. You triage the live graph. Any version made afterwards inherits that result, because the result was part of the graph it photographed. One run can therefore show up in several versions without you ever re-running it.
Activating a version does three things in this order:
- Freezes the graph you are leaving into its own snapshot, so nothing is lost. If this fails, nothing is deleted and the switch is abandoned.
- Replaces the live graph with the chosen version's snapshot.
- Moves the pointer. The now-current version sheds its stored bytes, because it is the live graph.
Because of step 1, a round trip is lossless: switch away and back, and your ranking, your verdicts and your mutes are exactly as you left them.
A run in progress blocks activation. Triage reads the whole graph into memory and writes at the end, so switching underneath it would publish a ranking computed against a graph that no longer exists. Activation refuses while a run is live, and offers a Stop link.
CypherFix's fix items are project-level, stored outside the graph, and activation deliberately leaves them alone, along with reports, scan output and captured traffic.
So after switching to a version with a different ranking, the board and the fix list can disagree: the board is truthful for the version you are now on, while the fix list still reflects whichever run produced it. Nothing reconciles that at switch time. The next triage run recomputes each item against the live graph, which is what restores agreement.
In practice: after activating a different version, re-run triage if you intend to work from the fix list.
Does muting delete anything? No. The finding, its relationships and its history stay in the graph exactly as they were. Mute only changes who can see it.
Will the agent tell me a finding is muted? No. It cannot see muted findings and cannot query for them, so from the agent's point of view they do not exist. Look in Muted Nodes instead.
Why is a header-hygiene finding at the very bottom? Because a missing header is a real fact with almost no impact and almost no way to exploit it, and the score multiplies those together. It is in Track, which is exactly right: worth knowing, not worth today.
If I mute something, does it vanish from a report I already generated? Reports are generated on demand, so a report you produce after muting will exclude it. Already-exported files are unchanged.
Can I mute a whole class of noise at once? Yes, with Mute Rules: write a rule such as "nuclei findings with severity info" and apply it to the current graph, to every new scan, or both. A rule never mutes a finding you judged, confirmed or unmuted yourself.
What does Reset do? It removes your Real or False positive, so the finding is ranked from its rules and any review again. It also gives up what a decision protects: a Mute Rule may mute it, and a scan that stops reporting it removes it.
Can an agent change what I decided? Not a decision you made in the app. An agent with your token can review findings, and record, change or reset the decisions it made itself.
Do I need an AI key to use it? No. The ranking, the grouping and the fix items are all produced in code. A key adds the evidence review, which mainly catches false positives, and better wording on the fix items.
-
Mute Rules: mute whole classes of findings by rule
-
Muted Nodes: every muted finding, and where you unmute one
-
CypherFix: Automated Remediation: the run happens inside
-
Red Zone: where the Priority Board tab lives
-
Scan Timeline: versions, Recon Delta and scheduling