Appearance
Risk Agent PREVIEW
The Risk Agent produces a defensible first-pass quantification for a risk threat: a monetary expected loss, the reasoning that produced it, and a reference trail back to the controls, evidence, and data it relied on. The output is a draft for human review, not a final number.
Preview
The Risk Agent is in preview. Outputs are intended to accelerate a human-authored quantification; review the reasoning before relying on the value, and keep using scenario analysis or Monte Carlo when you need stronger statistical grounding.
What this is
A run on a threat produces:
- a proposed monetary expected loss (a single point estimate, not a range)
- structured references — the frameworks, requirements, controls, evidence, tests, and external sources the agent drew on
- the reasoning trace of each role that contributed, which lays out the assessed mitigation factor, the formula, and every variable and value used in the calculation
The run is captured as a risk_agent_fermi quantification alongside the other methods: visible in the Quantification History table, the Risk Value Over Time chart, and the run drawer.
What a Fermi estimate is
The method is named for Enrico Fermi's estimation style: decompose a number nobody knows into factors somebody can defend. Nobody knows your annual loss from a backdoor attack. But your platform knows how many systems you run, your controls say what defenses exist, and published industry studies price a typical incident. Multiply defensible factors and you get an order-of-magnitude estimate with every assumption exposed.
The piano tuners of Chicago
Fermi's classic classroom question: how many piano tuners work in Chicago? Nobody knows, but the number can be built. Chicago has about 3 million households. Assume one in twenty owns a piano, a piano is tuned about once a year, and a tuner completes about 1,000 tunings a year. That gives 3,000,000 × 1/20 ÷ 1,000 ≈ 150 tuners. Each assumption is guessable to within a factor of a few, the errors partly cancel, and anyone who disagrees can attack a specific number instead of the conclusion. The Risk Agent's estimate has the same property: every factor is stated, so a wrong number starts a productive argument instead of ending one.
This is the same discipline as the manual Fermi decomposition the quantification guide recommends. The Risk Agent automates the decomposition and shows its work.
Fermi estimate
An example decomposition: every term traces to its agent.
Structural anchors
Users, transactions, revenue: platform and connected-source data, not model guesses
Investigator + Scout
×
Benchmark assumptions
Industry figures, cited by source
Quantifier
×
( 1 − mitigation factor )
0.0–1.0, from controls verified against evidence and tests
Auditor
=
Residual expected loss
A single monetary point estimate
Quantified value
The supervisor designs the decomposition per run, keeping the prior structure when nothing material changed. This is an example shape, not a fixed platform formula.
The value is order-of-magnitude useful for prioritisation. It is not a substitute for incident-data-backed modelling, and the agent presents it with the assumptions attached so they can be challenged.
How the agent works
The Risk Agent is a team of specialised AI agents, not a single model call. A supervisor orchestrates the run from start to finish, and each stage emits one artifact the next stage depends on.
Risk agent
One run, one gate, no invented numbers.
Supervisor
Frame the run
Threat context, prior runs (up to 5)
▼
Investigator (+ Scout)
Investigate
Platform data; external sources via Scout when needed · emits structural anchors
▼
Supervisor · Go / No-Go
Sufficient structural anchors?
No
Run ends
Unquantified
No number invented; zero recorded, excluded from charts
Yes
▼
Auditor
Audit the defenses
Controls verified against evidence and tests · emits mitigation factor 0.0–1.0
▼
Supervisor
Design the Fermi formula
For this threat; structure kept when nothing material changed
▼
Quantifier
Execute the formula
Example: anchors × benchmarks × (1 − mitigation) · emits the monetary estimate
▼
Run ends
Quantified
Becomes the threat's current value
A run that errors ends as Failed, with the reason shown on the run. Only Quantified runs contribute to charts and rollups.
Supervisor: frames, gates, designs
The supervisor owns the run. It reviews the threat context (the threat and risk descriptions, your project, your organization), optionally checks up to five prior runs on the same threat, and decides what the estimate needs. After investigation it makes the Go/No-Go decision: without sufficient structural anchors to ground the estimate, it stops the run as Unquantified rather than produce a number from nothing. If the run proceeds, the supervisor designs the Fermi formula for this specific threat and hands it to the quantifier. The platform does not apply a fixed equation; when a prior quantified run exists and nothing material changed, the supervisor aims to keep the same formula structure so values stay comparable.
Investigator: finds the anchors
The investigator searches your platform data (frameworks, requirements, controls, evidence) for structural anchors: real figures such as active users, transaction volume, or revenue that can ground the impact estimate. It works under a strict rule: anchors come from data, never from guesses. When platform data is not enough, it delegates to Scout, which searches your connected external sources (GitHub, Azure, AWS, Langfuse, Vijil) and tags what it finds as external data.
Auditor: prices your defenses
The auditor determines the mitigation factor, a value between 0.0 and 1.0 expressing how much your controls reduce the gross impact. It maps the threat to semantically related controls, then verifies each one: a control marked as executed is not taken at face value without attached evidence, and tests weigh more than documents because they prove the control is maintained over time. Residual gaps (for example, encryption at rest but not in transit) lower the factor. Most realistic assessments land between 0.3 and 0.8.
Quantifier: does the math
The quantifier executes the supervisor's formula using the investigator's anchors and the auditor's mitigation factor. Variables that platform data cannot supply are filled with industry benchmarks from the model's knowledge, and each one must be cited by source in the output. The quantifier has no tools and no web access; if it cannot complete the calculation honestly, the run fails rather than pad the gaps.
Three ways a run can end
| Status | Meaning | Value |
|---|---|---|
| Quantified | The estimate completed and passed the supervisor's checks | The monetary estimate; becomes the threat's current value |
| Unquantified | The Go/No-Go gate stopped the run: not enough structural anchors | Recorded as zero; excluded from charts and rollups |
| Failed | The run hit an error; the failure reason is shown on the run | Recorded as zero; excluded from charts and rollups |
Only Quantified runs contribute to the Risk Value Over Time chart and to rollups. Rollups use each threat's latest run, and a risk contributes to project totals only while every threat's latest run is Quantified, so starting a recalculation can remove the risk from rollups until the new run completes.
Where in Modulos
You run the Risk Agent from the quantification wizard for a risk threat:
Project → Risks → select a risk → select a threat → Quantify → Select Method → Risk Agent
The Configure Parameters step takes no input for this method: the agent assembles its own context from the threat, the project, and your organization. Runs execute asynchronously and can take a few minutes for a complex threat; the page updates automatically when results are ready.
Reading the output
The result opens with the Quantified Value in the header and, when the agent produced one, an Executive Summary naming the most material driver. Below them, up to three expandable sections carry the full analysis; a section appears only when the run produced its content, so an Unquantified or Failed run shows fewer. Each maps to the stage that produced it, so the flow above is also a map of the report.
Analysis Breakdown
The run's status, methodology, and analysis date, with a written Estimation Justification: the formula the supervisor designed, the structural anchors found, the assessed mitigation factor, and how the value compares to prior runs.
References & Methodology
The Estimation Source describing how the inputs were combined, and the References: chips linking each framework, requirement, control, evidence item, test, or external source the agent relied on. References to platform entities are checked against your current data, so a reviewer can see when a cited item no longer exists.
AI Agent Reasoning
The reasoning trace, one subsection per role that contributed: Supervisor Reasoning (how the run was framed and why the evidence was sufficient), Investigator Findings (the anchors and where they came from), Auditor Findings (the mapped controls, their evidence, and the residual gaps), and Quantifier Math (the formula, the inputs, and the step-by-step calculation). These summaries are where the mitigation factor, variables, and benchmark citations live; a reviewer can trace every assumption in the headline value back to its source here.
What the agent will and won't do
- It won't invent anchors. Structural figures come from your platform data or connected sources. No anchors means no number: the run ends Unquantified.
- It won't produce ranges. The output is a single point estimate with its assumptions exposed. For distributions and confidence bounds, use Monte Carlo.
- It cites its benchmarks. Industry figures used to fill gaps are named by source in the output, so a reviewer can judge whether the analogy holds for your business.
- It doesn't trust unverified controls. A control without evidence or tests contributes less mitigation than one that is proven to run.
- There is no approval gate. A Quantified result immediately becomes the threat's current value and feeds rollups; nothing waits for a human to accept it. The output itself is read-only: review it, and supersede it by re-running with Recalculate or quantifying with another method. The human reviewer stays accountable for what gets used and reported.
Re-running and stability
Each run creates a new entry in the Quantification History with its own value and reasoning, exactly as a Monte Carlo or scenario run does. Past runs are never overwritten.
The supervisor can read up to five prior runs before starting. When your anchors and controls are materially unchanged since the last quantified run, it aims to keep the same formula structure and benchmark assumptions, so the value stays stable instead of drifting between runs; this is agent judgment, not a deterministic guarantee. When something real changed (new evidence, added controls, a different threat description), the estimate moves with it. Use the Risk Value Over Time chart to compare runs.
Who can do what
Permissions — can run the agent and save runs
- Organization Admin, Risk Manager, or Policy Manager — these organization-level roles have full access to every project in the organization.
- Project Owner on the project.
Permissions — can read saved runs
All of the above, plus Project Editor, Project Reviewer, and Project Auditor on the project. These project roles can walk through Quantification History and the Risk Value Over Time chart but cannot start a new run.
Related pages
Risk Quantification
Conceptual model, workflow, and guardrails
Quantification Methods
Reference for all quantification methods, including the Risk Agent
AI Agents Overview
Where the Risk Agent fits alongside Scout, Evidence Agent, and Control Assessment Agent
Human in the Loop
How AI agent outputs are reviewed and accepted in Modulos