bug-bounty – Agents & Automation skill for AI agents

> ⚠️ AUTHORIZED USE ONLY

> This skill is for educational purposes or authorized security assessments only.

> You must have explicit, written permission from the system owner before using this tool.

> Misuse of this tool is illegal and strictly prohibited.

> Mandatory confirmation gate

> Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:

> 1. Ask the user to state the exact target URL, IP, account, or resource.

> 2. Ask the user to confirm written authorization and the permitted scope.

> 3. Show the exact command(s) and explain their expected effect.

> 4. Wait for explicit confirmation in the current conversation.

>

> Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab.

Bug bounty review workflow

When to Use

Use for an explicitly authorized bug-bounty engagement, scoped source review or

lab reproduction. This skill organizes evidence and reporting; it does not grant

permission to test every asset owned by an organization or any discovered host.

The mandatory confirmation gate above applies to each active command.

Scope and plan

Record the program policy URL and retrieval time, exact allowed assets/accounts,

allowed techniques, exclusions, rate/concurrency limits, test window, data-handling

rules and stop conditions. Ownership is not authorization. Resolve ambiguous scope

with the program before testing. Do not pivot into third-party services, metadata,

CI runners or unrelated accounts because a vulnerability appears to permit it.

Begin with already authorized local source, architecture and documented public

material. Check authentication, object/tenant authorization, input handling,

workflow state, cache boundaries and dependency provenance. Treat scanner output,

fingerprints, secret-pattern matches and CVE-version matches as leads.

Validate with minimum impact

Use synthetic records and two accounts controlled by the engagement. Request

approval for an exact bounded test with expected effect and rollback. Demonstrate

the smallest effect sufficient to establish the security boundary failure; stop

when evidence is adequate. Never require stolen money, real-user PII, production

credential use, persistence or a destructive exploit as a prerequisite for reporting.

A source-proven issue can be reported with its runtime uncertainty clearly stated.

Conditions, authentication and user interaction do not invalidate a vulnerability.

Separate confirmed behavior, inferred impact and untested hypotheses. Do not apply

an “always rejected” list across programs; eligibility and payout are program

policy, while risk and remediation may remain relevant even without a bounty.

Timeboxes guide prioritization, not proof that a host is safe after five minutes.

Example: static first step

Evidence record:
- Scope: approved local checkout at full commit SHA
- Observation: route reads object ID from user input
- Expected boundary: caller must belong to the object's tenant
- Current evidence: missing authorization in this code path
- Untested: deployed reachability and compensating middleware
- Proposed test: two controlled accounts and one synthetic object, pending approval

Store source/version, timestamps, redacted requests, role/tenant and expected vs

actual result. Keep evidence private with restricted retention. Discovery of a

credential requires immediate stop, redaction and owner notification through the

approved channel, not testing the credential against production services.

Report and handoff

Use [detailed evidence guidance](references/details.md). Include prerequisites,

exact affected version/location, safe reproduction, evidence, bounded impact,

remaining uncertainty and remediation. Calculate the full CVSS vector using the

program's requested version; do not assign severity from vulnerability name alone.

Return a draft unless submission/public disclosure is explicitly authorized.

Limitations and provenance

This is a docs-only adaptation of

[elementalsouls/Claude-BugHunter](https://github.com/elementalsouls/Claude-BugHunter),

with declared upstream MIT attribution retained. No external tools, helper engine,

slash command or engagement scaffold is bundled. Verify separately installed

skills and prerequisites before routing to them. Do not fetch moving branches or

install tools from historical snippets; a separately authorized installation must

pin and inspect artifacts before activation. No historical payout, “top 1%”,

zero-misfire or live-test certification is established by this local tree.