If your security team is evaluating AI-powered vulnerability scanners or has already deployed one, you need a framework for effective human-AI collaboration. This checklist ensures you're enhancing human expertise, not replacing it.
HTTP Terminator, PortSwigger's AI system for detecting HTTP request smuggling, identified 700 vulnerable targets and generated 30,000 unique attack vectors. It also discovered a new vulnerability class called "shared-parser confusion." Director of Research James Kettle guided the system at every critical decision point. Your AI tools won't deliver value without similar structured human oversight.
Prerequisites
Before using this checklist, confirm:
- You have at least one security engineer with expertise in the vulnerability class your AI tool targets (web application security, API security, infrastructure scanning).
- Your team can dedicate 4-8 hours per week to reviewing AI-generated findings.
- You have a test environment where AI tools can run without impacting production.
- Your compliance framework (PCI DSS v4.0.1 Requirement 11.3, OWASP ASVS v4.0.3) already requires regular vulnerability assessments.
Deployment Checklist
1. Define Human Decision Points
Action: Map every stage where your AI tool makes a judgment call, then assign a human reviewer.
Done when: You have a written decision matrix showing which AI outputs require human validation before action. For vulnerability scanners, this includes: target selection, attack vector generation, severity classification, and exploitation attempts.
Good looks like: "AI suggests 200 endpoints for deep scanning. Senior engineer reviews list, removes customer-facing payment APIs, approves remaining 180 targets within 15 minutes."
2. Establish Ground Truth Validation
Action: Before production deployment, run your AI tool against known-vulnerable test applications where you've already documented every flaw.
Done when: You can measure false positive and false negative rates against your ground truth dataset. Document which vulnerability types the AI misses or overreports.
Good looks like: "AI detected 8 of 10 known SQL injection points in our test environment, flagged 3 false positives in parameterized queries. We now know to manually verify all database interaction findings."
3. Create Human Feedback Loops
Action: Build a process where security engineers can correct AI classifications and see those corrections influence future scans.
Done when: Your team has a documented workflow for marking false positives, reclassifying severity, and feeding corrections back into the AI system (if supported) or into your internal knowledge base.
Good looks like: "Engineer marks XSS finding as false positive, adds context about input sanitization. Next scan against similar code patterns includes this context in the analysis."
4. Set Exploitation Boundaries
Action: Define which AI-generated attack vectors your team will actually execute, and which require manual review first.
Done when: You have written rules about what the AI can test automatically versus what needs human approval. Consider impact on availability, data integrity, and compliance scope.
Good looks like: "AI can automatically test GET request variations and parameter fuzzing. Any POST requests that modify data, authentication bypass attempts, or scans against third-party integrations require engineer approval."
5. Document Novel Findings Separately
Action: When your AI tool identifies something your team hasn't seen before, create a separate review process before remediation.
Done when: You have a "novel finding" workflow that includes: independent verification by a second engineer, research into whether this represents a new vulnerability class, and documentation of the discovery process.
Good looks like: "AI flags unusual HTTP header parsing behavior. Two engineers independently verify, research similar patterns, confirm this matches the 'shared-parser confusion' technique. Team documents the finding and updates scanning rules."
6. Measure Human Time Investment
Action: Track how many hours your team spends reviewing AI outputs versus how many vulnerabilities you actually remediate.
Done when: You can answer: "For every hour spent reviewing AI findings, how many confirmed vulnerabilities do we fix?" If the ratio drops below your manual testing baseline, your human oversight process needs adjustment.
Good looks like: "Team spends 6 hours weekly reviewing AI scan results, confirms and remediates 12 vulnerabilities. Previous manual testing: 8 hours weekly, 8 vulnerabilities fixed. AI is amplifying our effectiveness."
7. Align with Compliance Requirements
Action: Map your AI-assisted vulnerability research to specific compliance requirements you're already meeting.
Done when: You can show auditors that AI tools enhance (not replace) your existing PCI DSS v4.0.1 Requirement 11.3 quarterly scans, OWASP ASVS verification activities, or ISO/IEC 27001:2022 control A.8.8 (technical vulnerability management).
Good looks like: "Our quarterly PCI scans now include AI-generated test cases reviewed by our QSA-approved engineer. Scan reports document both automated findings and human validation steps."
Common Mistakes
Trusting severity scores without context. AI tools classify a finding as "critical" based on theoretical impact. Your engineer knows that endpoint is internal-only and rate-limited. Always apply business context to AI-generated severity ratings.
Skipping the feedback loop. If you can't correct the AI's mistakes, you'll review the same false positives every scan. Demand tools that learn from your team's expertise or build your own correction database.
Automating exploitation without guardrails. Generating 30,000 attack vectors is impressive until one crashes your payment processor during Black Friday. Set clear boundaries on what the AI can execute automatically.
Ignoring the "why" behind novel findings. When AI discovers something new, your team needs to understand the underlying vulnerability class, not just patch the specific instance. This is where human research creates lasting value.
Next Steps
Start with one vulnerability class and one AI tool. If you're scanning web applications, focus on a specific OWASP Top 10 category. Run the tool against your test environment for two weeks while a senior engineer reviews every finding. Measure your false positive rate and time investment.
If the AI amplifies your team's effectiveness (more confirmed vulnerabilities per hour invested), expand to production systems with appropriate guardrails. If you're spending more time reviewing bad findings than you would doing manual testing, either adjust your human oversight process or evaluate different tools.
The goal isn't autonomous AI security research. It's security engineers who can investigate 10x more attack surface because AI handles the repetitive scanning work while humans make every critical decision.
