A Practical Guide to AI-Assisted Pentesting for AppSec Teams
Pentesting is a core part of any application security program. Specifically, some organisations use pentesting as the final security gate before production. However, for the AppSec team, pentesting is yet another task in their never-ending operational backlog and one that mostly pops up in their queue out of nowhere demanding high priority. So how can AppSec teams deal with these while making less impact on their own priorities?
Manual pentests are not going to be scalable enough to keep up with development velocity, especially thanks to coding agents. Traditional DAST tools are struggling to keep up with testing complex business logic and often generate noise.
Meanwhile, some advanced application security programs may already have AI systems performing automated pentesting. Though they are efficient in identifying the most common application vulnerabilities—such as injections, access control bypasses, and authn/authz issues—they do have limitations:
They are risky to use against sensitive systems as they may cause damage when human judgment isn’t present.
They are unreliable for testing complex business logic, as those tests may require different moving parts which are difficult to simulate in an agentic system.
This is where an AI-assisted pentest shines. It is the middle path between a fully automated agentic pentest and a manual pentest, bringing the best of both worlds, and even more.
What is AI-assisted pentesting?
AI-assisted pentesting is when a human instructs an AI agent to perform a pentest where the agent execute the actual testing, and a human monitors, observes, judges, and directs the pentest. This drastically speeds up the pentest process as it significantly reduces repetitive, low-value, error-prone manual steps. The combination of human instincts with an AI agent's capabilities is what makes this an effective tool.
What entails in AI-assisted pentesting
A comprehensive AI-assisted pentest follows the phases below:
Reconnaissance phase: Gathering context, architecture, source code, and previous reports.
Threat modelling phase: Identifying and scoping high-value, realistic threats.
Planning phase: Deriving a targeted checklist of tests to assess the identified threats.
Execution phase: Actively testing the application alongside the AI agent while monitoring proxies and logs.
Reporting phase: Generating evidence-backed reports with root causes and remediation advice.
Reconnaissance phase
This is passive reconnaissance where an AI agent runs in fully autonomous mode gathering documentation and source code (no live system probing). Here, agent tools are used to gather data from different systems such as GitHub, Jira, Confluence, and even Slack threads. The idea is to build a solid foundation for the next phases. Capture:
What the application is and its business objectives
Personas and use cases
System architecture and the tech stack
Scope of the change, hence the scope of the pentest
Source code, API contract documentations
Previous pentest reports, vulnerabilities, and threat models
Collect as much information as possible here. If certain information is not available or ambiguous, use this context to ask the development team clarifying questions. Store the results in the pentest ticket itself or an external system such as a Confluence page or a Google Doc. Implement this phase as an independent skill and iterate over time to improve the quality of the data it produces.
Threat modelling phase
While there are different methodologies for pentests, threat-model-driven pentests are more suitable in these white-box pentests. If you already have a threat modelling agent, this is a good place to plug that in. Ask it to work with the recon data and provide the threat model. If not, go ahead and build a skill to produce threat models. You can use frameworks such as STRIDE, PASTA, or a simple threats list custom to your organisation.
Work with the above reconnaissance data and the threat modelling framework of your choice to identify the threats. Do not be surprised if your agent provides a list with dozens of threats. Narrow down the list for the pentest scope and focus on realistic, high-value threats. Consider the rationale, exposure, impact, and complexity of a viable attack. Human judgment is paramount here.
Planning phase
Use the produced threat model as the basis and derive a test plan. What we try to do here is build a checklist of tests to assess the identified list of high-value threats. Again, review and iterate the checklist, and remove duplicates and out-of-scope tests. As before, human judgment is paramount here.
I suggest keeping this planning skill independent of the threat modelling skill talked about above. The threat model is mostly fixed at this point, hence you should have the ability to iterate over the test plan to keep the list short while making sure all high-value threats are covered. Additional tip: have a subagent run in the background to make sure the plan covers the threat model.
Execution phase
This is the phase where we interact with the live system. Hence, human caution and judgment are critical. Have your agent connected with your pentest tool (in my case, it's Burp & Burp MCP). Pick one test at a time and move on to complete the entire checklist. We are instructing the agent to prepare required requests with test payloads in Burp Repeater.
Be diligent with credentials:
Configure credentials in Burp proxy itself instead of exposing them to the agent. This is unfortunately a manual step.
Follow the least privilege principle—use credentials with the minimum permissions required for the pentest scope, and avoid admin credentials when possible.
Be diligent with prepared requests:
Target only isolated test tenants and test data; never target real user data.
Perform only non-destructive tests.
Check prepared requests for hallucinated requests and payloads—this is exactly why humans in the loop are important to spot errors and steer the pentest in the right direction. Agents also tend to dwell on unrelated details, such as performing an insignificant additional test or trying to troubleshoot a returned error. If required, just document those, but move on with focus on the targeted test.
Also, do you have a centralized logs server which you can connect over MCP? Then connect it. Ask the agent to watch the application logs for each test. This has helped me not only identify security issues in logs (such as logging sensitive info) but also determine payloads that would actually work.
For each completed test, go ahead and update the test plan with the results and evidence. This is a highly interactive activity with your agent, hence this dictates the time spent on the pentest.
Reporting phase
The majority of the work is already done, but the task is not yet finished. Build a skill that uses the pentest plan, results, and evidence to generate a pentest report. The report should also contain root cause analysis and remediation advice. A report can be multiple Jira tickets per identified issue or a single document to be shared with the team. Try adding additional validations such as severity, CVSS score/vector, CWEs, and other information such as vulnerability classes. Additionally, make sure to have another subagent check the format of the reports for possible format errors and missing attachments.
Conclusion
On a closing note, none of the skills you build will be perfect on the first run; always iterate and adjust the skill. Always ask the agent why something went wrong and ask what should be changed in the skill to get it better next time. Over time, some skills will produce desired results with almost no human interaction, where the pentester will mostly be spending time planning, observing, and validating the pentest. Once the process is well established, the AppSec team will have a repeatable, consistent pentest process that consumes less effort but produces high-quality pentest results.
Governance, Compliance and Data Privacy
The proposed approach is applicable only for internal application security teams using enterprise-managed AI agents. AI agents' access to code and other documentation systems must have been pre-approved to guarantee enterprise data isn’t used to train public models. And tests should be done on internal systems under recorded request/approval.