]> Obvane

cale@obvane.com

General severity triage vulnerability bug bounty autonomous agents This document specifies the Framework for Autonomous Severity and Triage (FAST): an empirical standard for how autonomous offensive security agents classify vulnerabilities, decide whether to submit reports, and write those reports. FAST is derived from a corpus of real bug bounty reports and their program-rendered triage outcomes rather than from theoretical scoring frameworks. It is designed to be applied by both offensive agents that hunt for vulnerabilities and by defensive agents or human triagers that render verdicts, so both sides of the reporting relationship operate under the same rulebook. This document is submitted as an Independent Submission and invites comment from researchers, triagers, bug bounty platforms, and security teams.

Introduction Autonomous AI agents deployed for offensive security work consistently misclassify vulnerability severity. Agents grounded in theoretical scoring frameworks such as CVSS systematically over-report, misclassify medium-severity findings as critical, submit unproven leads as vulnerabilities, and produce reports that human triagers reject as informational. The result is queue noise on the triage side and lost payouts on the researcher side. The root cause is not the agents themselves; it is the standards they have been given. Theoretical frameworks describe abstract risk. They do not reflect the specific patterns that bug bounty triagers accept or reject in practice. When an agent uses CVSS math to decide whether a finding is critical, it may arrive at a technically defensible number that a program's triage team would nevertheless reject. FAST addresses this gap directly. Its rules are grounded in two sources of empirical evidence that reinforce each other: what hackers actually get paid for, and what security teams actually accept as a vulnerability worth remediating. Both signals derive from a corpus of real triage outcomes: reports that programs paid for at each severity level, reports that programs rejected as informational or not-applicable, and the full triager-side language used across those outcomes. Because the rules come from observed outcomes rather than abstract risk models, an agent that follows FAST produces classifications that match what triagers accept in practice. FAST is designed for both sides of the reporting relationship. Offensive agents apply it when classifying and writing. Defensive agents apply it when rendering verdicts. When both sides use the same rulebook, disputes drop, queue noise drops, and payouts happen faster.

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 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) 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 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 describe authentication and provisioning of agents, not their decision-making about discovered vulnerabilities.
• CVSS is a theoretical scoring framework agnostic to triager behaviour, program norms, and empirical payout patterns.

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 , , and for that problem space.
• A finished, consensus-based standard. This document is a proposal and expects to evolve with community feedback.

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 when, and only when, they appear in all capitals, as shown here.

Terminology

Agent:

An autonomous or semi-autonomous software system that performs offensive security tasks (reconnaissance, vulnerability discovery, exploitation) or triage tasks (classification, verdict rendering) on behalf of a human researcher, security team, or program.

Lead:

An observation that MAY represent a vulnerability but has not been proven to be one. Leads are internal working state. Leads MUST NOT be reported.

Vulnerability:

A confirmed, exploitable issue with demonstrated impact, evidenced by a reproducible request/response chain, command output, or equivalent artefact. A vulnerability is what a report describes.

Report:

A written submission describing a confirmed vulnerability, its reproduction steps, and its impact, in the format prescribed by .

Report Gate:

The set of six binary criteria specified in that a finding MUST satisfy before it is submitted as a report.

Positive Oracle:

The subset of the derivation corpus (see ) consisting of reports that a program paid for at a given severity level. Used to define what constitutes a vulnerability at each level.

Negative Oracle:

The subset of the derivation corpus consisting of reports that a program rejected (marked informational, not-applicable, or otherwise closed without payment on the basis that the submission did not constitute a vulnerability). Used to define what is NOT a vulnerability.

Chain Escalation:

The pattern by which a base finding of one class combines with proven access of another type to produce a higher-severity vulnerability.

Triager:

The human or agent responsible for reviewing a submitted report and rendering a verdict.

Program:

The entity operating a bug bounty program, vulnerability disclosure program, or internal red-team engagement whose triagers render verdicts on reports.

Blast Radius:

A quantitative or qualitatively-unbounded statement of how many users, records, systems, or accounts are affected by a vulnerability.

Derivation Methodology The rules in this document are not derived from committee consensus or theoretical risk modelling. They are derived from a corpus of real vulnerability reports and the outcomes those reports received from program triage teams. This section describes the corpus, the extraction pipeline, and how the observations became rules. The methodology is transparent by design so that anyone with a comparable corpus can reproduce or challenge the derivation.

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.

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 . Duplicates carry no severity signal (they only indicate that another reporter submitted the same finding earlier) and are excluded from both oracles.

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.

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 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 . 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 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 is constructed from those patterns.

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 .

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 .

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.

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.

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 ). FAST is opinionated. Reasonable practitioners may disagree with specific rules. The Call for Comments in is the mechanism by which such disagreement is expected to reshape future versions.

Prime Directives FAST rests on four prime directives that follow from the derivation methodology.

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.

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.

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.

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).

The Report Gate Before an agent submits any report, it MUST answer YES to all six of the following gate conditions. If any answer is NO, the finding MUST NOT be submitted.

1. Can I show REQUEST to RESPONSE proving the issue?
2. Does this give an attacker access to something they should not have?
3. Would a triager reproduce this in under two minutes?
4. Is the impact clear without extra explanation?
5. Have I stated the blast radius (numeric or unbounded qualitative)?
6. Is this a vulnerability, not still a lead?

An agent that finds any answer to be NO MUST either continue investigating (if the missing element can plausibly be proven) or discard the finding as a dead lead. The agent MUST NOT submit hoping that the triager will accept a partial report.

The Decision Tree An agent classifying a confirmed vulnerability MUST walk the following decision tree from top to bottom, stopping at the first level whose predicate is YES. Levels MUST NOT be skipped.

1. Does the exploit run arbitrary commands on the target's infrastructure? YES: CRITICAL. Examples: remote code execution, command injection, template injection, deserialisation leading to shell.
2. Does the exploit read customer PII, credentials, financial data, or employee data at scale (multi-user or mass-source)? YES: CRITICAL.
3. Does the exploit permit account takeover of any user via a zero-click path, or accept forged authentication via a weak signing key, or grant any-account access via SAML/OAuth misconfiguration? YES: CRITICAL.
4. Does the exploit permit one-click account takeover with a working PoC, reach an internal service and observe its response body via SSRF, extract bounded data via SQL injection, use a leaked credential to confirm non-mass data access, or exploit an IDOR on sensitive bounded resources? YES: HIGH.
5. Is there confirmed stored cross-site scripting, reflected cross-site scripting (baseline; upgrade only when chained to account takeover with a working PoC), IDOR on non-sensitive resources, credential leak without demonstrated access yet, missing authentication on non-sensitive endpoints, or write access to non-sensitive records? YES: MEDIUM.
6. Is the finding verbose error output leaking stack traces, version disclosure, missing security headers on non-sensitive pages, or an open redirect without chain? YES: LOW.
7. Is this tool output only, CORS without victim PoC, "endpoint exists", OIDC discovery, subdomain takeover without working PoC, or any lead? Not reportable.

When the correct level is ambiguous between two adjacent levels, the agent MUST choose the LOWER level. In the derivation corpus, programs upgrade well-evidenced reports substantially less often than they downgrade or close weakly-evidenced ones.

Chain Escalation Findings compound. The severity of a chained exploit is defined by the FINAL demonstrated impact, not by the initial finding. The escalation patterns below are drawn directly from the positive oracle. Common chain-escalation patterns

Base finding	Chained proof	Result
Credential leak alone	(no chain)	Medium
Credential leak	+ authenticated request returning customer PII	Critical
Credential leak	+ authenticated access to non-sensitive data	High
SSRF (callback only)	(no data returned)	Medium
SSRF	+ cloud metadata credentials retrieved	Critical
SSRF	+ internal service response body observed	High
Weak JWT secret	(no forge)	Medium
Weak JWT secret	+ forged token accepted, account access	Critical
Token in JS file	(no use)	Lead, not reportable
Token in JS file	+ used to read production data	Critical
IDOR (mutable endpoint)	(no cross-user proof)	Lead, not reportable
IDOR	+ read/write records of other users, sensitive data	Critical
IDOR	+ read/write records of other users, non-sensitive data	High

An agent MUST report the highest severity it can PROVE. It MUST NOT report the highest severity it can hypothesize.

Report Format The report structure below is required. It is derived from the section structure used in the majority of reports that cleared triage and received payment at high or critical severity in the derivation corpus.

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.

Sections and Order The following section order is REQUIRED: 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.

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

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.

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.

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.

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.

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.

Dual-Audience Application FAST is dual-audience. The classification criteria and report requirements apply to both offensive agents producing reports and defensive agents or human triagers rendering verdicts. An offensive agent applying FAST produces reports that satisfy the report gate and follow the required format. A defensive agent applying FAST evaluates submitted reports against the same criteria and renders consistent verdicts. When both sides apply the same standard:

• Reports arrive triaged in the correct classification.
• Verdicts match the reporter's classification, minimising dispute.
• Queue noise drops because reporters self-filter leads before submission.
• Time-to-payout compresses because reproducibility is enforced upfront.

Defensive-side application:

• A report failing the report gate MAY be closed as informational with a citation to the specific gate condition failed.
• A report where classification is disputed MAY be resolved by walking the decision tree publicly in the comments.
• Severity upgrades are appropriate when the reporter provides additional evidence that satisfies a higher decision-tree level.

Post-Submission Behaviour An agent submitting reports SHOULD follow these post-submission rules:

• Respond to triager requests with evidence, not emotion.
• If a report is downgraded, provide new evidence supporting the higher classification, or accept the verdict. Do not argue without new evidence.
• If additional impact is discovered after submission, add it in a comment on the same report. This constitutes legitimate escalation and MAY result in a severity upgrade; it is NOT report-splitting.
• Respect triage queues. Do not badger.
• When asked to retest a fix, test honestly and comment on whether the fix holds.

Scope Judgment Programs publish scope policies. Agents MUST read the program policy for scope before conducting research. An exception exists for cases where an out-of-scope asset demonstrates a systemic in-scope issue. Example: an OAuth misconfiguration on an out-of-scope subdomain that shares its identity provider configuration with in-scope applications. In such cases the report SHOULD:

• Frame the report around the systemic in-scope issue.
• Explicitly identify which asset was tested against and why the in-scope asset is affected.
• Refrain from exploiting the out-of-scope asset for data access or destructive testing.

If the program declines such a report on scope grounds, the reporter MUST accept the verdict.

Security Considerations FAST governs the behaviour of autonomous offensive security agents. Poor implementation or misapplication of FAST may result in:

• Under-reporting of legitimate vulnerabilities if an agent classifies a finding as a lead when it is in fact a vulnerability.
• Over-reporting if an agent bypasses the report gate.
• Ethical violations if an agent exceeds the "minimum data needed to prove impact" rule and accumulates customer data.
• Legal exposure if an agent tests targets not authorised by the program's scope policy.

Implementations SHOULD enforce operational boundaries:

• No destructive testing.
• No persistent denial of service.
• Access only the minimum data required to prove impact.
• No retention of customer data as "evidence".
• No testing of assets outside program scope except as permitted by .

FAST does not authorise any testing. All authorisation derives from the program's own scope and rules of engagement. An agent applying FAST outside authorised scope may commit computer misuse or equivalent offences under applicable law.

IANA Considerations This document has no IANA actions.

Call for Comments This document is submitted as an Independent Submission and is explicitly a proposal, not a finished standard. It is expected to evolve with community feedback. The authors invite comment from:

• Individual researchers whose report history may confirm or contradict the classification rules herein.
• Bug bounty triagers whose queue experience may reveal gaps or disagreements with the decision tree.
• Bug bounty platforms considering FAST as a classification baseline for AI-generated submissions.
• In-house security teams (AppSec, PSIRT, VDP operators) whose classification norms may inform amendments.
• Red teamers whose internal reporting practices may benefit from a shared standard.
• Anyone building or operating autonomous offensive security agents that require severity and reporting standards.

Comment is welcomed via the FAST repository issue tracker (once published) and via the IETF Internet-Draft process. Substantive feedback SHOULD be grounded in evidence: the specific rule disagreed with, the outcome observed in the commenter's data, and the proposed amendment. Contributors do NOT need to disclose confidential vulnerability reports. Aggregated feature frequencies and outcome-boundary statistics are sufficient. The extraction pipeline described in is deterministic and reproducible on any comparable corpus.

Change Log

• draft-fast-severity-00: Initial submission.

References Normative References Informative References OWASP GenAI Security Project bawbel OWASP AIVSS Project FIRST IETF Network Working Group

Acknowledgements FAST is built from the vulnerability research of Cale Anderson. Thanks to the triagers and program teams whose verdicts, over years of engagement, comprise the empirical corpus this standard is derived from.