AI-native penetration testing should not mean handing a target to a model and accepting whatever comes back. A pentest is an authorized security process that requires safe actions, proven exploitability, business context, reproducible evidence, and accountable human judgment.

AI is still changing how skilled researchers work. It can process supplied context, suggest overlooked attack hypotheses, compare repetitive artifacts, and challenge whether a finding is complete. Used carefully, that support leaves more attention for roles, tenant isolation, state changes, business logic, integrations, and exploit chains.

The Balhence position: AI expands the search. A human authorizes the action, proves the exploit path, decides the impact, and owns the report. Model output is a lead, never evidence by itself.

1. What AI-native means in a penetration test

AI-native describes a workflow designed around both AI's utility and its limitations. It is different from adding a chatbot to an existing method, and from claiming that an autonomous agent can conduct an entire client engagement.

In a responsible VAPT workflow, AI can cross-reference an OpenAPI document with an asset list, convert a role matrix into candidate authorization checks, group observations, propose alternative abuse paths, or review a finding for missing prerequisites. Every output remains provisional until a tester checks it against the authorized system and primary evidence.

The boundary is authority. A model does not decide scope, whether production is safe to test, when an action risks customer data, or how far a proof should go. It does not turn an interesting response into a confirmed vulnerability, set final severity, or sign off the report.

Three rules define the operating model

  • AI assists analysis: it can structure context, create candidate hypotheses, and check work for gaps inside an approved data boundary.
  • The tester controls execution: every live request, payload, rate, account, and proof step remains subject to the agreed rules of engagement.
  • Evidence decides the finding: only manually reproduced behavior with inspectable evidence, realistic impact, and a defensible remediation path enters the report.

2. What current penetration-testing evidence actually shows

Industry numbers can show adoption and technical progress, but they need boundaries. These are external survey and benchmark results, not Balhence performance figures. They do not predict finding counts or engagement time.

AI use among hackers has risen sharply

Bugcrowd's 2026 Inside the Mind of a Hacker announcement says its report draws from surveys and interviews with more than 2,000 participants worldwide. It reports that 82% of hackers use AI in their workflows, up from 64% in 2023. Bugcrowd identifies automation, learning, and data analysis as common uses.

That result demonstrates adoption within Bugcrowd's research community. It is not a controlled comparison of AI-assisted and non-assisted pentests, and it does not establish better coverage, accuracy, or client outcomes. It also describes hackers in a crowdsourced security context, which should not be treated as identical to a commissioned VAPT engagement with a fixed scope and rules of engagement.

Researchers report both adoption and clear limits

HackerOne's 2025 Hacker-Powered Security Report says 70% of surveyed researchers use AI tools in their workflow. Its published survey methodology states that the researcher survey included 1,825 active HackerOne researchers and was fielded between July and August 2025. HackerOne says the report was also supplemented with platform data from 1 July 2024 through 30 June 2025, covering all active customer programs.

The same report provides an important counterweight to adoption: 58% of surveyed security researchers said AI misses business logic or chained exploits, and only 12% believed it could replace them. These are self-reported views from active researchers, not a laboratory measurement, but they align with a practical weakness in model-only testing. An HTTP response can resemble a known flaw while the decisive risk depends on ownership, sequence, commercial rules, or an action in another role.

HackerOne's 2025 report announcement also says autonomous agents submitted more than 560 valid reports. That is evidence that autonomous systems can produce accepted results on its platform. It is not a count of autonomous client pentests, it does not reveal the total submission denominator in that statement, and it should not be read as a replacement rate for human researchers.

Controlled systems can find and patch real code vulnerabilities

DARPA's 2025 AI Cyber Challenge results show a different capability. Across a controlled final competition involving more than 54 million lines of code, competitor cyber reasoning systems found 54 of 63 synthetic vulnerabilities and patched 43. They also found 18 real, non-synthetic vulnerabilities in the open-source codebases and produced 11 patches for those real findings.

AIxCC was a controlled code-security challenge using systems built by multiple finalist teams. It was not a live web or API pentest, a comparison against human testers, or evidence about client authorization, production safety, business logic, or reporting. It demonstrates automated discovery and patching under competition conditions.

What the numbers support: AI adoption is high among security researchers, autonomous systems can produce valid security reports, and controlled systems can find and patch vulnerabilities at scale. The same evidence does not support claims of complete coverage, guaranteed speed, or autonomous replacement of a skilled tester.

3. Where AI can improve a web and API pentest

Scope and coverage cross-reference

Web and API scopes often arrive as incomplete host lists, diagrams, API specifications, collections, role notes, release tickets, and buyer requirements. Within agreed data rules, AI can compare those inputs and flag mismatches, such as an administrative route missing from the asset list or an API operation with no matching test role.

The output is a question list, not an automatic scope expansion. The client and tester still decide what is owned, authorized, reachable, excluded, and important. The web and API pentest scoping guide explains how to make that boundary inspectable.

Threat modeling and hypothesis expansion

A tester can use AI to generate additional abuse hypotheses from a human-built model of roles, resources, state transitions, and integrations. For example, it can suggest alternate ownership states for an object-level authorization check, edge cases around invitations and recovery, or places where an API and browser workflow may enforce different rules.

This helps breadth when an application contains many combinations. The tester still ranks hypotheses, removes implausible ideas, designs the minimum-impact test, and checks the rules. Generated payloads and code are reviewed before execution, never trusted merely because a model proposed them.

Artifact organization and pattern comparison

Authorized testing produces endpoint inventories, role comparisons, response differences, identifiers, headers, and state notes. AI can structure sanitized artifacts, group observations, and flag inconsistent behavior for manual review across API versions, content types, or roles.

A pattern is not proof. Differences can result from caching, test data, feature flags, asynchronous processing, or environment drift. A tester must isolate the variable, verify ownership and authorization, and preserve the supporting raw evidence.

Finding and report quality control

AI can check whether a draft finding contains the affected scope, identity, prerequisites, exact reproduction, evidence, observed impact, severity rationale, and targeted remediation. It can identify ambiguous language or a step that assumes hidden tester knowledge. This is editorial and structural support, not technical validation.

The final record remains grounded in the tester's captured evidence. The guide to a useful pentest report shows what engineering and assurance readers should be able to inspect. The sample report demonstrates how that evidence can be presented without exposing client material.

4. The decisions that remain human

Human involvement should not be a vague promise added after autonomous testing. It should appear as explicit gates in the engagement workflow.

  1. Authorization gate: the tester confirms assets, identities, techniques, rates, exclusions, data rules, stop conditions, and third-party boundaries before testing.
  2. Execution gate: a human reviews live actions and generated test material, then controls the account, timing, volume, and target.
  3. Exploitability gate: a candidate issue is manually reproduced with controlled accounts or synthetic data and the minimum proof needed.
  4. Impact gate: the tester connects technical behavior to the actual product, tenant, workflow, and business consequence instead of relying on a generic vulnerability label.
  5. Severity gate: scoring reflects observed prerequisites, privileges, blast radius, data class, and compensating controls. A model may challenge consistency, but it does not make the final decision.
  6. Reporting gate: the tester verifies every statement, removes unsupported conclusions, checks redaction, and owns the final deliverable.
  7. Closure gate: agreed fixes are re-tested against the original evidence and recorded as fixed, partial, not fixed, or unable to verify.

These gates preserve accountability when the model is confidently wrong, when context is missing, or when the technically possible proof would create unacceptable client risk. They also make AI use reviewable by procurement, engineering, and security leadership.

5. Client data controls for AI-assisted VAPT

AI assistance creates a data-processing question before a productivity question. Scope documents, code, traffic, credentials, customer records, evidence, and reports can contain sensitive material. The engagement must define what may be processed, by which service, for which purpose, and under which retention terms.

Balhence records permitted AI use in the scope or rules of engagement. No client material is sent to an external AI provider unless the use, provider, and relevant data class are permitted. Credentials, active session tokens, private keys, and authentication recovery material are not entered into model prompts. Sensitive artifacts are minimized or redacted, and raw evidence stays in the agreed evidence channel unless a separate approval says otherwise.

Controls to settle before testing

  • Permitted purposes: identify whether AI may assist scope review, hypothesis generation, artifact analysis, report quality control, or none of those tasks.
  • Approved data classes: distinguish public documentation, synthetic examples, sanitized traffic, source code, architecture, and confidential security evidence.
  • Provider terms: document the approved service, access controls, retention, training treatment, processing location, and deletion requirements where applicable.
  • Data minimization: remove secrets, unrelated records, personal data, and unnecessary response bodies before an approved analytical task.
  • Execution separation: do not give a model unrestricted credentials or autonomous authority to issue production requests.
  • Evidence integrity: preserve original requests, responses, logs, screenshots, and tester notes independently of model-generated summaries.
  • Retention and closure: delete or retain derived AI artifacts under the same documented engagement rules that govern other sensitive work product.

If a client's policy prohibits third-party model processing for specified material, that restriction belongs in the written engagement boundary. AI-native should describe an adaptable method, not a demand that confidential data be exposed to a particular vendor.

6. How to evaluate an AI-native pentest provider

Buyers should ask for operational detail instead of accepting the label. A credible provider can explain the exact tasks AI assists, where the human gates sit, how model output is tested, and what client information may be processed.

  • Which parts of scoping, testing, evidence handling, and reporting use AI?
  • Can an agent send live requests, or must a tester approve and control them?
  • Which AI providers and service tiers may process engagement material?
  • Are prompts or outputs retained or used for provider training?
  • Which client data classes are prohibited from model processing?
  • How is every reported finding manually reproduced and tied to raw evidence?
  • Who decides business impact, severity, safe proof limits, and re-test status?
  • Can the provider show a useful sample report and written rules of engagement?

Be cautious with promises such as 100x faster, zero false positives, complete coverage, autonomous business-logic testing, or guaranteed finding counts. The studies above do not support those claims. Strong AI-native positioning is specific about assistance and equally specific about limits.

7. Measure usefulness without inventing transformation claims

A service should not turn industry adoption figures into its own performance claims. Honest internal measurement asks whether AI improves the quality and traceability of the engagement: Did documentation cross-reference expose a real scope gap? Did a generated hypothesis become a manually verified finding? Did quality control catch missing evidence? Did the final report remain accurate after human review?

Raw prompt counts, generated test cases, and model-written words are activity measures. They do not demonstrate risk reduction. Balhence does not publish a speed, coverage, or finding-rate improvement percentage without comparable first-party engagement data that can support it. The defensible outcome remains an authorized scope, reproducible evidence, a practical remediation path, and a verified closure record.

In one sentence: AI-native VAPT uses models to widen and organize the candidate work, while an accountable tester retains control of authorization, execution, evidence, impact, reporting, and client data.

Primary sources and methodology

Put the AI boundary in the pentest scope

Define the applications, APIs, roles, evidence needs, permitted AI tasks, client-data restrictions, and human approval points before testing starts. Build a private draft or request a scoped conversation.

Build your draft scope Discuss the engagement