AI-Assisted Bug Bounty With Manual Validation

/

AI-assisted reconnaissance organized into hypotheses that a human security researcher manually validates

By Garrett Kohlrusch | GK Data LLC

The problem with AI in security research is not that a model touched the workflow. The problem is unverified output presented as a finding.

GK Data uses custom AI agents during advanced reconnaissance and documentation. They help organize large technical surfaces, preserve research context, and turn scattered observations into testable hypotheses. They do not decide whether a vulnerability exists. Scope, reproduction, exploit validation, impact, severity, and the final report remain human responsibilities.

Where AI is genuinely useful

Reconnaissance organization

Large programs produce hostnames, JavaScript bundles, mobile routes, parameters, archived URLs, API schemas, response patterns, and notes from previous sessions. Agents can normalize and cluster that material so a researcher can see relationships that are easy to lose in raw output.

Source and workflow review

An agent can highlight candidate sinks, trust-boundary changes, role checks, state transitions, and references to hidden endpoints. Those are leads, not findings. The researcher still has to trace the real data flow and test the deployed behavior.

Hypothesis generation and prioritization

AI can help turn an observation into a list of questions: Does this identifier cross tenants? Is the mobile endpoint older than the web endpoint? Does the file preview change content type? Which role should own this object? A useful agent produces an investigation queue. It does not invent the answers.

Documentation

Once the behavior is confirmed, AI can help structure timelines, compare request and response evidence, identify missing reproduction details, and improve clarity. The final wording must still match what was actually observed.

What is never delegated

  • Authorization and scope: the researcher determines what is permitted before testing.
  • Manual reproduction: the behavior is repeated using controlled steps and identities.
  • Exploit validation: the report distinguishes a suspicious response from an unauthorized outcome.
  • Impact: demonstrated impact is separated from plausible but untested escalation.
  • Severity: business context and prerequisites are reviewed by a person.
  • Final reporting: every request, screenshot, statement, and remediation recommendation receives human review.

The GK Data validation workflow

  1. Confirm authorization. Record the program rules, target scope, prohibited techniques, rate limits, and data-handling requirements.
  2. Collect deliberately. Gather only the reconnaissance needed for the target and keep provenance for important observations.
  3. Use agents to organize, not declare. Cluster assets, surface candidate paths, and retain context without labeling speculation as vulnerability.
  4. Test manually. Use controlled accounts and the minimum data necessary to confirm an unauthorized action or security boundary failure.
  5. Preserve evidence. Save the relevant requests, responses, roles, timestamps, screenshots, and environmental conditions.
  6. Write to the proof. Describe exactly what happened, what did not happen, and what would require additional testing.
  7. Review before delivery. Reproduce the chain from the report and remove unsupported severity language, invented context, and unnecessary sensitive data.

Confidentiality comes before convenience

Private program data, credentials, session material, customer records, source code, and internal hostnames should not be sent to a model merely because doing so is convenient. The correct decision depends on the program rules, contract, data classification, model deployment, retention controls, and approved processing environment.

When those conditions do not permit AI processing, the data stays out. Local or controlled models can reduce some exposure, but they do not erase contractual restrictions or the need for access control and retention discipline.

What a credible report contains

  • a clearly identified asset and affected feature;
  • prerequisites, roles, and test conditions;
  • steps another person can reproduce;
  • the relevant request and response evidence;
  • a demonstrated security boundary failure;
  • impact limited to what the evidence supports; and
  • remediation aimed at the root cause rather than a payload string.

Two public examples show that standard in practice: the blind stored XSS file-upload case study and the NASA GLOBE Observer stored XSS case study. In each, reconnaissance and documentation supported the work; manual reproduction established the finding.

The standard is accountability

AI-assisted security research can be faster and better organized without becoming low-quality automated reporting. The dividing line is accountability. A human researcher must be able to explain the data flow, reproduce the issue, defend the impact statement, and answer for every sentence delivered to the program or client.

That same standard guides GK Data’s testing approach and Web Application and API Penetration Testing. To discuss an authorized application security engagement, contact GK Data.


Need this kind of issue found before release?

GK Data LLC provides web, API, mobile, cloud, and network testing with manual verification and remediation-focused reporting.

Previous article
Next article