An AppSec team can point an AI agent running on a general-purpose model at its own web apps with little setup. Sure, the model writes the attacks. But everything that makes those attacks safe to run against production and worth acting on afterward lives in the harness around the model. The harness is where the engineering in AI pentesting sits. The Hugging Face intrusion OpenAI disclosed in July showed what happens when that harness gives way, even inside an OpenAI evaluation built to contain the agents.
Why Each Control Takes Rigorous Engineering
Let’s take a closer look at the attack different stages and the role AI agents can take there
Scope
A pentesting agent makes thousands of decisions about where to send its next request, and the model judges each one against a rule written in plain language. A web app’s real boundary often extends past one domain through redirects and calls to outside services. Enforcing scope means code that inspects every request before it leaves, and OWASP’s 2026 guidance routes privileged actions through a deterministic policy engine that checks them at execution time, outside the model.
Credentials
Finding exposed credentials is part of what a pentest does, so the agent regularly comes across working keys outside its assignment. Which of those it may use, for what, and when a person gets involved are policy decisions that the code around the model applies on every attempt.
Prompt Injection
Every page and API response the agent reads, including hidden fields, metadata and comments a user never sees, can carry content written by anyone who can post to the app. A single product review is enough to plant malicious instructions. OWASP ranks prompt injection the top risk for LLM applications and notes that no reliable prevention exists today. The design question is not whether the model gets fooled, but how much damage it can do if and when it does. That comes down to two things: how tightly each action is constrained and which actions require further inspection and human sign-off. Neither is simple. OWASP warns that approval fatigue degrades reviewer judgement at scale, so routing everything to a human simply shifts the failure point down the line.
Proof
In October 2026, Google stopped accepting product vulnerability reports to its open-source bug bounty program after a surge in automated submissions, the majority of which it said were not valid. A finding a developer can’t reproduce is just another ticket to close. Producing one worth acting on means running the exploit, capturing what it reached, and packaging the result so anyone can replay it, all within the limits of the other controls set.
None of this is built once. Every model upgrade can change how the agent behaves, and every release changes the app whose security it tests. And around the controls sit the systems a production agent depends on, including change-triggered testing, routing findings to the developers who own the code, strictly controlling what customer data reaches a model provider, and connecting what the agent finds in the app to the rest of the environment.
Across all of it, the pattern is the same. The model reasons about what to try, and deterministic code decides what runs, records it, and stops it when needed.
How Pentera Apps Implements the Harness
This separation of reasoning and execution is how we approach building Pentera Apps. Instead of letting an AI model send requests directly into an application, Pentera Apps pairs an AI that decides what to test with a deterministic harness that controls what runs. Every action is logged and any test can be paused or stopped at any time. It’s the same safety discipline Pentera has applied to production testing for nearly a decade, across thousands of global customers.
The harness also produces the proof. Every finding ships with a replayable exploit script, a CVSS 3.1 score and CWE mapping, so developers can reproduce the attack themselves instead of taking it on trust. Once the fix lands, the exact same attack can be re-run to confirm the path is closed. Tests run on demand or on a schedule, with change-triggered testing in CI/CD coming next, so validation stays inline with development.
The surrounding systems follow the same discipline. Only minimal, redacted data reaches the LLM, with zero retention and no training on customer data, and data stays in the customer’s region. Every test starts with context from reconnaissance across the customer’s attack surfaces, findings from their security stack, and live threat intelligence signals. That context lets Pentera trace an exploit in a web app be traced into network, cloud, and identity on one platform.
In agentic pentesting, the harness determines the results. Pentera Apps builds it in, so security teams get validated findings without building one themselves.
Note: This article has been expertly written and contributed by Assaf Regev, AVP Product Marketing at Pentera. Security teams can sign up for early access to Pentera Apps, Agentic Web App Pentesting.
