Notifications
Clear all
Topic starter
02/08/2026 11:29 am
TL;DR: Across more than 1,000 AI-powered penetration tests, whitebox engagements found 7x more high and critical vulnerabilities and required 15 agent launches per finding versus 31 for greybox, according to Aikido. The result is a measurable case for source-code access when teams need to uncover hidden authorization, authentication, and integrity failures.
NHIMG editorial — based on content published by Aikido: Why code access drives higher ROI in AI pentesting
By the numbers:
- Whitebox engagements required 15 agent launches per finding versus 31 for greybox.
- The report covers over 1,000 AI-powered engagements on the Aikido platform.
Questions worth separating out
Q: What breaks when AI pentesting scope is not enforced technically?
A: Tests can drift outside intended environments, touch production paths, or produce results that are impossible to trust.
Q: Why does source-code access change the value of AI pentesting?
A: Source code lets the agent inspect control flow, authorization checks, and internal request handling instead of guessing from observed responses.
Q: How do security teams know if greybox testing is enough?
A: Greybox is usually enough only when the objective is to map exposure and confirm that obvious attack paths are closed.
Practitioner guidance
- Define whitebox thresholds for critical applications Require source-code access for systems where broken access control, authentication logic, or data integrity defects would materially affect business operations.
- Map test scope to control failure modes Tie pentest scope to the specific classes of logic you need to validate, such as authorization enforcement, session handling, and server-side request handling.
- Use findings density to justify broader access Compare findings per agent launch and remediation effort across test modes, then use that data to decide where code access reduces risk faster.
What's in the full report
Aikido's full report covers the operational detail this post intentionally leaves for the source:
- Side-by-side metrics for whitebox and greybox testing across finding volume, severity, and cost per finding.
- The three vulnerability classes where whitebox outperformed greybox most clearly, including broken access control and authentication logic flaws.
- How source-code access changes the remediation workflow from discovery to pull request.
- Decision guidance on when to prefer whitebox based on access timelines and application criticality.
👉 Read Aikido's analysis of why code access improves AI pentesting ROI →
AI pentesting with code access: are your tests missing critical flaws?
Explore further
02/08/2026 12:45 pm
Code access is now a governance decision, not just a test option. The report shows that source-code visibility materially changes what AI pentesting can prove, especially for authorization and authentication defects. In practice, this shifts the conversation from test style to assurance boundary: if the code is hidden, the test is measuring exposure rather than control integrity. Practitioners should treat whitebox access as part of validation strategy, not a convenience setting.
A question worth separating out:
Q: Should organisations default to whitebox AI testing for critical applications?
A: Yes, when application logic governs access, transactions, or privileged actions. Whitebox testing is the better default for critical systems because it validates how controls are implemented, not just whether they are externally observable. Greybox remains useful for breadth, but it should not be the only proof of control effectiveness.
👉 Read our full editorial: AI pentesting shows code access sharply increases vulnerability discovery
