- A Pentera executive argues that in AI pentesting, the model proposes attacks and deterministic code decides what runs, so the surrounding controls matter most.
- The piece covers scope, credentials, prompt injection and proof of findings. Its author sells a product in this category, so treat the claims as the vendor's view.
- Before buying, ask vendors how every request is checked, what the agent may do with found keys, and how findings are proven.
The model is not the hard part
Buying an AI penetration tester is mostly buying a fence. The attacks come from a general-purpose model. The safety comes from everything around it.
That is the argument in a piece published by The Hacker News on October 21. Assaf Regev, AVP Product Marketing at Pentera, wrote it. Pentera sells an agentic web app pentesting product, and the piece closes with a pitch for it. The reasoning is still useful, because it describes a design question any security team should put to a vendor.
Regev's claim is that a team using a general-purpose model can begin testing its own web apps quickly. He places the engineering elsewhere: in running those tests safely on live systems and producing results a developer can use. He calls the control code around the model the harness.
Reasoning on one side, execution on the other
Regev describes a split of duties. The model decides what to try. Fixed-rule code approves each action, writes the log and can halt a test. Deterministic means the same input gets the same rule check, with no judgment call.
Take scope. During a run, an agent chooses where to send its next request thousands of times. If the limit is a plain-language instruction, the model must interpret it every time. Regev adds that an app's true edge can reach beyond one domain, through redirects and outside services. So he wants software that checks each outgoing request before it is sent.
He points to OWASP's 2026 guidance for the same idea. It sends privileged actions to a policy engine that applies fixed rules as the action executes. That engine sits outside the model.
Credentials raise a similar issue. Finding exposed keys is part of a pentest, so the agent will sometimes meet working keys that fall outside its assignment. Whether it may use them, for what purpose, and at what point a human is called in are policy choices, Regev says. The surrounding code enforces them on every attempt.
Plan for the agent being given bad instructions
Prompt injection is hidden text in content the agent reads, written to redirect it. Regev says any page or API response can carry text from anyone able to post to the app, including hidden fields, metadata and comments. One review on a product page could carry such instructions.
He reports that OWASP ranks prompt injection as the top risk for LLM applications. He adds that OWASP says no reliable prevention exists today.
So the design question changes. It is not whether the model gets fooled. It is how much the agent can do once it is. The answer, Regev says, rests on two things: how narrowly each action is limited, and which actions get extra checks and a human's approval.
Human sign-off is no free fix. Regev cites OWASP's note that approval fatigue weakens reviewers' judgment at scale. Sending everything to a person only moves the weak point down the line. The practical lesson is that the approval queue is a control with its own limits.
A finding must be reproducible
Regev cites a Google decision from October 2026. Google stopped taking product vulnerability reports for its open-source bug bounty program after automated submissions surged. The piece says Google found most of them not valid.
The source does not say what tools produced those reports. It does illustrate the cost of unproven findings: a report a developer cannot reproduce is another ticket to close. Regev's standard for a useful finding is evidence. The exploit must actually run, the access it gained must be recorded, and the result must be bundled so anyone can run it again.
In Regev's description of Pentera Apps, three items accompany every finding: a script that re-runs the exploit, a severity score under CVSS 3.1, and a CWE label naming the type of weakness. The vendor also says that once developers patch the flaw, the identical test can be repeated to check that the route into the app is shut. These are the vendor's own product claims, and WebPulse has not tested them.
Questions to put to your team and vendors
Regev also says the work is never finished. A new model version may change how the agent acts, and each software release changes the app being tested. That points to ongoing cost, not a one-time purchase.
Before approving an agentic pentest tool, ask these questions.
First, what checks every outbound request against the scope, and does that check sit outside the model? Second, what may the agent do with credentials it finds, and who decides? Third, what limits the consequences if a hidden instruction redirects it? Fourth, which actions need human approval, and how is reviewer fatigue handled? Fifth, can a developer replay each finding without trusting the tool? Sixth, what customer data reaches the model provider, and what happens when the underlying model changes?
Regev also refers to the Hugging Face intrusion that OpenAI disclosed in July. He offers it as an example of the harness failing, even within an OpenAI evaluation designed to contain agents. The piece gives no further detail, so WebPulse draws no conclusions from it.
The takeaway is simple. Getting an AI to attack is the easy step. Getting it to attack within limits, and to prove what it found, is engineering work around the model.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: The Hacker News.
