ANALYSIS · Evidence synthesis. Primary sources and our prior work are linked throughout. No new vulnerabilities were discovered in this piece.

AI now writes a large and growing share of production code, and it writes that code faster than anyone is securing it. For a team shipping an AI-built app, the uncomfortable part is that the failure modes are new. A penetration test designed for human-written web applications will confirm you are safe against last year's threat model and stay quiet about the one that actually applies to you.

The weaknesses that AI-built apps introduce, prompt injection, over-permissioned agents and tools, secrets baked into generated code, and attacks that ride the AI assistant itself, mostly sit outside what a standard scan or a checklist pentest looks for. This piece lays out what those gaps are, why they exist, and what a test that actually covers an AI-built app needs to include.

The velocity gap

Start with the supply side. GitHub has reported that in files where its assistant is enabled, roughly 46 percent of the code is AI written, and Google has said about a quarter of its new code is generated before a human reviews it. Adoption is close to universal among working developers. Production software is being written in a genuinely new way.

The security side has not kept pace. In our review of 23 studies on AI-generated code, a consistent share of AI output shipped with security weaknesses, and the pass rate did not improve across model generations. One widely cited benchmark from Veracode found that close to half of AI-generated code samples failed a security check, with some languages and bug classes far worse than the average. A Stanford user study found something more worrying still: developers using an AI assistant wrote less secure code and were more likely to believe it was secure. Confidence went up while security went down.

That combination, more code, produced faster, tested no more often and trusted a little more, is the exact gap a pentest for an AI-built app has to close.

What a standard pentest misses

None of the following is hypothetical. Each was documented in the field during 2026.

• Prompt injection. Untrusted text becomes instructions the app acts on. We covered a case of prompt injection redirecting an AI agent's crypto payments, and one where a public GitHub issue pulled data out of private repositories. A traditional test that fuzzes form fields never looks at the words a model reads.

• Over-permissioned agents and tools. An agent with real access reads attacker-controlled input and acts on it with whatever privileges it holds. The control is scoping, not cleverness, and scoping is exactly what a checklist app test does not review.

• The build pipeline itself. The assistant writing your code is now attack surface. In GhostApproval, an approved edit to a harmless file was redirected to run code, and in DuneSlide a single prompt executed code inside the Cursor editor.

• Secrets and unsafe defaults in generated code. AI-assisted repositories tend to leak credentials and ship insecure defaults at a higher rate, and those rarely appear on a standard web-application test plan.

• Scanners that can be fooled. The tools meant to catch this are themselves evadable, as with SkillCloak, so a clean scan is not the same as a clean app.

Mapping the new surface

Much of this is captured by the OWASP Top 10 for LLM Applications, a reference a traditional web-app test plan does not mention at all. The categories that matter most for an AI-built app are prompt injection, insecure handling of model output, excessive agency (agents that can do more than they should), and sensitive information disclosure. If your scope document does not name these, it is not testing your app, it is testing the app you would have built two years ago.

What a pentest for AI-built apps should cover

Everything a good application pentest already does, plus the AI-specific surface:

• Prompt-injection and jailbreak testing of every model-backed feature, including indirect injection through data the model reads rather than only what the user types.

• Agent and tool permission review: what each tool can reach, and what happens when its input is hostile.

• Data-flow tracing from any untrusted input to any privileged or irreversible action.

• Secrets in generated code and git history, and the security of AI dependencies and connected tools.

• The human-approval gates themselves: can an approval be bypassed or redirected, as GhostApproval showed.

How often, not just how deep

Cadence matters as much as coverage. Our analysis of exposure windows found that under an annual testing schedule, an expected 67.5 percent of 2025's actively exploited vulnerabilities would never have been tested before exploitation, and the median gap from public disclosure to active exploitation was 26 days. AI features move faster than that, because a prompt, a tool, or a model can change in a single deploy. A once-a-year test of a system that changes weekly is a photograph of a scene that has already moved.

The honest caveats

• A pentest is a point in time, and the AI threat landscape shifts quickly, which is the argument for testing continuously rather than once.

• Not every AI feature carries the same risk. Depth should follow what the model can actually reach and do, not the marketing around it.

• Testing finds problems, it does not fix them. The report has to be actionable, with severity and remediation, not just a list of observations.

Where this fits

This is the threat model our VAPT is built for. It tests the AI-specific surface above alongside the standard application checks, and it produces the report you can hand to a customer or an auditor. If you are shipping an AI-built app, that coverage is what the old test plan does not give you.