Full Automation for Security Research Is Wrong — Here's What Actually Works

I could make this system fully autonomous. Remove the human review gates. Let it find vulnerabilities, validate them, and submit reports automatically.

I won’t.

Not because the technology can’t do it. Because I’ve seen what happens when researchers prioritize volume over judgment. Their acceptance rates crater. Programs add them to internal “problematic researcher” lists. Other programs notice.

That specific reputation damage—slow, invisible, cumulative—is worse than any technical failure.

Human-in-the-loop security automation requires mandatory human review for all submission decisions. Automation handles reconnaissance, testing, and validation—the tedious work where machines excel. Humans handle judgment calls: Is this finding worth reporting? Is the impact assessment accurate? Does the proof-of-concept clearly demonstrate the vulnerability? Quality over quantity, always. This oversight model aligns with the NIST AI Risk Management Framework, which treats human oversight as a core governance requirement for high-stakes AI systems.

---

Why Is Mandatory Human Review Non-Negotiable?

Even a 40 percent false positive rate after automated validation is too high for direct submission. Programs track researcher quality over time, and repeated low-quality reports create negative associations that reduce bounty amounts and increase scrutiny on future submissions. Human review catches edge cases algorithms miss and protects long-term reputation.

In part 2, I described how validation reduced false positives from 90% to 40%. That’s a huge improvement.

But 40% false positives is still unacceptable for direct submission.

If I submit 10 reports and 4 are invalid:

• Programs notice patterns of low-quality submissions
• Triage teams develop negative associations with my username
• Future reports get scrutinized more heavily
• Bounty amounts decrease for “problematic” researchers

The math doesn’t favor automation without human gates.

My system has hard rules:

Always requires human review:

• Any finding with ≥0.70 confidence
• Critical or high severity findings (any confidence)
• First submission to any new program
• Scope ambiguity detected
• Potential for dispute or pushback

Never automated:

• Report submission
• Response to program triage questions
• Scope clarification decisions
• Disclosure timing

[!WARNING] Bug bounty platforms share information. A ban from one program can affect your standing elsewhere. Programs in the same company (e.g., Google, Meta) definitely share researcher reputations internally. One careless automated submission can cascade. HackerOne and similar platforms publish explicit policies on researcher conduct and program bans.

---

What Is the Quality Over Quantity Principle?

A researcher who submits 50 reports with 40 accepted outperforms one who submits 200 with only 50 accepted. Acceptance rate compounds: programs trust careful researchers, triage their reports faster, and award higher bounties. Submitting findings you are only 60 percent confident about damages this reputation faster than not submitting at all.

Two hypothetical researchers:

Researcher A: 200 reports submitted, 50 accepted (25% acceptance rate) Researcher B: 50 reports submitted, 40 accepted (80% acceptance rate)

Who would you rather have in your program?

Researcher B, obviously. They’re careful. They understand impact. They don’t waste triage time.

My system optimizes for Researcher B’s pattern:

1. High confidence threshold (0.85+) for human review queue
2. Detailed validation before any human sees it
3. Quality evidence collection (screenshots, PoC, hashes)
4. Report templates that match program expectations
5. No “spray and pray” submissions

I hated the idea of leaving valid findings unreported. But I needed to accept that a finding I’m 60% confident about isn’t ready. Let it mature. Get more evidence. Or discard it.

The acceptance rate compounds. Programs start trusting my reports. Triage becomes faster. Bounties increase. Fewer back-and-forth questions.

---

How Does Scope Validation Prevent Disaster?

Scope validation runs before every test, checking the target domain against explicit in-scope lists, wildcard patterns, and explicit exclusions from the program definition. Out-of-scope testing can trigger legal action, platform suspension, and permanent bans. Ambiguous cases never proceed automatically — they pause and wait for human judgment rather than risk the consequences.

Every bug bounty program has scope—what you’re allowed to test, what’s off-limits.

Out-of-scope testing can result in:

• Legal action (yes, really)
• Permanent program ban
• Platform suspension (OWASP testing methodology defines scope boundaries explicitly)
• Criminal investigation (in extreme cases)

Automation makes mistakes faster. Without scope validation, the system could hammer a production database that’s explicitly out of scope. By the time I notice, the damage is done.

My scope validation runs before every test:

async function validateScope(target: Target, program: Program): Promise<boolean> {
  // Check explicit in-scope domains
  if (program.inScope.domains.includes(target.domain)) {
    return true;
  }

  // Check wildcard patterns
  if (program.inScope.wildcards.some(w => matchWildcard(w, target.domain))) {
    return true;
  }

  // Check explicit out-of-scope
  if (program.outOfScope.includes(target.domain)) {
    logScopeViolation(target, program, 'explicit_exclusion');
    return false;
  }

  // Ambiguous--flag for human review
  logScopeViolation(target, program, 'ambiguous');
  await notifyHuman('scope_clarification_needed', { target, program });
  return false;
}

Ambiguous cases don’t proceed. They wait for human judgment. Better to miss a finding than to get banned.

In part 3, I described how scope violations are a failure category that triggers immediate halt and blacklisting.

---

What Evidence Should Every Report Include?

Every report should include timestamped screenshots showing the vulnerability, full HTTP request and response pairs in raw format, a reproducible proof-of-concept as a curl command or script, and SHA-256 hashes of all evidence at collection time. The hashes prove nothing was modified between discovery and submission if a dispute arises.

Evidence serves two purposes:

1. Help programs verify your finding
2. Protect you if there’s a dispute

My evidence collection:

interface EvidencePackage {
  screenshots: Array<{
    path: string;
    hash: string;
    capturedAt: Date;
  }>;
  httpExchanges: Array<{
    request: string;
    response: string;
    hash: string;
  }>;
  poc: {
    type: 'curl' | 'python' | 'manual';
    code: string;
    hash: string;
  };
  packageHash: string; // Hash of all component hashes
}

The package hash enables verification: “Here’s the SHA-256 of my evidence bundle at time of submission. It hasn’t changed.”

[!TIP] Some researchers skip evidence collection to submit faster. Don’t. That 10 minutes of screenshot capture has saved me in disputes where programs claimed “couldn’t reproduce.” I had timestamped proof that it worked on date X.

---

How Does Human Review Actually Work?

When a finding reaches 0.70 or higher confidence, it enters a review queue with full context: validation summary, false positive risk score, suggested actions, and similar past findings. The reviewer can approve for submission, request additional validation, dismiss as a false positive to train the learning system, or hold for more context.

When a finding reaches 0.70+ confidence, it queues for human review with full context:

interface ReviewQueueItem {
  finding: Finding;
  validationSummary: {
    pocResult: 'passed' | 'partial' | 'failed';
    responseDiff: string;    // Key differences found
    falsePositiveRisk: number;
  };
  suggestedActions: string[];
  priorityScore: number;
  program: ProgramSummary;
  relatedFindings?: Finding[]; // Other findings in same session
}

The review interface shows:

• Full finding details
• Validation evidence
• Why the system thinks it’s valid
• Similar past findings (accepted or rejected)
• Program-specific notes

Human reviewer can:

• Approve: Proceed to formatting and submission
• Request more validation: Send back for additional testing
• Dismiss: Mark as false positive (logs pattern for learning)
• Hold: Wait for more context before deciding

This connects to platform integration in part 4. Approved findings go to platform-specific formatters, then submit with human-approved content.

---

What’s the Human Augmentation Philosophy?

The goal is not to replace human security researchers but to eliminate the tedious mechanical work — subdomain enumeration, fingerprinting, endpoint discovery, initial detection — so human attention focuses where judgment matters. Automation handles breadth and consistency; humans handle impact assessment, severity calibration, disclosure timing, and program communication. The division is intentional.

I’m not building a replacement for human researchers. I’m building a tool that makes human researchers more effective.

What automation handles:

• Subdomain enumeration (tedious, mechanical)
• Technology fingerprinting (pattern matching)
• Endpoint discovery (exhaustive search)
• Initial vulnerability detection (known patterns)
• PoC validation (reproducibility testing)
• Evidence collection (systematic capture)
• Report formatting (platform-specific templates)

What humans handle:

• Is this finding impactful enough to report?
• Is the severity assessment accurate?
• Are there edge cases the automation missed?
• How should this be communicated to the program?
• Should we coordinate with other researchers?
• Is disclosure timing appropriate?

The division is clear: automation for breadth and consistency, humans for judgment and nuance.

I originally wanted full automation. Well, it’s more like… I wanted the efficiency fantasy of passive income from vulnerability reports. But judgment can’t be automated. Context matters too much. Programs are run by humans who respond to human communication.

---

What Are the Ethical Boundaries of Security Automation?

The system operates only within registered bug bounty programs on explicitly in-scope targets, halting immediately on scope ambiguity. It never exfiltrates data, misrepresents severity for higher bounties, fabricates evidence, or submits duplicates across programs. Rate limiting and ban detection are mandatory, not optional. Human review is required before any submission reaches a program.

Some things the system will never do:

Never exploit for gain beyond bounty

• No data exfiltration
• No ransomware deployment
• No selling access

Never test without authorization

• Only registered bug bounty programs
• Only explicitly in-scope targets
• Halt immediately on scope ambiguity

Never prioritize speed over safety

• Rate limiting is mandatory
• Ban detection triggers immediate halt
• Human review required before submission

Never misrepresent findings

• No exaggerating severity for higher bounties
• No fabricating evidence
• No duplicate submissions across programs for same vendor

These aren’t just ethical guidelines—they’re code constraints. The system literally cannot do some of these things.

---

How Does This Connect to the Full System?

Human-in-the-loop design is the final layer that unifies the entire architecture. The SQLite pattern database learns from human feedback on dismissed findings. Validation signatures come from human rejections. Platform formatters produce exactly what human reviewers approve. Every other part of the system — reconnaissance, testing, failure recovery — exists to serve human judgment.

Throughout this series:

1. Architecture: Multi-agent design with evidence-gated progression
2. Validation: Response diff analysis to reduce false positives
3. Failure Learning: Recovery strategies and pattern learning
4. Multi-Platform: Unified model with platform-specific formatters
5. Human-in-the-Loop (you are here): Mandatory review gates and ethical boundaries

Each layer builds on the previous. But they all converge on this final point: humans make the decisions that matter.

The SQLite RAG learns from human feedback. Validation signatures come from human rejections. Platform formatters produce what human reviewers approve. The entire system exists to serve human judgment, not replace it.

---

What’s the Actual Outcome?

Mandatory human review shifted submissions from high-volume to high-quality. Before the change, acceptance rates were low and program relationships were strained. After, the acceptance rate exceeds 80 percent, programs respond faster because trust is established, and evidence packages prevent disputes. The speed tradeoff — slower submissions — is worth the reputation gain.

Before human-in-the-loop design:

• Fast automated submissions
• Low acceptance rate
• Negative program relationships
• Stressful dispute resolution

After mandatory human review:

• Slower, more deliberate submissions
• 80%+ acceptance rate
• Programs respond faster (trust established)
• Evidence prevents disputes

The speed tradeoff is worth it. I’d rather submit 5 high-quality reports per week than 50 that damage my reputation.

---

Series Conclusion: What We Built

Over five posts, I’ve described a system that:

1. Uses multi-agent architecture for parallel reconnaissance, testing, validation, and reporting
2. Applies evidence-gated progression where findings must prove themselves before advancing
3. Learns from failures with categorized recovery strategies and pattern databases
4. Integrates multiple platforms through unified models and platform-specific formatters
5. Requires human judgment for all decisions that affect researcher reputation

It’s not fully autonomous. It’s not meant to be.

The goal was never to replace human security researchers. The goal was to eliminate the tedious parts—the subdomain enumeration, the endpoint mapping, the false positive filtering—so human attention goes to the parts that require judgment.

Maybe the best automation isn’t the kind that removes humans from the loop. Maybe it’s the kind that keeps humans at the center—informed, efficient, and making better decisions because the noise has been cleared away.

---

That’s the series. Five posts on building something I actually use. If you’re building security automation, I hope this helped you think through the architecture, the failure modes, and especially the ethical constraints.

Questions? Critiques? I’d love to hear them.