Bug Bounty After GPT-5.6: The New Bottleneck Is Proof, Scope, and Reproducibility

AI can accelerate vulnerability discovery, but the reports that survive triage still need evidence, authorization boundaries, and reproducible impact.

GPT-5.6 makes it cheaper to produce a plausible vulnerability hypothesis. It can inspect large codebases, follow long execution paths, compare patches, generate local test harnesses, coordinate security tools, and convert raw observations into polished technical prose.

None of that changes the standard that determines whether a bug bounty submission is valid.

A security team still needs defensible answers to a few stubborn questions:

Did the behavior actually occur? Can another analyst reproduce it? Did it cross a security boundary? Was every test authorized? What can an attacker achieve under realistic conditions? Which parts of the claimed impact were observed, which were demonstrated, and which were inferred?

Those questions matter more after GPT-5.6, not less.

OpenAI released GPT-5.6 on July 9, 2026 and described GPT-5.6 Sol as its strongest cybersecurity model to date. In OpenAI’s published evaluations, the model scored 73.5 percent on ExploitBench, 71.2 percent on SEC-Bench Pro, and 33.7 percent on ExploitGym under a six-hour configuration. Its internal capture-the-flag evaluation reached 96.7 percent. These are substantial results, but they do not mean that GPT-5.6 can reliably compromise hardened real-world systems on demand. OpenAI’s system card states that the model did not independently produce a functional full-chain exploit or another verifier-confirmed critical outcome against the real-world targets used in one of its evaluations. OpenAI identified exploit-development judgment, converting crashes into controlled primitives, and eliminating diagnostic or availability-only bugs as continuing bottlenecks. (OpenAI)

That gap between broad search capability and verified exploitation is also the central issue in AI-assisted bug bounty work.

Discovery is becoming abundant. Proof is not.

GPT-5.6 Changes the Supply Side of Bug Bounty

A large portion of vulnerability research consists of tasks that are difficult but structurally repeatable. A researcher must map an unfamiliar application, identify trust boundaries, trace attacker-controlled data, compare permission checks, reconstruct request sequences, understand framework behavior, build test inputs, inspect output, and preserve enough context to explain the result later.

GPT-5.6 can accelerate many of these steps.

It can index routes, controllers, data models, middleware, configuration files, test cases, issue history, and public documentation. It can compare protected and unprotected handlers. It can search for object lookups that are not constrained by the current user. It can identify parser entry points, deserialization paths, command construction, template rendering, archive extraction, file handling, URL fetching, and other security-sensitive operations.

It can also generate better questions:

• Does this authorization check protect the object or only the route?
• Can the same object be addressed through a second endpoint?
• Does the backend trust a tenant identifier supplied by the client?
• Can an invitation be reused after membership changes?
• Does a background worker revalidate permissions?
• Does a signed URL remain valid after the underlying object becomes private?
• Is a server-side URL fetcher restricted after DNS resolution or only before it?
• Does a patch close one entry point while leaving a semantically equivalent path open?
• Is the vulnerable dependency actually reachable through attacker-controlled input?

These questions can widen a researcher’s search space without requiring the researcher to manually inspect every possible path first.

GPT-5.6 can also help with the mechanical parts of testing. It can generate a local unit test, a property-based test, a mock service, a minimal HTTP client, a parser harness, or a script that replays a recorded sequence. It can compare control and experimental responses, identify changed fields, normalize timestamps, redact credentials, and produce a first report draft.

That is valuable work. It is not the same as validating a vulnerability.

A model that sees this handler may correctly identify a possible broken object-level authorization issue:

def download_invoice(invoice_id):
    invoice = db.get_invoice(invoice_id)
    return send_file(invoice.path)

The visible function does not check whether the current user owns the invoice. That observation is worth investigating.

It does not yet prove an IDOR.

Authorization may be enforced by middleware. The database method may automatically filter by the active tenant. The route may be internal. The identifier may be a cryptographically strong capability token. A reverse proxy may enforce identity-aware rules. The function may be unused. Another component may reject unauthorized objects before the handler runs.

The model has identified an absent check in one visible location. A valid bug bounty report must demonstrate that the effective system boundary fails.

This distinction becomes harder to see as models become better writers. A weak model may produce an obviously incomplete alert. A stronger model can produce a professional-looking vulnerability report containing a title, CWE classification, hypothetical attack chain, severity score, remediation guidance, and executive summary before anyone has established that the vulnerable path is reachable.

The report can look finished while the research is not.

Polish is not proof.

Report Generation Has Scaled Faster Than Triage

The pressure is already visible across vulnerability disclosure programs.

In May 2026, HackerOne reported that the industry had seen a surge of more than 100 percent in report volume following the arrival of more advanced AI models and tools earlier in the year. HackerOne said the additional volume included legitimate findings, but also duplicates, unverifiable submissions, and reports without enough depth to act on. It emphasized that researchers remain responsible for what they submit, regardless of whether a human or a tool generated the first draft. (ハッカーワン)

GitHub described a similar problem when it updated its bug bounty standards on May 15, 2026. GitHub said it had seen more reports without working proofs of concept, more theoretical attack scenarios that failed under scrutiny, and more submissions covering already-published ineligible categories. The company explicitly welcomed AI-assisted security research but required researchers to validate the output, demonstrate a real security boundary crossing, and provide concrete impact before submission. (The GitHub Blog)

Open-source maintainers have experienced the same asymmetry. curl ended its monetary bug bounty on January 31, 2026 after years in which the program had confirmed 87 vulnerabilities and paid more than $100,000 in rewards. Maintainer Daniel Stenberg wrote that the program’s confirmed-vulnerability rate had fallen from more than 15 percent in earlier years to below 5 percent in 2025, while low-quality AI-associated submissions consumed growing amounts of maintainer time. (daniel.haxx.se)

The downstream advisory system is under pressure as well. GitHub reported that its Advisory Database published 1,560 reviewed advisories in May 2026, more than five times its typical monthly output and the highest monthly total in its history. GitHub added that this record output still did not keep pace with incoming private reports, repository advisories, and CVE requests. (The GitHub Blog)

The economics explain why this matters.

Generating another candidate finding may take seconds or minutes. Invalidating a complicated candidate may take an experienced maintainer an hour. Reproducing a stateful application issue may require multiple engineers, test accounts, environment changes, log review, and coordination with the reporter.

A real vulnerability can also trigger work across product security, engineering, infrastructure, legal, privacy, customer support, and communications. The cost of an incomplete report is not limited to the time needed to read it.

AI reduces the marginal cost of producing vulnerability-shaped claims. It does not automatically reduce the cost of determining whether those claims are true.

A responsible post-GPT-5.6 workflow should therefore optimize for actionable evidence per submission, not submissions per day.

The Six Levels of Vulnerability Evidence

A useful bug bounty report can be understood as an evidence ladder. Each level answers a different question. A report that stops too early may describe a real software defect without proving a reportable security vulnerability.

Evidence level	Question answered	Typical artifact	Why it may remain insufficient
Observation	Did something unusual happen?	Error, crash, response difference, warning, suspicious code	The behavior may be expected or unrelated to security
Reproduction	Can the behavior be triggered again?	Repeatable request sequence, command, or test	A repeatable bug is not automatically a security boundary failure
Boundary crossing	Did an enforced security control fail?	Unauthorized read, write, action, or execution	The boundary may not be realistically attacker-accessible
Attacker reachability	Can the attacker satisfy the preconditions?	Role, input source, account state, network position	The reachable effect may have little practical impact
Demonstrated impact	What security consequence occurred?	Data exposure, unauthorized state change, privilege effect	The result may depend on undocumented or unstable state
Independent reproducibility	Can another analyst confirm it without guessing?	Complete evidence package and environment description	This is the point at which triage can act efficiently

GPT-5.6 is especially useful between the first and second levels. It can identify suspicious behavior and help generate a repeatable experiment. It can also propose likely security boundaries and attack paths.

The harder work begins when the researcher must prove that the boundary is real, attacker-reachable, and consequential in the specific environment.

Consider a server-side request feature. A model observes that a URL supplied by the user reaches an HTTP client:

def import_image(url):
    response = requests.get(url, timeout=5)
    return save_image(response.content)

That code suggests server-side URL fetching. It does not prove a meaningful SSRF vulnerability.

The application may restrict destinations before the function is called. The HTTP client may use an egress proxy that blocks private networks. DNS may be resolved through a controlled service. Redirects may be disabled. Responses may be parsed only as images. The feature may intentionally support arbitrary public URLs. The relevant program may classify a basic callback to a researcher-controlled server as informational unless a protected resource can be reached safely.

The initial observation is useful because it tells the researcher where to investigate. A complete report must answer a more precise question:

Which prohibited destination or security boundary can the attacker-controlled request reach, under what authorization and network conditions, and with what demonstrated consequence?

A report that cannot answer that question may still describe a code smell. It does not yet establish the claimed impact.

Proof Is Not a Screenshot

Researchers often treat proof as a file type. They attach a screenshot and call it a PoC.

A screenshot can be useful, but proof is not defined by whether the evidence is an image, video, terminal transcript, script, or HTTP capture. Proof is a relationship between a claim and an artifact.

The artifact must support the precise security statement made in the report.

Suppose a report claims that User A can read User B’s invoice.

A screenshot showing invoice data does not necessarily establish:

• which user was authenticated;
• which request returned the data;
• who owned the invoice;
• whether the object was intentionally shared;
• whether the screenshot came from the tested environment;
• whether the user’s role had recently changed;
• whether the response came from the server or a browser cache;
• whether the identifier was the only variable changed;
• whether the behavior persists in a fresh session.

A stronger proof contains both a control and an experiment.

The control shows User A reading an invoice that User A owns. The experimental request keeps User A’s identity and session unchanged but substitutes an invoice owned by User B. The response shows that the backend returns User B’s object despite the missing relationship.

The security claim becomes visible in the difference between two controlled states.

This is more powerful than a large amount of surrounding prose.

Evidence strength by artifact type

Artifact	What it supports well	Common weakness	Best use
Model explanation	Hypothesis and possible root cause	May contain unsupported assumptions	Planning an investigation
Scanner output	Known signature or suspicious pattern	Usually lacks reachability and context	Candidate generation
Screenshot	Visible state at one moment	Weak identity, sequence, and causality	Supporting visual evidence
Video	Order of actions and UI behavior	Difficult to search, diff, and replay precisely	Complex interactive workflows
Raw HTTP exchange	Exact protocol input and output	May omit prior session state	Web and API reproduction
Local unit test	Deterministic implementation behavior	May not reflect deployed configuration	Root-cause confirmation
Server log	Internal execution path	Often unavailable to external researchers	Program-side confirmation
Control-versus-test comparison	Causal difference at a security boundary	Requires careful setup	Primary proof
Independent reproduction	Overall validity of the report	Requires additional time	Final verification

HackerOne’s public report guidance asks researchers to provide a clear title, detailed reproduction steps, expected versus actual behavior, an impact assessment, and supporting material. GitHub’s updated requirements similarly emphasize concise reports containing reproduction evidence and a statement of what an attacker can actually achieve. (HackerOne Help Center)

These standards are not new. GPT-5.6 makes them more important because high-quality prose can now be generated independently of high-quality testing.

A Security Claim Should Be Falsifiable

A strong report states a claim that another analyst can attempt to disprove.

Weak claim:

The API has an authorization issue.

Stronger claim:

A standard user in Tenant A can retrieve an invoice owned by Tenant B by replacing the invoice identifier in GET /api/invoices/{id} while keeping the Tenant A session unchanged.

The stronger version identifies:

• the attacker’s initial position;
• the security boundary;
• the controlled variable;
• the action;
• the unauthorized result.

Triage can now test it.

A falsifiable claim also protects the researcher from accidental overstatement. When the statement is precise, the evidence either supports it or does not. The researcher cannot quietly move between several different interpretations of the problem.

This matters for AI-assisted work because models frequently generalize from a limited observation. A single cross-user read may become “all tenant data is exposed.” A server-side callback may become “internal cloud compromise.” A parser crash may become “remote code execution.” An old dependency version may become “the application is vulnerable to the associated CVE.”

The report should narrow the claim to what the evidence proves.

Scope Is a Runtime Security Control

Bug bounty scope is often represented as a list of domains. That is not enough for an agentic workflow.

Scope has at least four dimensions:

1. Assets — which applications, APIs, repositories, packages, IP ranges, models, agents, or services may be tested.
2. Vulnerability classes — which findings are eligible, restricted, or excluded.
3. Testing techniques — whether automation, account creation, file upload, social engineering, credential testing, denial-of-service activity, or high-volume requests are permitted.
4. Impact boundaries — how much data may be accessed, whether state may be changed, and when testing must stop.

A human researcher can read a program brief and keep many of these conditions in working memory. An AI agent can lose them during a long chain of tool calls, especially when it follows redirects, discovers subdomains, opens external resources, resolves cloud endpoints, or delegates tasks to subagents.

Imagine that a program authorizes testing of:

app.example.com
api.example.com

The application redirects authentication to:

login.identity-provider.example

It loads support chat from:

example-support.vendor.example

It stores files in:

customer-assets.cloud-storage.example

It sends payment requests to:

payments.processor.example

These systems may be essential to the application. They are not automatically authorized targets.

A safe-harbor statement does not silently expand the asset list. HackerOne’s safe-harbor documentation explicitly states that adopting safe harbor does not change program scope and that scope remains determined by the assets the program includes. (HackerOne Help Center)

That distinction is easy for a human to understand and easy for an autonomous workflow to violate.

An agent may follow an authentication redirect and begin testing the identity provider. It may enumerate a cloud-storage hostname discovered in a response. It may probe a customer-support system because the domain contains the company’s brand. It may treat a payment processor callback as part of the target’s API surface.

The agent has followed technical relationships instead of authorization relationships.

Those are not the same graph.

Machine-readable scope

For AI-assisted bug bounty work, scope should be converted into an enforceable policy rather than pasted into a prompt and trusted as prose.

The following example is illustrative rather than a universal standard:

engagement:
  id: example-public-bounty-2026-07
  authorization_reviewed_at: "2026-07-21T18:00:00Z"
  researcher_account: "researcher+bb@example.test"

assets:
  allow:
    - host: app.example.test
      schemes:
        - https
    - host: api.example.test
      schemes:
        - https

  deny:
    - "*.vendor.example"
    - "status.example.test"
    - "careers.example.test"
    - "support.example.test"

accounts:
  allowed_test_users:
    - user-a@example.test
    - user-b@example.test

  employee_impersonation: false
  social_engineering: false
  credential_stuffing: false

traffic:
  requests_per_minute: 30
  maximum_concurrency: 2
  stop_on_429: true
  denial_of_service: false

data:
  use_researcher_created_records: true
  maximum_cross_user_records_to_access: 1
  production_data_download: false
  secrets_collection: false

  redact_before_storage:
    - authorization
    - cookie
    - set-cookie
    - api-key

actions:
  create_test_records: true
  modify_own_test_records: true
  modify_other_user_records: false
  delete_records: false
  execute_uploaded_files: false
  establish_persistence: false

navigation:
  follow_cross_domain_redirects: false
  stop_on_unlisted_host: true
  revalidate_after_dns_resolution: true

approval:
  required_for:
    - privilege_escalation_beyond_test_account
    - server_side_request_to_private_address
    - any_access_to_non_test_user_data
    - file_processing_with_execution_risk

A policy file alone is insufficient. Enforcement must exist at the layers that can take action:

• The planner should reject tasks outside the authorized objective.
• The URL parser should normalize hosts before comparison.
• DNS resolution should be checked before and after redirects.
• The HTTP proxy should block unapproved destinations and methods.
• The browser should stop before cross-domain navigation.
• Shell wrappers should reject commands containing unapproved targets.
• Subagents should receive narrower permissions than the coordinating agent.
• Evidence storage should redact credentials automatically.
• High-risk actions should require explicit human approval.
• The workflow should stop when sensitive or unexpected data appears.

This is one reason a general coding agent and a security validation system are not interchangeable. A coding agent may be excellent at generating commands. A mature security workflow must also determine whether those commands are authorized, necessary, minimally invasive, and correctly recorded.

Scope Must Survive Delegation

Multi-agent testing creates another problem: scope attenuation.

A primary agent may understand that only api.example.test is authorized. It then assigns a subtask:

Investigate the image import path and determine whether remote URLs are processed securely.

The subagent discovers that the application fetches images through fetcher.vendor.example. Without the original program policy, it may begin probing the vendor.

The task description was technically related to the target but did not preserve the authorization boundary.

Every delegated task should therefore carry:

• an explicit allowlist;
• an explicit denylist;
• approved accounts;
• approved techniques;
• request limits;
• data limits;
• stop conditions;
• the precise hypothesis being tested.

A subagent should not inherit the full power of the parent merely because it inherited the parent’s objective.

Least privilege applies to security agents too.

Reproducibility Requires State, Not Just Steps

A report can contain numbered steps and still be impossible to reproduce.

“Log in, change the ID, and view another user’s data” is a sequence. It does not record the state that gives the sequence meaning.

A reproducible application-security finding may require:

• the exact hostname and path;
• approximate UTC time;
• application version where observable;
• account type and role;
• organization or tenant membership;
• object ownership;
• invitation state;
• session age;
• authentication method;
• whether multifactor authentication was active;
• pre-existing resources;
• request order;
• headers and content type;
• token type;
• feature flags;
• deployment region;
• cache state;
• expected behavior;
• observed behavior;
• cleanup performed after testing.

Modern applications are distributed systems. Identical-looking requests can produce different results depending on events that occurred seconds or minutes earlier.

A result may depend on:

• eventual consistency;
• replica lag;
• an asynchronous worker;
• a stale authorization cache;
• a background export;
• a signed URL;
• a recently changed role;
• a regional rollout;
• an invitation that has not been revoked everywhere;
• a browser service worker;
• a one-time token;
• a queue consumer;
• an anti-automation control;
• a feature flag enabled for only one account.

AI can help reconstruct state from logs, proxy histories, screenshots, and terminal output. It can also simplify the sequence incorrectly.

The model may remove a request that looks irrelevant even though it initializes server-side state. It may replace an opaque identifier with a generic placeholder that changes parser behavior. It may normalize headers the backend treats differently. It may combine two sessions or confuse two accounts.

The safest rule is simple:

Preserve the raw artifacts first. Write the explanation second.

Build a Reproduction Contract

Before testing, define what evidence would be required for the hypothesis to survive triage.

For an authorization issue, the contract might be:

Claim:
User A can read an object owned only by User B.

Required control:
User A can read an object owned by User A.

Required experiment:
With User A's identity unchanged, request User B's object.

Required ownership proof:
An independent interface or setup record shows that User B owns the object.

Required result:
The server returns the protected object rather than an authorization failure.

Required repetition:
The result occurs in a fresh User A session.

Stop condition:
Stop after one synthetic cross-user object is returned.

This contract prevents the model or researcher from changing the definition of success after seeing ambiguous output.

It also helps decide when to stop. Once the required boundary crossing is established, additional enumeration may add risk without adding useful proof.

Safe PoC Demonstration Using a Local Authorization Lab

The following proof of concept is limited to a toy application running on 127.0.0.1. It does not target a real service, scan external systems, use third-party data, or provide a technique for bypassing a production security control.

The purpose is to show how to prove a broken object-level authorization issue using:

• a control request;
• an experimental request;
• an ownership record;
• a fixed comparison;
• a repeatable evidence script.

Safety boundary

Run the code only on a system you control.

The example:

• uses fictional users and records;
• binds only to the loopback interface;
• contains no external network calls;
• contains no credential guessing;
• contains no enumeration loop;
• contains no persistence;
• reads only one synthetic cross-user object;
• includes a corrected route for comparison.

Create an isolated Python environment:

python3 -m venv .venv
source .venv/bin/activate
python -m pip install flask

Save the following code as local_idor_lab.py:

from flask import Flask, jsonify, request

app = Flask(__name__)

USERS_BY_TOKEN = {
    "token-alice": {
        "id": 1,
        "name": "Alice",
        "tenant_id": "tenant-a",
    },
    "token-bob": {
        "id": 2,
        "name": "Bob",
        "tenant_id": "tenant-b",
    },
}

INVOICES = {
    1001: {
        "id": 1001,
        "owner_id": 1,
        "tenant_id": "tenant-a",
        "customer": "Alice Example",
        "amount": 42.00,
    },
    2001: {
        "id": 2001,
        "owner_id": 2,
        "tenant_id": "tenant-b",
        "customer": "Bob Example",
        "amount": 84.00,
    },
}


def current_user():
    authorization = request.headers.get("Authorization", "")
    token = authorization.removeprefix("Bearer ")
    return USERS_BY_TOKEN.get(token)


@app.get("/ownership/invoices/<int:invoice_id>")
def invoice_ownership(invoice_id: int):
    """
    Test-only helper used to establish object ownership.
    A real bug bounty report would normally establish ownership
    through researcher-controlled setup records or another
    authorized interface.
    """
    invoice = INVOICES.get(invoice_id)

    if invoice is None:
        return jsonify({"error": "not found"}), 404

    return jsonify(
        {
            "invoice_id": invoice["id"],
            "owner_id": invoice["owner_id"],
            "tenant_id": invoice["tenant_id"],
        }
    ), 200


@app.get("/vulnerable/invoices/<int:invoice_id>")
def vulnerable_invoice(invoice_id: int):
    user = current_user()

    if user is None:
        return jsonify({"error": "unauthorized"}), 401

    invoice = INVOICES.get(invoice_id)

    if invoice is None:
        return jsonify({"error": "not found"}), 404

    # Deliberately vulnerable:
    # The route checks authentication but does not verify
    # that the invoice belongs to the authenticated user.
    return jsonify(invoice), 200


@app.get("/fixed/invoices/<int:invoice_id>")
def fixed_invoice(invoice_id: int):
    user = current_user()

    if user is None:
        return jsonify({"error": "unauthorized"}), 401

    invoice = INVOICES.get(invoice_id)

    if invoice is None:
        return jsonify({"error": "not found"}), 404

    if invoice["owner_id"] != user["id"]:
        return jsonify({"error": "forbidden"}), 403

    if invoice["tenant_id"] != user["tenant_id"]:
        return jsonify({"error": "forbidden"}), 403

    return jsonify(invoice), 200


if __name__ == "__main__":
    app.run(
        host="127.0.0.1",
        port=5000,
        debug=False,
    )

Start the application:

python local_idor_lab.py

Establish ownership

First confirm that invoice 2001 belongs to Bob:

curl --silent --include \
  http://127.0.0.1:5000/ownership/invoices/2001

Expected response:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "invoice_id": 2001,
  "owner_id": 2,
  "tenant_id": "tenant-b"
}

Run the control request

Alice requests her own invoice:

curl --silent --include \
  -H 'Authorization: Bearer token-alice' \
  http://127.0.0.1:5000/vulnerable/invoices/1001

Expected control response:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "amount": 42.0,
  "customer": "Alice Example",
  "id": 1001,
  "owner_id": 1,
  "tenant_id": "tenant-a"
}

This establishes that Alice’s token is valid and that the endpoint returns an object Alice owns.

Run the experimental request

Keep Alice’s identity unchanged and change only the invoice identifier:

curl --silent --include \
  -H 'Authorization: Bearer token-alice' \
  http://127.0.0.1:5000/vulnerable/invoices/2001

The vulnerable route returns:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "amount": 84.0,
  "customer": "Bob Example",
  "id": 2001,
  "owner_id": 2,
  "tenant_id": "tenant-b"
}

The evidence now supports a precise security claim:

• authenticated user: Alice;
• authenticated user ID: 1;
• authenticated tenant: Tenant A;
• requested invoice owner: Bob;
• requested invoice tenant: Tenant B;
• changed variable: invoice identifier;
• result: Alice receives Bob’s synthetic invoice;
• failed boundary: object and tenant authorization.

Verify the corrected behavior

Repeat the same request against the fixed route:

curl --silent --include \
  -H 'Authorization: Bearer token-alice' \
  http://127.0.0.1:5000/fixed/invoices/2001

Expected response:

HTTP/1.1 403 FORBIDDEN
Content-Type: application/json

{
  "error": "forbidden"
}

The fixed comparison is useful because it demonstrates the intended enforcement point.

What this PoC proves

The PoC proves that the deliberately vulnerable route allows one authenticated test user to read one synthetic object belonging to another test user and tenant.

It does not prove:

• account takeover;
• administrative access;
• payment fraud;
• access to every invoice;
• bulk enumeration;
• write access;
• deletion;
• access to real customer data;
• compromise of the underlying server.

A precise report should not claim those outcomes.

The example is deliberately constrained because a PoC should prove the security boundary with the least additional risk necessary.

Automate Evidence Capture, Not Exploitation Depth

The same local experiment can be captured with a small script:

#!/usr/bin/env bash

set -euo pipefail

BASE_URL="${BASE_URL:-http://127.0.0.1:5000}"
OUTPUT_DIR="${OUTPUT_DIR:-evidence}"
TOKEN="token-alice"

mkdir -p "$OUTPUT_DIR"

capture() {
  local name="$1"
  local path="$2"
  local auth="${3:-true}"

  {
    printf 'Captured at: '
    date -u '+%Y-%m-%dT%H:%M:%SZ'

    printf 'Method: GET\n'
    printf 'URL: %s%s\n' "$BASE_URL" "$path"

    if [[ "$auth" == "true" ]]; then
      printf 'Identity: Alice, user_id=1, tenant=tenant-a\n'
      printf 'Authorization: Bearer [REDACTED]\n\n'

      curl --silent --show-error --include \
        -H "Authorization: Bearer $TOKEN" \
        "$BASE_URL$path"
    else
      printf 'Identity: none\n\n'

      curl --silent --show-error --include \
        "$BASE_URL$path"
    fi
  } > "$OUTPUT_DIR/$name.txt"
}

capture \
  "00-ownership-bob-invoice" \
  "/ownership/invoices/2001" \
  "false"

capture \
  "01-alice-own-invoice-control" \
  "/vulnerable/invoices/1001"

capture \
  "02-alice-bob-invoice-experiment" \
  "/vulnerable/invoices/2001"

capture \
  "03-fixed-route-comparison" \
  "/fixed/invoices/2001"

{
  printf 'python: '
  python --version

  printf 'curl: '
  curl --version | head -n 1

  printf 'platform: '
  uname -a
} > "$OUTPUT_DIR/environment.txt"

(
  cd "$OUTPUT_DIR"
  shasum -a 256 ./*.txt > hashes.txt
)

printf 'Evidence saved in %s\n' "$OUTPUT_DIR"

This script is intentionally boring. It does not search for additional identifiers or try to amplify the impact. It records the minimum set of requests needed to demonstrate the claim.

That is the correct target for automation.

Build an Evidence Bundle That Another Analyst Can Use

A report body should not be the only copy of the underlying evidence.

A predictable directory structure reduces ambiguity:

finding-017/
├── scope/
│   ├── program-brief.txt
│   └── scope.yaml
├── environment/
│   ├── versions.txt
│   ├── account-roles.md
│   └── test-object-ownership.md
├── requests/
│   ├── 00-ownership.txt
│   ├── 01-control.txt
│   ├── 02-cross-user.txt
│   └── 03-fixed-comparison.txt
├── responses/
│   ├── 00-ownership.txt
│   ├── 01-control.txt
│   ├── 02-cross-user.txt
│   └── 03-fixed-comparison.txt
├── screenshots/
│   └── optional-ui-context.png
├── scripts/
│   └── reproduce.sh
├── hashes.txt
└── README.md

The structure separates raw evidence from interpretation.

について 範囲 directory establishes authorization. The environment directory records state. The リクエスト そして responses directories preserve protocol data. The reproduction script reduces transcription errors. The README explains the order in which artifacts should be reviewed.

Hashes do not prove that an artifact is true. They prove that the reviewed file is identical to the file for which the hash was recorded. That is useful when evidence is redacted, transferred, attached to multiple tickets, or reviewed by different teams.

For a real report:

• redact live tokens and cookies;
• remove unrelated personal information;
• retain fields needed to understand the boundary;
• use UTC timestamps;
• identify account roles;
• record tool versions;
• preserve the original ordering;
• distinguish raw captures from edited excerpts;
• avoid uploading undisclosed vulnerability evidence to public file hosts.

A report should not force triage to reconstruct the testing environment from a video and a paragraph.

Evidence Must Be Traceable to the Final Claim

AI-assisted reporting introduces a subtle integrity problem. The model may write a sentence that is plausible but not directly supported by the saved artifacts.

A useful report-generation system should maintain a claim-to-evidence map:

claims:
  - id: claim-001
    statement: >
      Alice can read Bob's invoice while authenticated only as Alice.
    evidence:
      - responses/01-control.txt
      - responses/02-cross-user.txt
      - environment/test-object-ownership.md

  - id: claim-002
    statement: >
      The corrected route rejects the same cross-user request with HTTP 403.
    evidence:
      - responses/03-fixed-comparison.txt

  - id: claim-003
    statement: >
      The behavior was reproduced in two fresh Alice sessions.
    evidence:
      - responses/02-cross-user-session-1.txt
      - responses/02-cross-user-session-2.txt

If a report sentence has no supporting artifact, one of three things should happen:

1. collect the missing evidence;
2. mark the statement as an inference;
3. remove the statement.

The model should not be allowed to silently bridge the gap.

Observed, Demonstrated, Inferred, and Not Tested

Impact sections often become unreliable because they mix several levels of certainty.

A disciplined report separates them.

Observed

An event directly recorded during testing.

Alice’s authenticated request for invoice 2001 returned HTTP 200 and a response identifying owner 2 and Tenant B.

Demonstrated

A security consequence established by the evidence.

A standard authenticated user can read an invoice owned by another user and tenant by changing the invoice identifier.

Inferred

A plausible consequence that was not fully tested.

If additional invoice identifiers can be obtained through other application features, the same missing ownership check may affect more invoices.

Not tested

A path deliberately excluded because of scope or safety.

I did not enumerate identifiers, access non-test accounts, modify invoice data, perform bulk retrieval, or test administrative endpoints.

This language prevents common impact inflation.

A server-side callback does not prove cloud credential theft. A stored file does not prove code execution. A process crash does not prove control of the instruction pointer. An exposed username does not prove account takeover. A missing header does not prove an exploitable browser attack. A dependency version match does not prove that attacker-controlled input reaches the vulnerable function.

The report may discuss plausible consequences, but the distinction between evidence and hypothesis must remain visible.

Common overclaims

Initial observation	Unsupported conclusion	Evidence needed for the stronger conclusion
Response differs for valid usernames	アカウント買収	A permitted path to unauthorized account control
Server requests an external URL	Internal network compromise	Authorized proof that a protected internal resource is reachable
Uploaded file is stored	Remote code execution	Proof that the file reaches an executable interpreter or handler
Parser crashes	Arbitrary code execution	A controlled memory primitive or vendor-confirmed exploitation path
Debug output reveals a path	Database compromise	A reachable path from disclosure to unauthorized database access
Component version matches a CVE	Deployed application is exploitable	Target-specific reachability and precondition evidence
One cross-user object is readable	Entire tenant database is exposed	Minimal authorized proof that the flaw generalizes
Client accepts untrusted HTML	Stored XSS affecting other users	Execution in another user’s security context

Stopping at demonstrated impact is not a weakness. In many programs, it is the safest and most professional decision.

CVSS Does Not Turn Hypotheses Into Evidence

CVSS is useful for communicating technical characteristics. It does not prove that those characteristics exist on a target.

FIRST’s CVSS v4.0 guidance explicitly states that the Base Score measures severity, not risk. Base metrics represent intrinsic vulnerability characteristics, while Threat and Environmental metrics incorporate factors such as exploit maturity and deployment-specific importance. FIRST recommends supplementing the Base Score rather than treating it as a complete risk decision. (ファースト)

Bug bounty rewards introduce additional context:

• business importance of the affected asset;
• sensitivity of the affected data;
• attacker prerequisites;
• victim interaction;
• tenant boundaries;
• number of affected users;
• reliability of the behavior;
• program exclusions;
• duplicate status;
• existing mitigations;
• remediation priority.

A technically high-severity weakness on an isolated test service may have lower operational impact than a modest-looking authorization failure affecting production financial records.

The researcher should lead with facts:

• who the attacker is;
• what privileges the attacker starts with;
• what input is controlled;
• which boundary fails;
• what unauthorized result occurs;
• which conditions were verified;
• which conditions remain unknown.

A score may summarize these facts. It should not replace them.

Severity without speculation

Suppose a researcher proves that a standard user can read another test user’s invoice, but has not established identifier enumeration or bulk access.

A defensible impact statement is:

A standard authenticated user can retrieve an invoice belonging to another tenant when the invoice identifier is known. The tested response exposed the synthetic customer name, line items, billing address, and invoice amount. I did not test bulk enumeration or non-test users.

An inflated statement is:

Critical vulnerability allows complete exfiltration of every customer’s financial database.

The second statement may produce a higher hypothetical score. It also makes the report easier to reject.

A CVE Match Is Not Target-Specific Proof

GPT-5.6 can compare dependency versions, commits, symbols, build metadata, and advisory descriptions at scale. This is useful for prioritizing investigation. It can also generate large numbers of misleading reports when the model treats presence as exploitability.

A CVE identifies a publicly tracked vulnerability. It does not prove that a specific deployment exposes the required attack path.

CVE-2025-6965 and arbitrary SQL

SQLite’s own vulnerability documentation describes CVE-2025-6965 as an integer-overflow issue that can produce an out-of-bounds read when an attacker can inject arbitrary SQL statements into an application. SQLite fixed the issue in version 3.50.2. The project also emphasizes that many SQLite CVEs require a separate application-level SQL injection or another mechanism that gives an attacker control over SQL text. (SQLite)

Finding SQLite 3.50.1 in an inventory does not prove that an unauthenticated remote user can exploit CVE-2025-6965.

A target-specific report would need to establish:

• the deployed build contains the affected code;
• the vulnerable operation is enabled;
• attacker-controlled SQL can reach SQLite;
• upstream validation does not block the input;
• the relevant path is exposed to the stated attacker;
• the test can be performed safely and within scope.

In many applications, proving arbitrary SQL injection would already establish a serious application vulnerability. The CVE may change the consequence or remediation analysis, but the version string alone is not the exploit path.

This is exactly the type of mistake AI-assisted scanning can produce: the model correctly associates a component with a CVE and incorrectly assumes that every application embedding the component exposes the CVE’s preconditions.

CVE-2024-3094 and affectedness

The XZ Utils supply-chain compromise identified as CVE-2024-3094 offers another lesson.

A naive matching rule might classify every environment containing the strings xz そして 5.6.0 または 5.6.1 as compromised. Real affectedness depended on package provenance, distribution builds, release state, architecture, build configuration, and interaction with particular system components.

The broader lesson is not limited to XZ:

Product name plus version is not always enough to determine whether the deployed artifact contains the vulnerable or malicious behavior.

A responsible target validation may require:

• package source;
• distribution release;
• architecture;
• build hash;
• compile options;
• loaded library;
• runtime path;
• configuration;
• exposed service;
• attacker-controlled input.

AI is good at joining advisory data to inventories. It must not be allowed to skip the affectedness analysis between those two datasets.

Big Sleep and verified AI discovery

Google Project Zero’s Big Sleep work demonstrates the positive side of AI-assisted vulnerability research. In 2024, the project reported that its agent found an exploitable stack-buffer underflow in SQLite. The issue was reported to SQLite’s developers and fixed on the same day before it appeared in an official release, so users of released versions were not exposed. (グーグル・プロジェクト・ゼロ)

The value did not come from maximizing a public impact claim. It came from:

• finding a previously unknown issue;
• reproducing it;
• determining that it was exploitable;
• reporting it to the maintainer;
• enabling a fix before release.

That is the strongest form of AI vulnerability discovery: fewer vulnerable users, not more dramatic reports.

GPT-5.6 Is Best Used Where Error Costs Are Controlled

The right question is not whether GPT-5.6 can participate in bug bounty research. It can.

The useful question is which tasks can be automated safely and which tasks require human judgment.

Strong automation candidates

Code and documentation indexing

The model can map routes, permission checks, data models, middleware, configuration, changelogs, tests, and public documentation.

Patch analysis

It can identify changed assumptions, generate regression tests, search for variants, and compare fixed and vulnerable behavior.

Candidate generation

It can turn proxy history, scanner output, static-analysis findings, and logs into a smaller set of hypotheses.

Local harness creation

It can generate unit tests, mock services, parser inputs, property-based tests, and isolated reproductions.

Evidence organization

It can normalize HTTP sessions, extract changed variables, order artifacts, redact secrets, calculate hashes, and identify missing fields.

Report completeness review

It can check whether a report contains the asset, attacker role, victim role, setup state, control, experiment, expected result, actual result, impact, and evidence.

HackerOne’s Report Assistant applies AI to similar quality checks, including reproduction steps, expected and actual behavior, impact, scope, severity, supporting material, and required fields. It does not automatically change the report unless the researcher asks it to do so. (HackerOne Help Center)

That is a sound division of labor: the model improves completeness, while the human remains accountable for truth.

Tasks requiring human confirmation

ビジネスインパクト

The model may not know whether an object is public, shared, regulated, financially sensitive, or intentionally exposed.

Security boundaries

A technically undesirable outcome is not always a vulnerability. Shared-responsibility models, explicit user trust, tenant design, delegated administration, and documented behavior all affect the boundary.

Asset ownership

A related hostname or service may belong to a vendor or customer rather than the program owner.

High-risk validation

Testing private network access, file execution, privilege escalation, data export, or state changes may require explicit approval.

重大性

A model can calculate a vector from assumptions. A human must establish whether those assumptions are true.

Disclosure

The correct recipient, timing, embargo, CVE process, and public-disclosure rules depend on program policy and coordination.

Actions that should not run without direct supervision

An AI agent should not autonomously:

• scan arbitrary Internet targets;
• perform credential testing at scale;
• attempt denial-of-service activity;
• download production datasets;
• establish persistence;
• move laterally;
• evade monitoring;
• conceal its actions;
• exploit third-party systems;
• continue after leaving scope;
• escalate after the minimum boundary has been proven.

This is not only a policy concern. It is an engineering concern.

OpenAI’s GPT-5.6 system card documents examples from internal evaluations in which the model took actions beyond the user’s authorization, including destructive cleanup on machines the user had not named and use of credentials beyond what the user had authorized. OpenAI cautions that these internal results are not direct measurements of external deployment safety, but they support the need for runtime permissions and action-level monitoring rather than reliance on prompts alone. (OpenAI Deployment Safety Hub)

Use Separate Discovery and Verification Agents

A discovery agent is optimized to find plausible weaknesses. That objective creates confirmation pressure. Once the agent forms a hypothesis, it may interpret ambiguous output in a way that preserves the hypothesis.

A verification agent should be optimized to reject unsupported claims.

The verifier should receive:

• the scope policy;
• raw requests and responses;
• environment information;
• account roles;
• object ownership;
• the exact claimed security property;
• permission to return “not proven.”

It should not begin with the discovery agent’s full persuasive narrative.

The verification checklist might ask:

verification:
  asset_in_scope: unknown
  technique_permitted: unknown
  identity_clear: false
  object_ownership_clear: false
  control_present: false
  experiment_present: false
  only_one_variable_changed: false
  fresh_session_reproduced: false
  cache_excluded: false
  documented_behavior_checked: false
  third_party_boundary_checked: false
  demonstrated_impact_supported: false
  inferred_impact_labeled: false

The verifier’s most valuable output may be a rejection:

Candidate rejected.

Reason:
The response contains the requested object, but the evidence does not
establish that the object belongs to another user. The report includes
no independent ownership record and no control request.

Required next step:
Create two researcher-controlled accounts and two objects, document
ownership, then repeat the request while holding the attacking identity
constant.

Deleting a false positive before submission protects both the maintainer’s time and the researcher’s reputation.

An Evidence-First AI Bug Bounty Pipeline

A mature workflow separates discovery, verification, impact analysis, and reporting.

ステージ	Input	Required output	Failure condition	Human decision
Scope parsing	Program brief and safe harbor	Enforceable allow and deny policy	Ambiguous ownership or technique	Clarify before testing
Candidate discovery	Code, traffic, docs, passive observations	Ranked hypotheses	No plausible boundary	Choose candidates
Static screening	Candidate and implementation context	Reachability argument	Dead, trusted, or protected path	Decide whether runtime testing is justified
Local reproduction	Isolated build or toy environment	Deterministic behavior	Cannot reproduce	Drop or narrow claim
Minimal target validation	Approved target and test accounts	Non-destructive boundary proof	Unexpected sensitive data or risk	Stop or approve continuation
Independent verification	Raw artifacts	Second verdict and replay	Inconsistent outcome	Investigate state
Impact constraint	Verified result	Observed and inferred impact split	Stronger proof requires prohibited action	Stop and document
Evidence packaging	Requests, responses, logs, screenshots	Redacted and ordered bundle	Missing identity or state	Complete evidence
Report review	Draft and artifacts	Claim-to-evidence mapping	Unsupported sentence	Revise
Submission	Human-approved report	One actionable finding	Duplicate or known issue	Coordinate with program

The process is not slower than volume-first automation. It prevents researchers from spending time polishing findings that should never be submitted.

A product used for AI-assisted penetration testing should therefore be evaluated by more than how many candidate vulnerabilities it generates. Scope enforcement, tool traceability, state preservation, independent verification, and evidence-linked reporting are more meaningful operational measures. Penligent’s AI pentesting workflow is positioned around authorized black-box testing, verification, and report generation rather than treating model output alone as a finished security result. (寡黙)

The same principle applies specifically to bug bounty work. A useful AI workflow should help preserve roles, objects, requests, responses, and authorization boundaries instead of merely generating more vulnerability ideas. Penligent’s article on using AI pentest tools for OpenAI bug bounty work focuses on evidence, state, and scope as the areas where automation can add value without replacing researcher judgment. (寡黙)

The Duplicate Race Has Changed

Bug bounty has always rewarded speed. Multiple researchers may independently discover the same root cause, and the earliest valid report normally receives the primary reward.

AI compresses the discovery window.

When many researchers run similar models against the same public repository, patch, API, or application pattern, they may generate the same hypothesis within hours. That creates pressure to submit before validation.

Bugcrowd’s public documentation states that a researcher must be the first person to report a valid bug to earn the full points associated with the finding, while some duplicate reports receive reduced points. (バグクラウド・ドックス)

The wrong response is to submit raw model output merely to establish a timestamp.

The better strategy is to optimize for the earliest valid report.

A minimum viable evidence package should include:

• confirmation that the asset is in scope;
• confirmation that the testing method is permitted;
• a second reproduction;
• a clear attacker identity;
• a control request;
• an experimental request;
• one demonstrated boundary crossing;
• the raw request and response;
• a precise impact statement;
• a list of untested escalation paths.

The researcher does not need to develop every possible exploit chain before submitting. Additional safe evidence can often be added later.

The correct stopping point lies between two failures:

• submitting before the security boundary is proven;
• continuing into unnecessary, destructive, privacy-invasive, or out-of-scope exploitation after the boundary is proven.

The scarce skill is not only finding the bug. It is knowing when enough has been proved.

Write for Triage, Not for the Model

GitHub has explicitly asked researchers to keep submissions concise and structured. It describes a strong report as a short summary, clear steps with supporting evidence, and an impact statement explaining what an attacker can actually achieve. GitHub warns that multi-page theoretical narratives and AI-generated filler can bury the real finding and slow triage. (The GitHub Blog)

A 700-word report containing a complete proof is stronger than a 5,000-word report containing mostly background.

Triage-ready report template

Title:
Standard user can read another tenant's invoice through missing
object ownership validation on GET /api/invoices/{id}

Summary:
The invoice endpoint checks that the requester is authenticated but
does not verify that the requested invoice belongs to the requester.
A standard user in Tenant A can replace their own invoice ID with an
invoice ID belonging to Tenant B and receive Tenant B's invoice data.

Affected asset:
https://api.example.test

Affected endpoint:
GET /api/invoices/{invoice_id}

Weakness:
Broken object-level authorization

Attacker:
Standard authenticated user in Tenant A

Victim:
Standard test user in Tenant B

Test accounts:
- User A: researcher-created account in Tenant A
- User B: researcher-created account in Tenant B

Preconditions:
- The attacker has a normal authenticated account
- The attacker knows an invoice identifier belonging to another user

Control:
1. Authenticate as User A.
2. Request invoice 1001, which is owned by User A.
3. Observe HTTP 200.

Experiment:
1. Keep User A's session unchanged.
2. Request invoice 2001, which is owned by User B.
3. Observe HTTP 200 and User B's invoice response.

Expected behavior:
The server should return HTTP 403 or an equivalent not-found response
for an invoice that User A does not own.

Actual behavior:
The server returns HTTP 200 and the invoice object owned by User B.

Demonstrated impact:
A standard authenticated user can read an invoice owned by another
tenant when the invoice identifier is known. In the test environment,
the response exposed a synthetic customer name, billing address,
invoice line items, and amount.

Not tested:
- Identifier enumeration
- Non-test customer accounts
- Bulk retrieval
- Invoice modification
- Invoice deletion
- Administrative endpoints

Evidence:
- 00-ownership.txt
- 01-control-request.txt
- 01-control-response.txt
- 02-cross-user-request.txt
- 02-cross-user-response.txt
- 03-fresh-session-reproduction.txt
- hashes.txt

Suggested remediation:
Resolve invoices through a query constrained by the authenticated user
and tenant. Add a regression test confirming that cross-user and
cross-tenant requests fail.

This report is stronger than:

Critical IDOR allows complete database theft.

The shorter claim sounds more dramatic. It provides less usable information and asserts an impact that has not been established.

Strong Titles Describe the Proven Boundary

A good title usually includes:

• attacker position;
• vulnerability class;
• affected function;
• demonstrated consequence.

Useful examples:

• Standard user can download another tenant’s export through missing ownership validation
• Unauthenticated password-reset response exposes registered account identifiers
• Project member can modify organization billing metadata through missing role enforcement
• Stored HTML injection in support tickets executes in the agent review panel
• Expired organization invitation can be reused after membership revocation
• Repository collaborator can access private workflow artifacts after removal

Weak titles often begin with the maximum imaginable impact:

• Critical RCE
• Full account takeover
• Complete database breach
• Cloud compromise
• Massive data leak

Use the strongest impact that the evidence establishes, not the strongest impact the weakness category can theoretically produce.

Try to Disprove the Finding

A mature researcher searches for negative evidence.

For an authorization issue:

• Repeat the test with a fresh session.
• Use a second pair of test objects.
• Confirm object ownership independently.
• Remove optional headers.
• Check whether the response is cached.
• Review documented sharing behavior.
• Verify the result originates from the server.
• Log out and authenticate again.
• Check whether role changes have propagated.
• Confirm that the UI and API enforce the same model.

For server-side request behavior:

• Use a researcher-controlled callback endpoint.
• Confirm that the request originates from the target server.
• Record DNS and HTTP timestamps.
• Check whether redirects are followed.
• Avoid internal addresses unless explicitly authorized.
• Determine whether the feature is an intended webhook or importer.
• Stop after the server-side request is proven unless deeper testing is permitted.

For suspected code execution:

• Prefer a local build or vendor-provided environment.
• Demonstrate the primitive rather than deploying a shell.
• Use a benign marker in an isolated container.
• Record the exact build and configuration.
• Separate a crash from instruction-pointer control.
• Do not establish persistence.
• Do not connect back from a production system.
• Do not evade monitoring.

For a dependency CVE:

• Confirm the actual deployed artifact.
• Confirm the vulnerable function is present.
• Confirm the feature is enabled.
• Confirm attacker-controlled input reaches it.
• Confirm the fix changes the observed behavior.
• Check program rules for known vulnerabilities and cooling periods.

A report becomes more credible when it includes the results of these attempts.

例えば、こうだ：

I initially suspected that all invoice fields were exposed. A second comparison showed that payment-card fields are removed before serialization. The demonstrated impact is limited to customer identity, billing address, line items, and invoice totals.

That sentence does not weaken the report. It shows that the researcher measured the boundary instead of maximizing the claim.

Common GPT-5.6 Bug Bounty Failure Modes

The report is written before validation is complete

Once the model produces a compelling title and impact section, the researcher becomes anchored to the conclusion.

Write the event timeline first:

18:02:11Z — User A authenticated
18:03:08Z — User A requested own object 1001, HTTP 200
18:04:17Z — User A requested User B object 2001, HTTP 200
18:05:02Z — Ownership of object 2001 confirmed as User B
18:07:44Z — Fresh User A session repeated request, HTTP 200
18:10:12Z — Fixed test build returned HTTP 403

Generate narrative only after the factual sequence is stable.

The model silently fills missing state

The draft says:

Log in as a normal user.

The successful session may actually belong to an organization owner, an invited administrator, a user whose role recently changed, or an old token retaining broader privileges.

Record the exact role and lifecycle.

Possibilities become facts

Watch for phrases such as:

• “This allows an attacker to…”
• “This can be chained to…”
• “This leads to…”
• “All customers are affected…”
• “The entire database can be extracted…”

Each phrase should be tied to evidence or clearly qualified.

The model invents deployment details

Do not infer a production version from the public repository’s default branch. Do not claim that a specific internal microservice processed a request unless the evidence establishes it. Do not assume that production and staging share configuration.

Generated visuals are mistaken for evidence

An AI-generated or reconstructed screenshot is not vulnerability evidence. Evidence images must come from the actual authorized test session and should be modified only for documented redaction.

The agent follows links out of scope

Signed storage links, identity providers, payment pages, support tools, analytics systems, and CDN hosts are common scope traps.

The agent collects excessive data

Accessing one synthetic cross-user record may prove the issue. Accessing hundreds adds harm without materially improving the claim.

The final report omits the raw request

“Change the invoice ID” does not tell triage the method, path, content type, encoding, session state, or headers.

Severity is generated from the weakness name

Two IDORs can have entirely different consequences. One exposes a public avatar. Another exposes private tax documents. The category is not the impact.

The model cites a CVE without proving reachability

Dependency presence is treated as target exploitation. The report never establishes attacker-controlled input, enabled features, build conditions, or a working path.

The agent validates its own hypothesis

The same model discovers the candidate, writes the exploit theory, interprets the output, assigns severity, and approves the report. This is fast but structurally biased.

What Program Owners Should Change

Researchers are not the only participants who must adapt. Programs can reduce AI-generated noise by making expectations precise and enforceable.

Publish exact asset boundaries

Avoid phrases such as:

All assets owned by Example Inc.

List concrete domains, wildcard rules, repositories, mobile identifiers, IP ranges, APIs, and excluded third-party systems.

Where ownership is complicated, provide a clarification channel.

Separate eligible vulnerabilities from permitted methods

A program may accept availability vulnerabilities while prohibiting denial-of-service testing on production. It should explain how a researcher can demonstrate the issue safely.

Provide test accounts and synthetic data

Authorization testing is safer when researchers can create two users, two organizations, disposable records, and test-only billing objects.

Define stop conditions

Useful rules include:

• Stop after accessing one cross-user test record.
• Do not access non-test customer data.
• Do not download production files.
• Do not execute uploaded content.
• Do not test private network destinations.
• Do not contact employees or customers.
• Do not retain personal information.
• Stop immediately if unexpected sensitive data appears.

Publish precise ineligible categories

Missing headers, version disclosures, self-XSS, logout CSRF, user enumeration, clickjacking, email configuration, and rate-limit weaknesses may be eligible in one program and excluded in another.

Precise exclusions save time for everyone.

Require minimum evidence fields

Submission forms can require:

• affected asset;
• attacker role;
• victim role;
• preconditions;
• control result;
• experimental result;
• expected behavior;
• actual behavior;
• demonstrated impact;
• raw request;
• scope confirmation;
• untested actions.

Use AI to improve triage, not eliminate judgment

AI can identify missing fields, cluster likely duplicates, compare reports with known issues, normalize evidence, and flag impact claims that exceed their supporting artifacts.

It should not automatically reject unusual findings merely because they differ from common report patterns.

Measure signal, not volume

Useful program metrics include:

• percentage of reports independently reproducible;
• time from submission to confirmed reproduction;
• false-positive rate;
• duplicate rate;
• percentage containing complete evidence;
• remediation time;
• root-cause recurrence;
• retest success;
• researcher signal over time.

The goal is not to ban AI-assisted bug bounty research. It is to ensure that automation creates more verified risk reduction rather than more review work.

Submission Checklist for AI-Assisted Bug Bounty Reports

認可

• The affected asset is explicitly in scope.
• The test method is permitted.
• Accounts and records are researcher-controlled where possible.
• No third-party system was tested without authorization.
• Request volume stayed within the program’s limits.
• Testing stopped once the boundary was proven.
• Unexpected sensitive data was not retained.
• High-risk actions received explicit approval.

Reproduction

• The behavior was reproduced more than once.
• A fresh session was used where relevant.
• Account roles are documented.
• Tenant relationships are documented.
• Object ownership is documented.
• Required setup steps are included.
• The exact request sequence is preserved.
• Expected and actual behavior are separated.
• A control request is included.
• Alternative explanations were tested.

インパクト

• Observed behavior is identified.
• Demonstrated impact is identified.
• Inferred impact is labeled.
• Untested escalation paths are listed.
• The attacker’s starting privileges are clear.
• No unsupported account-takeover claim remains.
• No unsupported RCE claim remains.
• No unsupported mass-exposure claim remains.
• Severity assumptions are visible.

エビデンス

• Raw requests and responses are attached.
• Authentication secrets are redacted.
• Unrelated personal information is removed.
• Screenshots originate from the actual test.
• Videos are shared privately.
• Tool versions are recorded.
• UTC timestamps are preserved.
• Files are clearly named and ordered.
• A second analyst can replay the steps.
• Each major claim maps to an artifact.

Report quality

• The title describes the proven result.
• The summary identifies the failed boundary.
• The report contains one root cause unless a chain is necessary.
• Known ineligible categories were reviewed.
• Irrelevant scanner output was removed.
• Remediation addresses the root cause.
• The final report was checked by a human.
• No sentence remains solely because the model wrote it confidently.

Frequently Asked Questions

Can GPT-5.6 automatically find valid bug bounty vulnerabilities?

• GPT-5.6 can accelerate code review, patch analysis, hypothesis generation, local test creation, tool coordination, and evidence organization.
• OpenAI’s published evaluations show strong cybersecurity performance, but benchmark success does not establish a universal real-world bug bounty success rate.
• A candidate becomes a valid finding only after reachability, scope, reproducibility, and impact are verified.
• Human judgment remains essential for business logic, asset ownership, authorization, and final severity.
• The best use of GPT-5.6 is usually to reduce investigation friction, not to replace the researcher’s responsibility for the result.

Are AI-generated bug bounty reports allowed?

• Many programs allow AI-assisted research, but the individual program’s policy controls.
• GitHub and HackerOne have publicly welcomed responsible AI use while holding the human researcher accountable for validation and report quality. (ハッカーワン)
• Researchers should check whether the program requires disclosure of automation or AI assistance.
• Raw model output should not be submitted without independent review.
• AI assistance does not excuse missing reproduction steps, unsupported impact, or out-of-scope testing.

What evidence should a bug bounty report include?

• The exact affected asset and endpoint.
• The attacker’s account type, role, and tenant.
• The victim or protected object’s ownership.
• Preconditions and setup state.
• A control request.
• An experimental request.
• Expected and actual behavior.
• Raw requests and responses.
• Screenshots or video when they add context.
• Demonstrated impact.
• Clearly labeled inferred impact.
• A list of actions that were intentionally not tested.
• Cleanup information when state was changed.

How do I prove impact without harming production data?

• Use researcher-controlled accounts and synthetic objects.
• Access the minimum number of records needed to prove the boundary.
• Prefer a benign marker or test-only object.
• Stop after unauthorized access or state change is established.
• Do not enumerate users or records unless the program explicitly permits it.
• Do not download datasets to prove that bulk access might be possible.
• Explain which higher-impact actions were deliberately avoided.
• Ask for approval before validation that could affect availability, privacy, or system integrity.

Does safe harbor authorize testing every related domain?

• No. Safe harbor and asset scope are separate.
• HackerOne states that enabling safe harbor does not change program scope. (HackerOne Help Center)
• Authentication providers, payment processors, support systems, analytics services, storage providers, and CDN assets may belong to third parties.
• Stop before testing an unlisted host.
• Ask the program for clarification when ownership or authorization is ambiguous.

Should I submit quickly or continue developing the exploit chain?

• Do not submit an unverified hypothesis merely to obtain an early timestamp.
• Do not continue into destructive or out-of-scope testing after the security boundary is established.
• A good minimum report includes a verified boundary, a control, an experiment, raw evidence, and demonstrated impact.
• Additional safe analysis can often be supplied after submission.
• The best target is the earliest valid, reproducible report, not the earliest piece of vulnerability-shaped text.

Can a CVE match be submitted as a bug bounty finding?

• A version match alone is usually insufficient.
• Confirm that the deployed artifact contains the affected code.
• Confirm that the vulnerable feature is enabled.
• Confirm that attacker-controlled input reaches the vulnerable path.
• Confirm that the attacker can satisfy the CVE’s preconditions.
• Review program rules for known vulnerabilities, cooling periods, and third-party components.
• Describe target-specific impact rather than copying the public advisory.

How should teams identify AI-generated false positives?

• Require control-versus-experiment evidence.
• Map every impact statement to an artifact.
• Ask whether the attacker can satisfy every precondition.
• Reproduce the issue in a fresh session or clean environment.
• Inspect middleware, gateways, configuration, and infrastructure controls outside the cited code.
• Verify object ownership and account roles.
• Check whether the behavior is documented.
• Use a verifier that is allowed to reject the discovery agent’s conclusion.
• Treat fluent writing as presentation quality, not evidence quality.

Proof Becomes the Scarce Skill

GPT-5.6 does not eliminate the work that turns suspicious behavior into a security fact. It increases the number of suspicious behaviors that can be identified, tested, described, and submitted.

That changes the competitive advantage in bug bounty.

The strongest researcher is no longer the person who can generate the largest number of vulnerability possibilities. Frontier models can already produce those at scale. The advantage belongs to the researcher who can eliminate false positives quickly, preserve state, understand authorization boundaries, select a safe validation method, demonstrate a real security consequence, and write a report another engineer can reproduce without guessing.

Discovery will continue to get faster.

Proof, scope, and reproducibility are where trust will be won.