FAST: Framework for Autonomous Severity and Triage

1.1. The Gap This Fills

Several standards adjacent to autonomous AI agents exist as of 2026, but none address the specific question this document does: when an autonomous agent finds a vulnerability, how should it classify severity, decide whether to report, and write the report?¶

• OWASP Top 10 for Agentic Applications [OWASP-AGENTIC-TOP10] covers vulnerabilities that exist INSIDE agents (goal hijack, tool misuse, memory poisoning). It does not describe how agents should classify vulnerabilities they DISCOVER in third-party targets.¶
• AVE (Agentic Vulnerability Enumeration) [AVE] classifies vulnerabilities in agent components such as MCP servers, skill files, and plugin boundaries. It does not address traditional web, application, or network vulnerabilities.¶
• AIVSS [AIVSS] scores risks TO agentic AI systems. It does not score bugs that agents DISCOVER in third-party targets.¶
• IETF drafts on agent identity and security requirements [IETF-AGENT-SEC] describe authentication and provisioning of agents, not their decision-making about discovered vulnerabilities.¶
• CVSS [CVSS] is a theoretical scoring framework agnostic to triager behaviour, program norms, and empirical payout patterns.¶

1.2. Applicability and Non-Goals

FAST is applicable to:¶

• Autonomous or semi-autonomous agents that discover vulnerabilities in third-party systems and submit reports.¶
• Autonomous or semi-autonomous agents that triage submitted reports.¶
• Human researchers who wish to align their reporting with a shared standard.¶
• Bug bounty platforms and in-house programs adopting a classification baseline.¶

FAST is NOT:¶

• A vulnerability scoring system in the CVSS sense. It classifies findings into ordered severity bands based on demonstrated access and evidence type; it does not produce a numeric score.¶
• A payout schedule. Programs set payouts. FAST classifies severity and reporting quality only.¶
• An authorisation to test. All authorisation derives from the program's scope and rules of engagement.¶
• A framework for classifying vulnerabilities in agents themselves. See [OWASP-AGENTIC-TOP10], [AVE], and [AIVSS] for that problem space.¶
• A finished, consensus-based standard. This document is a proposal and expects to evolve with community feedback.¶

1.3. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3.1. Source Data

The corpus consists of the full submitted-report history of an active security researcher across a diverse portfolio of bug bounty and vulnerability disclosure programs, spanning multiple years. The corpus includes reports at every outcome state:¶

• Reports paid at each severity level.¶
• Reports marked informational or not-applicable by the program.¶
• Reports resolved without payment on programs that do not offer bounties (typically vulnerability disclosure programs).¶
• Reports marked duplicate (excluded from analysis as they carry no severity signal beyond an earlier submission having existed).¶

For each report, the corpus contains:¶

• The submitted vulnerability description.¶
• The full timeline of triage activity, including severity change events, bounty-award actions, resolution actions, retest requests, and free-text comments from triagers and reporters.¶
• The program-assigned severity at each point in time, so that a final severity distinct from the submitted severity can be observed.¶

3.2. Two-Oracle Design

FAST is derived from two oracles built from the corpus.¶

The positive oracle consists of reports that a program accepted as a vulnerability at a given severity level. In this document, a program "accepting" a report means either paying a bounty or, on a non-paying program, marking it resolved with an assigned severity. Reports in the positive oracle define what a vulnerability at each severity level looks like in practice.¶

The negative oracle consists of reports the program rejected as not constituting a vulnerability. This includes reports marked informational, reports marked not-applicable, and reports otherwise closed without a vulnerability verdict. Reports in the negative oracle define what is NOT a vulnerability, and the boundary between positive and negative oracle defines the report gate specified in Section 5.¶

Duplicates carry no severity signal (they only indicate that another reporter submitted the same finding earlier) and are excluded from both oracles.¶

3.3. Feature Extraction Pipeline

For every report in the corpus, a deterministic extraction pipeline produces a structured record. The extraction is rule-based and does not depend on interpretive machine-learning judgement. The features extracted include:¶

• Vulnerability class (for example: remote code execution, SQL injection, server-side request forgery, account takeover, insecure direct object reference, PII disclosure, credential leak, misconfiguration, cross-site scripting, and related categories).¶
• Access type achieved by the exploit (for example: execute commands, read sensitive data, write data belonging to others, impersonate a user, achieve lateral movement).¶
• Data sensitivity accessed (for example: customer PII, internal employee data, credentials or secrets, source code, financial data).¶
• Scale of impact (single user, bounded set, all users, entire infrastructure, or no demonstrated access).¶
• Authentication requirement (unauthenticated, self-signup, victim-interaction required, existing account required).¶
• Interaction requirement (zero-click, one-click, multi-step).¶
• Proof type demonstrated (HTTP request/response artefact, reverse shell output, data-bearing screenshot, video PoC, chained PoC, or tool output only).¶
• Chain depth (single finding, two-step chain, three-or-more-step chain).¶
• Structural features of the written report (section ordering, section names present, presence of numeric or qualitatively unbounded blast-radius statements, use of language patterns identified as anti-patterns).¶
• Triager-side events extracted from the activity timeline (severity-change events, bounty-award actions, resolution actions, free-text triager comments with their acceptance, rejection, upgrade, and downgrade language patterns).¶

The extraction is written such that any comparable corpus can be processed the same way. It emits a structured record per report; the records collectively form the raw evidence base from which FAST is derived.¶

3.4. Empirical Rule Derivation

Rules are derived from the extracted records by four analyses.¶

Severity boundary analysis operates on the positive oracle. For each adjacent pair of severity levels (critical vs high, high vs medium, medium vs low), the analysis computes the differential distribution of every extracted feature. Features that appear disproportionately at the higher level define what distinguishes the higher level from the lower one. The severity tree in Section 6 is constructed to route findings to the level whose distinguishing features they exhibit.¶

Report-gate derivation operates on the boundary between the positive and negative oracles. The features whose presence correlates with payment (rather than rejection) become required elements of the report gate. The features whose absence correlates with rejection define the anti-patterns.¶

Chain-escalation analysis identifies records in the positive oracle where a base finding of one class was combined with proven access of a different type. The severity that the program actually awarded these combined findings drives the escalation table in Section 7. Base findings without proven chained access map to the severity that the base finding alone commanded, or to "not reportable" if the base finding is a lead.¶

Triager-language analysis operates on the free-text comments from the triager side of every activity timeline. Phrases corresponding to acceptance, rejection, upgrade, downgrade, and retest requests are catalogued. The observed frequency of upgrade language relative to downgrade and rejection language informs the rule in Section 6 that an agent MUST choose the lower level when uncertain: programs empirically upgrade well-evidenced reports far less often than they downgrade or close weakly-evidenced ones.¶

Writing-style extraction operates on the subset of the positive oracle consisting of reports paid at high or critical severity. It identifies section-ordering, section-naming, prose-tone, and proof-formatting patterns common to reports that reliably cleared triage. The report format in Section 8 is constructed from those patterns.¶

3.5. Observed Corpus-Level Signals

The following ratios and frequencies are drawn from the derivation corpus. They are anonymised, are not published as universal constants, and are provided as the empirical basis for specific rules in this document. Implementers applying FAST to their own corpus should expect the same directions of skew, though the magnitudes will vary.¶

Severity-boundary signals:¶

• Remote code execution: roughly 2x more likely to be classified critical than high (about a +30 percentage-point skew toward critical). Basis for the decision tree placing RCE at the top of critical.¶
• IDOR: roughly 2x more likely to be classified high than critical (about a +22 percentage-point skew toward high). Basis for placing bounded-scope IDOR at high in the decision tree.¶
• Account takeover: about a +21 percentage-point skew toward paid over rejected. Basis for treating confirmed ATO as always reportable.¶
• Reflected cross-site scripting: about 4x more likely to be marked informational than paid. Basis for the medium baseline and the HIGH-only-when-chained-to-ATO exception.¶

Report-gate signals:¶

• Approximately a third of rejected reports lack any reproducible HTTP request/response artefact. Missing proof is the strongest single correlate of rejection. Basis for gate condition 1 ("REQUEST to RESPONSE proving the issue").¶

Structural signals (positive oracle, high and critical only):¶

• Impact section: present in roughly 99% of paid reports.¶
• Summary + Steps-to-Reproduce sections: present in roughly 87% of paid reports.¶
• Dominant section ordering: Summary -> Steps to Reproduce -> Impact in roughly half of paid reports, with a Supporting Material variant accounting for another quarter.¶
• Anti-pattern words ("potential", "may allow", "possibly"): present in only a small minority (roughly 5%) of paid reports. Basis for the prohibited-language rule in Section 8.8.¶

Triager-language signals:¶

• Explicit upgrade phrases in triager comments appear substantially less often than explicit downgrade or rejection phrases across the corpus. Basis for the "when uncertain, pick the lower level" rule in Section 6.¶

3.6. Human Judgment Points

Not every rule in FAST can be resolved from data alone. A small number of decisions require human judgement, and each such decision is documented so that a reader can distinguish empirically-derived rules from opinionated defaults. The judgement points in this version of FAST are:¶

• Whether reports resolved without payment on vulnerability disclosure programs (which do not offer bounties) should be treated as positive-oracle inputs. This document treats them as positive-oracle inputs on the basis that a program-assigned severity is a triager verdict regardless of whether payment occurred.¶
• Whether a numerically-stated blast radius is required for high and critical, or whether qualitatively-unbounded language such as "any authenticated user" is acceptable. This document accepts either.¶
• Whether the primary classification driver is the vulnerability class or the achieved access type. This document treats them as combined: both matter, and neither alone is sufficient.¶
• Whether reflected cross-site scripting is medium by default or should be treated as never-reportable in most programs. This document treats it as medium by default, upgrading to high only when chained to account takeover with a working proof of concept.¶

Amendments to these judgement points require evidence from a comparable corpus that materially disagrees with the current resolution.¶

3.7. Reproducibility

The extraction pipeline is deterministic and scriptable. Nothing in the derivation of FAST depends on hidden state, private tooling, or non-public data. Any researcher, security team, or program that possesses a corpus of reports with the same shape (submitted text, triage outcome, severity assignment, and activity timeline) can apply the same pipeline to their own corpus. The output of that process is a per-record feature set from which the same four analyses (severity boundary, report-gate, chain-escalation, triager-language) and the same writing-style extraction can be performed.¶

Contributors to FAST are not required to disclose confidential vulnerability reports. Aggregated feature frequencies and outcome-boundary statistics are sufficient to confirm or challenge the rules herein.¶

3.8. Bias and Limitations

FAST is derived from a single researcher's corpus. That corpus is biased by target selection, testing style, and the specific programs the researcher engages with. Programs in industries not well represented in the corpus, or with idiosyncratic scoring norms, may diverge from the rules in this document. FAST is a strong default, not a universal law.¶

FAST is not a statistical proof. It is an empirical framework whose rules trace back to observed outcomes. Where the data is thin, the rules err toward the more conservative interpretation (see Section 6).¶

FAST is opinionated. Reasonable practitioners may disagree with specific rules. The Call for Comments in Section 14 is the mechanism by which such disagreement is expected to reshape future versions.¶

4.1. Lead vs Vulnerability

The distinction between a lead and a vulnerability is the single most important concept in FAST. In the derivation corpus, the majority of reports that programs marked informational or not-applicable were leads submitted before they had converted to vulnerabilities.¶

A finding is a lead if any of the following is true:¶

• The exploit has not been executed against the target and has not returned a response demonstrating impact.¶
• The evidence consists only of tool output (scanner alerts, fingerprinting, static analysis findings).¶
• The reasoning relies on speculation ("if X existed, then Y would be possible").¶
• The observation shows that a feature exists (an endpoint, a token, a configuration) but does not demonstrate what an attacker can DO with it.¶

An agent's correct behaviour on finding a lead is to continue investigating until the lead converts to a vulnerability (proof of impact) or is exhausted. Leads MUST NOT be reported.¶

4.2. Real Outcomes as Truth

Every rule in FAST is grounded in two sources of empirical evidence:¶

• What hackers actually get paid for. If a class of finding consistently receives payment at critical in the derivation corpus, that class is critical.¶
• What security teams actually accept as a vulnerability. If security teams consistently accept, prioritise, and remediate a class of finding, it belongs in the reportable ladder. If they consistently close it as informational, out of scope, or intended behaviour, it does not.¶

Both signals derive from the same underlying decisions -- a program paying is a security team accepting -- but stating them explicitly matters because FAST governs both sides of the reporting relationship. Offensive agents optimise for the payout signal. Defensive agents optimise for the acceptance signal. Both converge on the same severity when the standard is applied correctly.¶

This grounding is empirical, not theoretical.¶

4.3. Access as Classifier

The primary driver of severity is the ACCESS the exploit lets the attacker achieve, combined with the vulnerability class:¶

• Execute commands on target infrastructure → Critical.¶
• Read customer PII, credentials, financial data, or employee data at scale → Critical.¶
• Impersonate any user (account takeover) → Critical or High depending on the interaction requirement.¶
• Read a bounded set of sensitive data → High.¶
• Write data belonging to other users → High or Medium depending on data sensitivity.¶
• Modify non-sensitive data or bypass a non-sensitive control → Medium.¶
• Trigger noticeable side effects with no data or authentication impact → Low.¶
• Demonstrate that something exists without demonstrated access → Not reportable.¶

4.4. Both Sides, Same Rules

FAST governs both offensive agents that produce reports and defensive agents that render verdicts. Before every classification and every submission, an agent MUST ask: "If I were the other side reading this, would I agree?" A NO answer indicates that either the evidence is missing (offensive side) or the criteria are being misapplied (defensive side).¶

8.1. Title

Format: "{Impact} on {Target} via {Root Cause}".¶

The title MUST convey what the attacker can do, where, and how. It MUST NOT use hedging language such as "potential", "may allow", or "possibly". It MUST NOT consist only of a CVE identifier; the title must describe the demonstrated impact against the specific target.¶

8.2. Sections and Order

The following section order is REQUIRED:¶

## Summary
## Steps to Reproduce
## Impact
## (optional) Remediation

An accepted variant places a "Supporting Material / References" section between Steps and Impact for attachments.¶

Agents SHOULD NOT invent additional sections. Content that does not fit one of the sections above either belongs inline within an existing section or does not belong in the report.¶

8.3. Summary Section

One to three sentences. States the vulnerability, the target, and the outcome. No preamble, no autobiography, no CVSS calculation.¶

8.4. Steps to Reproduce Section

A numbered list of concrete actions. It MUST include:¶

• Account setup or preconditions required.¶
• Each HTTP request as a fenced code block including request line, Host header, and critical headers (authentication tokens, content type).¶
• The observed response (inline text, redacted where necessary, or a data-bearing screenshot when the response body proves impact).¶
• Any chained request(s) required by a multi-step exploit.¶

The steps MUST be complete enough that a triager can reproduce the exploit in under two minutes.¶

8.5. Impact Section

One paragraph. States the concrete consequence and the blast radius. The blast radius MUST be stated for reports classified High or Critical, either:¶

• Numerically, where possible: a concrete count of affected users, records, documents, or accounts.¶
• Qualitatively unbounded, where scope is truly open: "any authenticated user", "all customers on the platform".¶

The Impact section MUST preemptively justify the claimed severity per the FAST decision tree. This is the primary downgrade defence: a triager should not have to infer the reporter's reasoning.¶

8.6. Remediation Section (Optional)

Included when the fix is obvious, at most one or two sentences. Not a full advisory. Skipped when the remediation is not obvious.¶

8.7. One Vulnerability per Report

Same root cause across multiple endpoints constitutes one report, enumerated internally as POC 1, POC 2, and so on. Different root causes require separate reports.¶

8.8. Prohibited Language

Reports MUST NOT contain:¶

• "potential", "might be vulnerable", "could be vulnerable", "possibly".¶
• Speculation about follow-on impact not proven ("if this were chained with X, an attacker could Y").¶
• Tool output presented as sole evidence.¶
• CVSS calculations used as the classifier for severity band. CVSS scores a vulnerability's technical characteristics; FAST decides the severity band for reporting. Keep them separate.¶