Mantis Calibrate

Risk Calibrator (/mantis_calibrate)

System Goal

Risk Analysis Expert. Evaluates confirmed findings against a rigorous risk matrix, taking into account successful reproduction and production viability to produce a final risk score (1-10).

Command Definition

• Command: /mantis_calibrate
• Description: Calibrates the risk level of findings based on evidence and

impact.

Instructions

Convert the raw security findings and their empirical results (repro/patch) into a prioritized, actionable risk report.

Execute the calibration as follows:

1. Load Full Pipeline State:

• Read all JSON files from the workspace/findings/ directory. Because

the pipeline appends data to each finding file at each stage, these files provide the complete picture of each finding's journey (including its id, reproduction status, and production viability).

• Read workspace/kb/THREAT_MODEL.md from the Knowledge Base (if it

exists) to evaluate component exposure, trust boundaries, and asset criticality.

• Batch Processing: If there are more than a few findings to

calibrate, split the task into batches (a few findings at a time). If you have the ability to invoke subagents, delegate each batch to a subagent to process in parallel, then aggregate the results.

1. Calculate Risk Score (1-10): For each unique finding file, calculate the

actual technical risk score in a matrix form based on the following formula components, where Hazard = Impact + Likelihood:

• Impact (1-5): Evaluate impact using the CIA triad (Confidentiality,

Integrity, Availability) while strictly considering Blast Radius.

• 5: Complete, systemic loss of Confidentiality (full data breach) or

Integrity (system compromise, e.g., clear Remote Code Execution (RCE) by an unprivileged attacker who isn't already in an effective position to execute code). MUST NOT be used for attackers who already have execution privileges.

• 4: Substantial loss in one or more areas. This includes systemic

Availability loss (total outage of a major service) or major data exposure.

• 3: Moderate loss (e.g., partial data exposure, temporary or partial

system disruption).

• 2: Minor loss (e.g., minor information leak, localized disruption).

A vulnerability whose blast radius is limited to affecting only a single user's own data MUST NOT be scored higher than 2. Exception: If the action lacks non-repudiation (allowing the user to plausibly deny the action to commit fraud or blame others), or triggers side-effects affecting other users/system stability, it should not be downgraded.

• 1: Negligible impact on CIA, mostly a cosmetic issue. Findings of

the type "the code is fragile", "lack of defense-in-depth", or purely theoretical hygiene issues MUST have an Impact score of 1, ensuring they are rated LOW at most.

• Note on Privileges Required & Lateral Movement:
• If the finding requires HIGH privileges (e.g.,

administrative privileges, admin-to-super-admin escalation) or only allows lateral movement/pivoting between internal components from an already compromised state, cap its individual Impact score at 2.

• If the finding requires LOW privileges (e.g., standard

authenticated user), cap its individual Impact score at 3 (unless it leads to systemic compromise of other tenants/users, in which case it can be higher).

• These caps apply to individual findings. If successfully

chained into an Exploit Chain (Super Finding) by the chainer, the chain itself should be evaluated based on the privilege level required for the entry point (initial step) of the chain.

• Likelihood (1-5): Evaluate the probability of occurrence based on

proven exploitability rather than theoretical difficulty.

• 5: Actively exploited in the wild, OR the agent successfully

generated a functional, weaponized exploit (not just a unit test).

• 4: Public Proof of Concept (PoC) exists, OR the agent generated a

highly plausible but partially weaponized exploit.

• 3: No functional exploit, but the attack vector is trivial to

automate.

• 2: Theoretical and highly complex (requires local access, strict

timing).

• 1: Strictly theoretical risk with no known exploit path.
• Context Multiplier (0.1 - 1.0):
• If status is FALSE POSITIVE or production_viability is

NON_VIABLE: Drop this finding completely. Do not score it or update its file with calibration data.

• If production_viability is VIABLE:
• Network/Trust Exposure:
• If the finding resides inside an **Exposed Interface / Trust

Boundary** (directly accessible to untrusted inputs): 1.0.

• If it resides in an Internal Component accepting

semi-trusted parsed data: 0.8.

• If deeply nested inside a Privileged/Trusted Zone: 0.5.
• Asset Criticality & Reachability:
• If the Threat Model indicates the component handles

high-value data (e.g., PII, core secrets), keep the multiplier high.

• If it affects a low-value target (e.g., internal analytics,

sandboxed test data), reduce the multiplier (e.g., 0.5).

• Availability-Specific Context: If the finding is

availability-only (DoS), check the component's availability_tier in the Threat Model:

• LOW_CRITICALITY: Reduce multiplier to 0.5.
• STANDARD: Reduce multiplier to 0.8.
• CRITICAL: Keep multiplier at 1.0.
• If static/dynamic analysis proves the vulnerable code is

effectively "dead code" (never called in runtime execution paths), drastically reduce the multiplier to 0.2.

• User Interaction:
• If user_interaction is REQUIRED (e.g., CSRF,

Clickjacking, or convincing a user to open a malicious file), apply a 0.7 multiplier to the Context Multiplier (e.g., if exposure is Internal (0.8) and user interaction is required, the combined multiplier is 0.8 * 0.7 = 0.56). This ensures these findings are capped below the CRITICAL threshold.

• If workspace/kb/THREAT_MODEL.md does not exist or does not

mention the components, default the Multiplier to 1.0.

• If production_viability is SAMPLEORTEST:
• Set the Context Multiplier to a reduced value (e.g. 0.4) so

that severe bugs in sample code typically land in the MEDIUM bucket rather than HIGH or CRITICAL.

• In the executive_summary, explicitly state that this is not a

production bug. The recommendation MUST focus on fixing the example/test so that developers do not copy insecure patterns into production code.

**Final Score (Hazard) = (Impact + Likelihood) Multiplier* (Capped at 10.0).

Note on Outrage: In your reasoning, comment on the broader equation Risk = Hazard + Outrage, where the "outrage risk" (e.g., reputational damage, user sentiment fallout) is taken into account. Do not include the outrage factor in the final numerical score.

1. Critical Sanity Triage (Downgrading Weak Findings): Before determining

the final priority, perform a second-level sanity check on the quality of the finding and its accumulated evidence. You MUST force-downgrade the finding's priority to LOW (and cap its final score at 2.0) if it meets any of the following "weak finding" criteria:

• Reproduction Failure: The reproduction failed (`repro_status:

"failedtoreproduce"`). If the agent cannot successfully reproduce the vulnerability, it MUST be force-downgraded regardless of any theoretical arguments for production viability.

• Minor Configuration Hygiene: The issue represents a minor deviation

from best-practice configuration (e.g., slightly loose permissions on an internal directory, lack of modern encryption on low-value internal transport) but does not lead to a clear exploit path, privilege escalation, or data exposure.

• Vague Code Paths / Fragile Assumptions: The finding's description or

reasoning relies on unverified assumptions about caller behavior or adjacent system components that are not documented in the active Knowledge Base.

• Unreliable/Noisy Triggers: The finding represents an issue that can

technically be triggered but is highly likely to be ignored in practice due to high noise, or is indistinguishable from normal system operations without causing real harm.

1. Determine Priority:

• CRITICAL (8.0 - 10.0): Immediate action required. Very high hazard

(e.g. high impact and likelihood). Must NOT be used unless it represents a clear RCE (or equivalent total loss) by an unprivileged attacker (where privileges_required is NONE) who is not already in an effective position to compromise the system, AND user_interaction is NONE (zero-click).

• HIGH (6.0 - 7.9): High priority. Significant hazard, needs prompt

resolution.

• MEDIUM (3.0 - 5.9): Standard priority. Moderate hazard, can be

scheduled.

• LOW (0.1 - 2.9): Low priority. Minimal hazard. **Any finding of the

type "the code is fragile", purely hygiene/defense-in-depth, or one that exclusively affects a single user's own data MUST be capped at LOW priority regardless of the calculated score (unless the exception for lack of non-repudiation or broader side-effects applies).**

1. Token-Optimized File Updates: To minimize LLM output tokens, **do not

re-emit or manually rewrite the entire JSON object in your output.** Instead, write a reusable helper script (e.g., workspace/helpers/append_calibrate.py) during your first finding update. For all subsequent findings, do not regenerate the script; simply execute the existing helper script with the new parameters to append the required fields to workspace/findings/.json.

Alongside the existing core finding data, explicitly append the following fields to show the matrix breakdown:

• "impact_score" (1-5)
• "likelihood_score" (1-5)
• "availability_tier" (CRITICAL, STANDARD, LOW_CRITICALITY or null)
• "mantis_risk_score" (the final Hazard score)
• "priority" (CRITICAL, HIGH, MEDIUM, LOW)
• "outrage_commentary" (your reasoning about the outrage factor)
• "executive_summary"

Save your updates to the individual finding files. When complete, notify the user.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: google
• Source: google/mantis
• License: Apache-2.0
• Homepage: https://cloud.google.com/

Install and usage instructions live in the source repository linked above.