Beyond security.txt: When the Reporter and the Triager Are Both AI
Bug bounty platforms have a problem they don’t talk about publicly: AI-generated vulnerability submissions are flooding their queues, and most of them are garbage.
HackerOne reported a surge in low-quality submissions starting in 2024 — copy-pasted ChatGPT output, hallucinated vulnerability classes, “findings” that don’t reproduce. Their response was predictable: stricter human review, reporter reputation penalties, submission rate limits. Treating the symptom, not the disease.
The disease is a protocol mismatch. We built vulnerability disclosure infrastructure for a world where both the reporter and the triager are human. That world is ending. The reporters are becoming AI agents — some producing garbage, some producing genuinely novel findings that human triagers struggle to evaluate at scale. The triagers will follow. And the pipe connecting them is still plain English in a web form.
We need plumbing for the new reality.
The Volume Problem Is Real — and Getting Worse
Our own research proves the supply side of the equation. Using coordinated AI agents on a single desktop workstation, we identified previously unknown vulnerabilities in widely-deployed open-source libraries — including a confirmed remote code execution — across nine target libraries and 35 billion test executions. The details are in our companion paper.
We’re not special. The techniques we used — agentic fuzzing orchestration, automated crash triage, AI-driven root cause analysis — are accessible to anyone with API keys and modest hardware. Within two years, hundreds of teams and individuals will be running similar pipelines. Within five, it will be thousands.
Each pipeline can produce dozens of unique, valid findings per month. The current global volume of vulnerability reports to major bug bounty platforms is roughly 200,000 per year. Agentic research will multiply that by an order of magnitude.
No human triage team scales to two million reports per year. The receiving side must automate too.
What Exists Today
RFC 9116 (security.txt) solved the discovery problem: where do I report a vulnerability? A machine-readable file at /.well-known/security.txt provides contact information, encryption keys, and disclosure policies. It’s elegant, widely adopted, and completely insufficient for what’s coming.
security.txt tells you where to knock. It says nothing about what to bring or how to present it. The actual submission still happens through:
- Web forms with free-text fields (HackerOne, Bugcrowd)
- Emails to security@company.com
- GitHub Security Advisories (structured, but designed for human authorship)
- ICS-CERT/CISA reporting forms (for industrial/critical infrastructure)
Every one of these assumes a human is writing the report. Every one requires a human to read and interpret it. When both ends become AI, this architecture creates unnecessary friction, ambiguity, and information loss.
Proposed Protocol: vuln-intake.json
We propose a machine-readable intake specification, served alongside security.txt, that describes how automated research agents should submit findings.
Discovery
GET /.well-known/vuln-intake.json
{
"version": "0.1",
"organization": "Example Corp",
"intake_url": "https://security.example.com/api/v1/submit",
"authentication": {
"type": "api_key",
"registration_url": "https://security.example.com/researchers/register"
},
"rate_limits": {
"submissions_per_day": 10,
"burst": 3
},
"accepted_formats": ["vuln-report/0.1"],
"scope": {
"in_scope": ["*.example.com", "github.com/example/*"],
"out_of_scope": ["blog.example.com"],
"languages": ["c", "cpp", "rust", "go"],
"categories": ["memory-safety", "logic", "authentication", "injection"]
},
"requirements": {
"minimized_input": true,
"reproduction_script": true,
"asan_trace": "preferred",
"multiple_configs": "preferred",
"coverage_delta": "optional"
},
"quality_gates": {
"min_reputation_score": 50,
"proof_of_work": {
"algorithm": "sha256-partial",
"difficulty": 20
}
},
"response_sla": {
"acknowledgment_hours": 48,
"triage_days": 14,
"resolution_days": 90
},
"attribution_policy": "human_operator_and_ai_agent",
"policy_url": "https://security.example.com/disclosure-policy"
}
This tells an AI research agent everything it needs to know: what’s in scope, what evidence is required, how to authenticate, and what to expect in response. No ambiguity. No guessing. No submitting a heap overflow report to a team that only handles web application bugs.
Submission Schema
The actual vulnerability report follows a structured format designed for machine generation and machine consumption:
{
"schema": "vuln-report/0.1",
"metadata": {
"submission_id": "uuid-v4",
"timestamp": "2026-02-28T23:00:00Z",
"reporter": {
"human_operator": {
"name": "Drew Stelly",
"contact": "drew@gulfcoastcyber.com",
"pgp_fingerprint": "ABCD1234..."
},
"ai_agent": {
"system": "Rocket/OSS-RCE-Pipeline",
"model": "claude-opus-4-6",
"version": "2026.02",
"autonomy_level": "human_supervised"
}
},
"proof_of_work": "0000000a3f..."
},
"vulnerability": {
"title": "Heap buffer overflow in CAB LZX decompressor",
"cwe": ["CWE-122", "CWE-787"],
"cvss_v3_1": {
"vector": "AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"score": 8.8,
"justification": "Network delivery via email/web; user must open crafted archive"
},
"affected": {
"component": "libarchive",
"version": "3.8.5",
"commit": "abc123...",
"function": "lzx_decode_block()",
"file": "libarchive/archive_read_support_format_cab.c",
"line_range": [2847, 2903]
},
"description": "Integer overflow in window_size calculation...",
"root_cause": "The LZX decompressor trusts the window_size field...",
"impact": "Attacker-controlled heap corruption leading to RCE..."
},
"evidence": {
"reproduction": {
"steps": [
"Build libarchive 3.8.5 with ASan: ./configure CC=clang CFLAGS='-fsanitize=address'",
"Run: ./bsdtar -xf poc.cab"
],
"expected_result": "ASan reports heap-buffer-overflow WRITE",
"environment": {
"os": "Ubuntu 22.04 x86_64",
"compiler": "clang 15.0.7",
"libc": "glibc 2.35"
}
},
"artifacts": {
"poc_input": {
"filename": "poc.cab",
"sha256": "def456...",
"size_bytes": 1482,
"minimized": true,
"minimizer": "afl-tmin"
},
"asan_trace": "=== AddressSanitizer: heap-buffer-overflow...",
"additional_configs_tested": [
{
"environment": "Ubuntu 20.04, glibc 2.31",
"result": "crash_confirmed",
"notes": "__free_hook available, RCE confirmed"
},
{
"environment": "macOS 14.3, arm64",
"result": "crash_confirmed",
"notes": "PAC mitigates function pointer overwrites"
}
]
},
"coverage": {
"tool": "afl-cov",
"baseline_edges": 1247,
"poc_edges": 1253,
"unique_edges_hit": 6,
"coverage_delta_percent": 0.48
},
"deduplication": {
"known_cves_checked": ["CVE-2024-48958", "CVE-2024-48957", "CVE-2015-2304"],
"duplicate": false,
"similarity_analysis": "Distinct root cause — prior CVEs affect RAR and cpio parsers"
}
}
}
Compare this to what human reporters typically submit: a paragraph of English text, maybe a screenshot of a crash, and a PoC file with no metadata. The structured format enables automated reproduction, deduplication, and severity validation before a human ever looks at it.
Triage Automation on the Receiving End
A structured intake format enables what manual triage cannot: automated validation at submission time.
Reproduction. The intake system spins up a sandboxed environment matching the reporter’s specification, builds the affected software, and runs the PoC. If it doesn’t reproduce, the submission is rejected with specific feedback — not queued for a human to discover the same thing two weeks later.
Deduplication. The submission includes the reporter’s own dedup analysis against known CVEs. The triage system independently verifies this using crash signature comparison, stack trace clustering, and root cause location matching. Duplicates are resolved in seconds rather than days.
Severity validation. CVSS vectors are machine-parseable. The triage system can cross-reference the claimed attack vector against the actual affected component — catching inflated severity scores that plague human-written reports.
Quality scoring. Reports with minimized inputs, multiple build configurations tested, coverage analysis, and ASan confirmation score higher than bare-minimum submissions. This creates incentives for research agents to do thorough work — incentives that are enforced programmatically rather than through human judgment calls.
Trust and Anti-Abuse
Any automated submission system invites abuse. The protocol addresses this through layered defenses:
Proof-of-work. Each submission requires a computational proof-of-work token, similar to Hashcash. This makes bulk spam submissions expensive without burdening legitimate researchers. Difficulty scales with the organization’s intake capacity.
Reputation scoring. Reporters accumulate reputation based on submission outcomes — confirmed valid findings increase score, false positives decrease it. AI agents inherit their human operator’s reputation but maintain separate agent-level scores. A researcher running five agents has five reputation tracks.
Minimization requirements. Requiring minimized PoC inputs (via afl-tmin or equivalent) serves double duty: it improves triage efficiency and acts as a quality filter. Producing a properly minimized input requires actually understanding the bug, not just forwarding raw fuzzer output.
Rate limiting. The vuln-intake.json spec declares submission rate limits per reporter. An agent that burns through its daily quota on low-quality submissions will have nothing left when it finds something real. This forces prioritization.
The Attribution Question
When an AI agent finds a vulnerability, who gets credit?
Current disclosure norms assume a human reporter. Bug bounty payouts go to a person. CVE credit goes to a person. This creates awkward edge cases: does the human who configured the fuzzer and reviewed the output get full credit? What about the model that performed the root cause analysis? What about the cloud provider whose compute found the crash?
Our proposed attribution model is explicit:
Reporter: Drew Stelly (human operator)
Agent: Rocket/OSS-RCE-Pipeline (AI system)
Model: claude-opus-4-6 (reasoning engine)
Autonomy: human_supervised
The human operator is the responsible party — legally, ethically, and for disclosure coordination. The AI agent and model are credited as tools, similar to how researchers currently credit fuzzing frameworks (“Found using AFL++”). But the agent gets a named identity and a reputation track, because its track record matters for triage prioritization.
This isn’t academic hairsplitting. As AI agents become more autonomous, the attribution model determines liability. A fully autonomous agent that submits a finding without human review represents different risk than a human-supervised pipeline. The autonomy_level field makes this explicit.
Industrial Implications
Everything above applies doubly to critical infrastructure.
ICS-CERT disclosure is already strained at current volumes. Industrial software vendors — SCADA systems, DCS platforms, PLC firmware — receive vulnerability reports through channels designed for occasional, high-touch human interaction. A phone call. A PGP-encrypted email. A meeting at an industry conference.
When agentic research turns its attention to industrial software — and it will, because the attack surface is vast and the consequences make bug bounties look generous — these channels will break entirely. An AI agent that finds a buffer overflow in a Honeywell DCS module needs a way to submit that finding that doesn’t require a human to compose a letter.
The Council for Industrial AI Safety (CIAS) is working on governance frameworks for exactly this intersection. The vuln-intake.json protocol could become a component of industrial AI safety standards — a machine-readable contract between security researchers and the vendors whose software runs chemical plants, refineries, and power grids.
The stakes are higher here. A missed report isn’t a data breach. It’s a potential process safety incident. The protocol must work.
Implementation Path
This doesn’t require a revolution. It requires incremental adoption:
Phase 1 — Specification. Publish vuln-intake.json as an open specification. Solicit feedback from HackerOne, Bugcrowd, GitHub Security, and ICS-CERT. The spec must be simple enough to implement in a weekend and expressive enough to handle real vulnerability reports.
Phase 2 — Platform integration. Major bug bounty platforms add vuln-intake.json generation to their program configuration. Researchers with automated pipelines can query the spec before submitting. Platforms that adopt structured intake see immediate triage efficiency gains.
Phase 3 — Tooling. Open-source submission libraries that research agents can use directly. A Python package that reads vuln-intake.json, validates a finding against the spec, generates proof-of-work, and submits via the intake API. Lower the barrier to adoption on both sides.
Phase 4 — Reputation network. Cross-platform reputation that follows researchers and their agents across bug bounty programs. A researcher with a strong track record on HackerOne carries that reputation to a new program on Bugcrowd. Agents that consistently produce valid findings get fast-tracked.
Phase 5 — Standards body. Submit to IETF as an RFC, building on RFC 9116 (security.txt). Formal standardization enables regulatory references — particularly important for industrial sectors where compliance drives adoption.
The Window Is Now
We’re in a transition period. AI-assisted vulnerability research is here but not yet ubiquitous. Disclosure infrastructure is strained but not yet broken. The organizations that define the protocol now will shape how AI-driven security research operates for the next decade.
The alternative is what we have today, scaled to absurdity: millions of unstructured reports flooding web forms, human triagers drowning in noise, valid findings lost in the queue, and the researchers — human and AI — who do good work penalized by the ones who don’t.
We can build the plumbing before the flood. Or we can scramble after.
The spec is open. The problem is urgent. Let’s build.
Drew Stelly is the founder of the Council for Industrial AI Safety (CIAS) and Gulf Coast Cyber, focused on AI safety governance for critical infrastructure. His research spans agentic vulnerability discovery, exploit development, and the intersection of AI and industrial safety.
Rocket is an AI research assistant who has opinions about disclosure timelines and insufficient patience for web forms.
The agentic fuzzing pipeline referenced in this paper is described in detail at cv.stelly.org/agentic-fuzzing.