9 minmedium
Agents vs. agents: how we triage HackerOne reports for $2 each, 85% as well as a human
Elastic Security Labs built an AI-powered vulnerability triage system for their HackerOne bug bounty program that uses Claude LLM in an eight-stage analysis pipeline with an independent adversarial review, achieving 85% agreement with human analysts at ~$2 per report. The system processes untrusted, attacker-controlled input at every stage, making prompt injection, credential exfiltration, and sandbox escape the primary threats to the triage infrastructure itself. A layered defense-in-depth architecture — ephemeral VMs, network isolation, egress filtering, credential separation, resource limits, and human-in-the-loop final decisions — mitigates these risks while keeping the cost per triage low.
Conf:high
Detection / Hunteropenrouter
What Happened
Elastic's security team built an AI system to automatically review vulnerability reports submitted to their HackerOne bug bounty program. The volume of reports had skyrocketed because AI tools made it cheap for people to generate and submit large numbers of low-quality reports. The new AI triage system reads each report, assesses whether the claimed vulnerability is real and exploitable, scores its severity, and sometimes tries to reproduce the issue in a disposable virtual machine that deletes itself after 30 minutes. The system agrees with human security engineers 85% of the time and costs about $2 per report. A human still makes the final decision on every report. The team took extensive security precautions because the reports themselves could contain malicious instructions designed to manipulate the AI, steal credentials, or break out of the sandbox. Organizations running bug bounty programs could adopt a similar approach by encoding their own product-specific knowledge into the triage rules.
Key Takeaways
- AI-generated vulnerability reports caused HackerOne submissions to spike to 1,390 in H1 2026, exceeding full-year totals for 2024 and 2025 combined.
- An eight-stage AI triage pipeline using Claude achieves 85% agreement with human analysts at approximately $2 per report, validated against 764 known-outcome reports.
- Prompt injection via report text is identified as the most likely attack vector against the triage system, requiring zero special access from an attacker.
- Defense-in-depth architecture uses ephemeral GCP VMs with 30-minute auto-shutdown, network isolation, egress filtering via Squid proxy, credential separation, and read-only mounts to contain sandbox escapes.
- An adversarial review stage independently challenges every analysis conclusion, catching CVSS inflation, missed triage rules, and severity anchoring in roughly 15% of cases.
Affected Systems
- Elastic Stack (Elasticsearch, Kibana, Fleet, Elastic Agent, Logstash, Beats, APM Server)
- HackerOne bug bounty platform
- Google Cloud Platform Compute Engine VMs (e2-standard-2, e2-standard-4)
- Claude LLM API by Anthropic
- Elastic Workflows (GA in Elastic 9.4)
Vulnerabilities (CVEs)
None identified.
Attack Chain
- Initial Access: Attacker submits a vulnerability report to HackerOne containing crafted text designed to manipulate the AI triage agent (prompt injection)
- Execution: Report text is processed by Claude LLM in the analysis VM; injected instructions attempt to alter severity scoring, bypass triage rules, or leak internal context
- Credential Access: Reproduction steps may attempt to extract API keys, cloud metadata, or internal configuration from the VM environment
- Defense Evasion: Crafted reports attempt to anchor severity to researcher-claimed levels or mirror researcher framing to avoid independent assessment
- Sandbox Escape: Reproduction steps attempt to break out of the Docker container to the host VM or pivot to the broader network via egress
- Impact: If containment fails, attacker could exfiltrate credentials, manipulate triage outcomes, or use the VM for resource abuse or lateral movement
Detection Availability
- YARA Rules: No
- Sigma Rules: No
- Snort/Suricata Rules: No
- KQL Queries: No
- Splunk SPL Queries: No
- EQL Queries: No
- Other Detection Logic: No
No detection rules or queries are provided in the article. The article describes an architectural defense-in-depth approach rather than specific detection logic.
Detection Engineering Assessment
copy:
| Dimension | Rating | Rationale |
|---|---|---|
| EDR Visibility | Low | The article describes ephemeral GCP VMs with no persistent EDR agent. The reproduction environment runs Docker containers on these VMs, but since VMs self-destruct after 30 minutes and are freshly provisioned from a Packer image, traditional EDR telemetry would be transient and not retained. The non-root 'triage' user and read-only mounts limit what EDR would observe. |
| Network Visibility | Medium | All outbound traffic from the reproduction VM routes through a Squid proxy at 10.0.0.10:3128, providing visibility into egress attempts. The tester container has no internet access by default. However, this is a purpose-built sandbox, not an enterprise network where defenders would typically hunt. |
| Detection Difficulty | Hard | The primary attack vector (prompt injection via report text) is not detectable by traditional security tooling — it requires analysis of LLM input/output. Sandbox escapes and credential exfiltration attempts would generate some network and process telemetry, but the ephemeral nature of the infrastructure means logs must be collected centrally in real-time before the VM terminates. |
Required Log Sources
- GCP Compute Engine VM lifecycle logs
- Squid proxy access logs (egress from reproduction VMs)
- Docker container event logs on reproduction VMs
- Google Cloud Storage write logs (analysis output uploads)
- Elastic Workflows execution logs
- HackerOne API audit logs
Hunting Hypotheses
copy:
| Hypothesis | Telemetry | ATT&CK Stage | FP Risk |
|---|---|---|---|
| Consider hunting for unexpected outbound network connections from GCP VMs in the audit-network VPC that bypass the Squid proxy, which could indicate a sandbox escape attempt or credential exfiltration. | GCP VPC flow logs, Squid proxy logs, GCP firewall logs | Exfiltration / Sandbox Escape | Low — the architecture is designed so all egress goes through the proxy; any deviation is anomalous by design. |
| Consider hunting for reproduction VMs that exceed the 30-minute lifetime threshold, which could indicate the auto-shutdown mechanism was disabled or bypassed by an attacker who escaped the sandbox. | GCP Compute Engine instance lifecycle logs, VM uptime metrics | Persistence / Sandbox Escape | Low — VMs are designed to auto-terminate; extended uptime is inherently suspicious. |
| Consider monitoring for Docker container processes running as root or attempting to access the host filesystem from the tester container, which could indicate a privilege escalation attempt after container escape. | Docker container event logs, process execution logs on the reproduction VM | Privilege Escalation | Medium — legitimate reproduction steps may invoke privileged Docker operations, requiring context-aware analysis. |
| Consider hunting for credential access patterns where the reproduction VM attempts to read GCP metadata endpoints or environment variables not assigned to its phase, indicating credential exfiltration across phases. | GCP metadata API access logs, process environment variable access events | Credential Access | Low — the architecture explicitly separates credentials by phase; cross-phase access is anomalous. |
Control Gaps
- Traditional EDR agents are not persistently deployed on ephemeral VMs, limiting post-compromise forensic visibility.
- Prompt injection attacks against the LLM agent are not detectable by network or endpoint security tooling — they require analysis of the LLM's input and output content.
- Data poisoning attacks that subtly shift triage patterns over time would be difficult to detect without longitudinal monitoring of triage decision drift.
- The 30-minute VM auto-shutdown means forensic evidence on the VM is lost unless logs are streamed to a central collector in real-time.
Key Behavioral Indicators
- GCP VM in audit-network VPC making direct outbound connections bypassing the Squid proxy at 10.0.0.10:3128
- Docker container on reproduction VM attempting to access host filesystem paths outside the read-only mount
- Process running as root on the reproduction VM when the triage agent should run as the unprivileged 'triage' user
- Reproduction VM attempting to access GCP metadata service or cloud APIs not required for its phase
- VM instance exceeding 30-minute runtime threshold without termination
- Tester container attempting to join the external bridge network reserved for product containers
False Positive Assessment
Low — this article describes a defensive architecture and threat model, not detection rules that would generate alerts. The hunting hypotheses are specific to the described ephemeral VM infrastructure and would have low false positive rates by design.
Recommendations
Immediate Mitigation
defender takeaway
- Verify against your organization's incident response runbook and team escalation paths before acting. If you operate an AI-powered triage or analysis system that processes untrusted input, consider auditing whether the AI agent can take external actions directly — the article's core mitigation is that all agent output flows through a human-approved orchestrator.
- Consider reviewing whether credentials needed by your AI pipeline are scoped to the minimum phase that requires them, stored in a secrets manager, and never written to disk.
- If you run sandboxed reproduction or analysis environments, evaluate whether they use ephemeral infrastructure with auto-termination rather than long-running hosts with persistent state.
Infrastructure Hardening
- Consider implementing network isolation for any environment that processes untrusted input — the article's pattern of internal Docker networks with no default internet access, combined with a single egress proxy, provides a strong containment model.
- Evaluate whether egress filtering through a dedicated proxy (such as Squid) would provide visibility into outbound traffic from your sandbox or analysis environments.
- If applicable to your cloud infrastructure, consider using immutable Packer-built VM images with agent code baked in at build time rather than pulled at runtime, to reduce supply chain risk.
- Consider enforcing resource limits (CPU, memory, execution timeout) on any container that executes untrusted or researcher-described steps.
User Protection
- If your organization runs a bug bounty program, consider implementing an AI-assisted first-pass triage gate to reduce the volume of reports requiring senior engineer attention.
- Evaluate whether your triage process includes an independent adversarial review step that challenges analysis conclusions before they reach a human reviewer.
- Consider calibrating any AI triage rules against your full historical corpus of reports rather than a small sample, to avoid category-level blind spots.
Security Awareness
- Consider training security engineers on prompt injection risks when using LLM-based tools to process untrusted input, emphasizing that report text is adversarial by nature.
- If your team uses AI for vulnerability analysis, consider building awareness of anchoring bias — the tendency to unconsciously adopt the reporter's framing rather than forming an independent assessment.
- Consider documenting the threat model for any AI system that processes external input, treating the AI system itself as a security-critical asset that attackers may target.
MITRE ATT&CK Mapping
MITRE ATT&CK Mapping5 techniques
Tactic
Initial Access
Tactic
Privilege Escalation
Tactic
Credential Access
Tactic
Impact
Additional IOCs
- File Paths:
/opt/vuln-triage-agent- Location on the Packer-built VM image where the triage agent code is baked in at build time, not pulled from a repository at runtime.
