AI pentesting shows code access sharply increases vulnerability discovery

At a glance

What this is: This is an analysis of AI-powered penetration testing that finds source-code access materially increases discovery depth and lowers the cost per finding.

Why it matters: It matters because IAM, application security, and AI security teams need to know when greybox testing leaves internal authorisation logic, authentication flows, and access control failures effectively invisible.

By the numbers:

• Across more than 1,000 AI-powered penetration tests, whitebox engagements found 7x more high and critical vulnerabilities.
• 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.

👉 Read Aikido's analysis of why code access improves AI pentesting ROI

Context

AI-powered penetration testing is changing the economics of security assessment, but access still determines what the test can actually see. In this report, the core question is not whether an AI agent can find bugs, but whether greybox access leaves critical failure modes hidden inside application logic, internal auth flows, and data integrity paths.

That distinction matters for identity and access governance because broken access control and authentication logic are not purely application issues. They are often the same classes of failure that expose privilege boundaries, weak authorisation checks, and misplaced trust in what an external test can observe.

Key questions

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. If scope depends on prompts or written instructions, the platform can behave outside the buyer’s risk boundary. Technical scope enforcement is what keeps an automated tester from becoming an uncontrolled actor.

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. That increases the chance of finding critical flaws that are invisible externally and reduces wasted effort on dead-end probing. In high-risk applications, code access shifts testing from surface validation to control validation.

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. It is not enough when the question is whether internal authorization, authentication, or data integrity logic actually behaves correctly. If the business impact of a failure is high, code-informed testing is the safer assumption.

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.

Technical breakdown

Why source code changes discovery depth in AI pentesting

Whitebox testing gives the agent the full application context, including routing logic, auth checks, internal services, and state transitions. That matters because many high-severity flaws are not observable from a response body alone. An external attacker can only probe endpoints, but a whitebox agent can reason about control flow, hidden branches, and whether authorization is enforced consistently across layers. The report’s finding that whitebox surfaced 7x more high and critical issues reflects that difference in visibility, not just a faster workflow.

Practical implication: use source-code access when the goal is to validate authorization logic, not just enumerate exposed endpoints.

Broken access control, authentication logic flaws, and SSRF in whitebox testing

Broken access control appears when the application fails to enforce who can do what at the server layer, even if the user interface suggests otherwise. Authentication logic flaws sit one step earlier, where the sequence for login, session handling, or step-up checks can be bypassed or reused incorrectly. SSRF and data integrity issues often require code-level context because the dangerous path is buried in internal request handling or backend trust assumptions. Whitebox testing expands coverage because these flaws frequently depend on implementation details that greybox cannot infer.

Practical implication: prioritise whitebox for systems where hidden privilege checks or multi-step authentication paths create meaningful abuse potential.

Why AI agents reduce the cost penalty of whitebox access

Traditional whitebox testing was slower because humans had to read code manually and reconcile findings by hand. AI agents compress that overhead by ingesting the codebase quickly and moving from discovery to remediation faster. That changes the ROI calculation: if the agent can inspect source in seconds, the old assumption that greybox is the default economical choice no longer holds. The report’s 15 versus 31 agent-launch difference suggests the real variable is not access convenience, but how much risk remains opaque when code is withheld.

Practical implication: evaluate whitebox as a cost-control mechanism for finding density, not as a luxury reserved for only the most sensitive applications.

Threat narrative

Attacker objective: The attacker objective is to exploit implementation-level application flaws that are invisible to greybox testing and can lead to unauthorised access, request forgery, or integrity compromise.

1. Entry occurs through externally visible application interfaces when greybox testing has no source-code context and must infer behaviour from responses alone.
2. Escalation happens when hidden authorization checks, authentication flows, or backend request handling remain untested because the agent cannot inspect implementation paths.
3. Impact is the continued presence of high-severity flaws such as broken access control, authentication logic bypasses, and SSRF that survive external validation.

NHI Mgmt Group analysis

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.

Broken access control is the most revealing signal in this dataset because it sits at the intersection of application design and identity enforcement. When authorization logic is embedded in code, greybox testing can only guess at policy correctness. That makes application security and IAM governance converge around the same failure mode: server-side trust that is never independently verified. Teams should assume internal access rules are under-tested unless code is in scope.

Whitebox AI pentesting lowers the cost of depth, which should change how coverage is prioritised. If an AI agent can scan source and surface materially more high-severity findings at lower cost per finding, then application criticality should drive access decisions rather than habit. That aligns with modern assurance models in NIST-CSF and NIST-800-53, where validation depth should match business impact. Practitioners should reserve greybox for bounded exposure questions, not for high-risk logic validation.

AI-driven testing will widen the gap between what teams think they have tested and what they have actually proven. The report suggests that without code access, organisations may be overestimating the completeness of their vulnerability discovery, especially for multi-step authentication and backend trust paths. That is a governance problem as much as a tooling one. Practitioners should update assurance criteria so that critical applications require code-informed validation before they are considered covered.

Source-code visibility is becoming part of the security evidence chain. Once AI agents can process code quickly, the old distinction between assessment and remediation narrows, because findings can move directly into pull requests. That changes audit expectations: teams will need to show not just that testing occurred, but that the test had enough access to validate control behaviour. Practitioners should document access scope alongside findings to preserve assurance value.

What this signals

Discovery depth is becoming the new benchmark for application assurance. As AI agents reduce the labour cost of source-informed testing, security teams will be judged less on whether they ran a pentest and more on whether they validated the logic that governs access. For identity-heavy applications, that means the assurance question moves from exposed endpoints to server-side policy enforcement.

Control coverage, not test volume, is what will matter in board conversations. A higher number of tests does not help if all of them stop at the same external boundary. Teams should expect pressure to explain which control paths were validated, where source-code visibility was required, and how whitebox evidence changes confidence in access governance.

AI-assisted pentesting will push more organisations toward evidence-based access decisions. The practical shift is simple: if code access consistently reveals materially more critical flaws, then app owners and security leaders will need a formal rule for when source must be in scope. That is where NIST-CSF style risk-based scoping becomes operational rather than theoretical.

For practitioners

• 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. Treat those apps as whitebox by default unless there is a documented reason to stay greybox.
• 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. Greybox is acceptable for surface enumeration, but it is weak evidence for internal control correctness.
• 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. If whitebox consistently reveals more critical issues, the access decision should move into security governance review.
• Document access scope in security assurance records Record whether each assessment was greybox or whitebox, what code or configuration was available, and which control paths were actually validated. This prevents teams from overstating coverage when the test never saw the internal logic that matters.

Key takeaways

• AI pentesting delivers materially better results when it can inspect source code, because internal control failures are often invisible from the outside.
• The gap between whitebox and greybox is not just about efficiency, it is about whether teams can validate authorization, authentication, and integrity logic at all.
• For critical applications, code access should be treated as part of the assurance model, not as an optional enhancement to testing.

Key terms

• White Box Testing: A testing approach where the tester has access to source code and full system context. It supports deeper validation of logic, data flow, and authorization behaviour, and in agentic settings it produces the most precise findings because the agent reasons from implementation truth.
• Gray Box Testing: A testing approach that gives the tester partial internal context such as credentials, documentation, or workflow information without full source code. It improves coverage and efficiency, but still leaves implementation details and some trust assumptions invisible.
• Broken Access Control: Broken access control occurs when a system fails to restrict what an authenticated user, service, or workload can do. The issue often appears as missing checks, inconsistent enforcement, or excessive permissions. It is a structural weakness because attacks exploit the gap between verified identity and permitted action.
• Authentication Logic Flaw: An authentication logic flaw is a mistake in the sequence or conditions that govern login, session handling, step-up verification, or account recovery. These flaws often arise from implementation detail rather than protocol weakness, making source-code review especially valuable.

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.

👉 Aikido's full report covers the whitebox versus greybox metrics, vulnerability classes, and remediation flow details.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It is a fit for practitioners who need to connect identity controls to broader security assurance decisions.