How to Use AI Agents for Offensive Security
Written by
Brandon Veiseh
To use AI agents for offensive security: decide whether to build or buy, scope and rate limit the agents to your approved surface, feed them per-target context, choose black-box or white-box testing, provision two-tier credentials to catch privilege escalation, schedule runs on every push, and route validated findings into Linear, Jira, or a ready-to-merge pull request.
AI agents can now run continuous penetration tests against your own attack surface, validating real exploits in runtime instead of waiting for a quarterly pentest. This guide walks through the setup end to end: choosing between building agents in-house or using a provider, scoping and rate limiting them, feeding them per-target context, picking black-box or white-box testing, provisioning credentials, scheduling runs on every push, and routing findings straight into your dev workflow.
Should You Build Security Agents In-House or Use a Provider?
The first decision is whether you want an external provider of agents or your own in-house build. The catch is that models need a good enough harness, which is often why in-house builds struggle to perform well. Research shows this: the same GPT-4 model that exploited 87% of one-day vulnerabilities with a proper agent harness dropped to 7% without one . Harness quality, not raw model choice, is what separates agents that find real exploits. If you are still surveying the provider side, our roundup of the best AI tools for red teams covers where each one fits. We've worked with hundreds of companies, and oftentimes, red teams aren't large enough to build agent harnesses strong enough to keep up. That's why we built MindFort, for any team to have access to leading security agents.
How Do You Keep Agents Scoped?
Next you want to scope the agents so they are only touching what you want them to touch, and rate limit them if your network might block them. This is really easy to configure. You set an include and exclude scope so agents stay on approved surfaces, then pick a pacing mode from Auto down to Extreme Stealth depending on how much noise your network can tolerate. Remember, most of these platforms deploy large teams of agents, so rate limit accordingly.
![]()
What Context Should Your Agents Have?
I then provide per-target knowledge for each target I want to test. In MindFort, upload any knowledge documents and notes for that specific target. This step matters most for business logic flaws, which scanners miss because they don't understand what your application is actually supposed to do. By adding more context, agents can lower their false positive rate drastically to less than 1%.
![]()
Black-Box or White-Box?
You can deploy agents to simulate attackers with either no internal knowledge or full codebase knowledge. White-box will find more because the agents know where to attack and have full codebase access, though black-box more faithfully mirrors an outside threat actor.
![]()
Which Credentials Should You Provision?
Then I'll create credentials. Usually I set up two, with one being an admin account and one being a regular account, so I can check for privilege escalation. A single-account test hides authorization flaws, and broken access control has sat at the top of the OWASP Top 10 since 2021 , so the two-tier setup is worth the extra minute. MindFort agents can handle any type of auth, including MFA, SSO, SMS, Magic Link, and more.
![]()
What Happens When Agents Report Findings?
After I see my findings, I add them as a ticket to Linear or Jira, or open an automated PR that I'm able to review and merge.
View info about your findings, including the type of vulnerability, the severity, automatic triaging based on context, and more.
Since these findings were actually exploited, they are validated. Agents then have the capability to write a ready-made PR to turn findings into something your engineers can act on the same day. Also, a great feature is that you can deploy a smaller team of agents to retest that specific finding after patching, to validate a fix.
![]()
How Often Should Your Security Agents Run?
I then think about how I want to schedule my agents so I'm finding things continuously as I ship new features. I'd recommend an MCP or API call on every push, like MindFort has, or scheduling assessments. Code scanning alone won't yield as good results, because you're missing critical interactions in your infrastructure when you aren't pentesting in runtime. For MindFort specifically, our agents self-learn on every run, so performance improves over time.
How Do You Run One-Off Security Tasks?
Not every job is a full assessment. Sometimes I just have an inbound bug report to check, a single fix to confirm, or one target I want to map an attack surface for. MindFort handles these as tasks: I point a small set of agents at a narrow objective instead of kicking off a whole pentest.
Take triaging bug reports, for example. Agents will excel because they already have full knowledge and context about the target. I can drop in the report, and the agents try to reproduce it, confirm whether it's actually exploitable, dedupe it against findings we've already logged, and attach a risk score. Other tasks I'm able to do include validating fixes. After an engineer patches something, I dispatch agents to recreate the original session and re-run the exploit. If it's dead, the finding gets marked resolved. If it isn't, it comes back with proof of how it's still reachable.
What makes tasks worth using is where you trigger them from. You can tag the agents in Slack, call them from an MCP-compatible coding agent like Cursor or Claude Code, or hit the API directly, so a task runs from wherever you're already working.
Why Should You Use Agents for OffSec?
AI agents let a small red team do the work of a much larger one. They run recon, attempt the exploit, then validate and report the finding, all on the strongest models available. Attackers have access to the same models, so the race is finding your vulnerabilities before they do. Quarterly pentests can't win anymore with harness advancements. You need runtime testing on every release.
FAQ
Should you build AI security agents in-house or use a provider?
For most teams, a provider. Agents are only as good as their harness: the same GPT-4 model exploited 87% of one-day vulnerabilities with a proper agent harness and dropped to 7% without one. Few red teams have the resources to build and maintain a harness that competitive, which is why most teams adopt a platform instead of building one.
How do you keep AI agents scoped during testing?
Set an include and exclude scope so agents only touch approved targets, then pick a pacing mode, from Auto down to Extreme Stealth, based on how much noise your network can tolerate. Most platforms deploy large teams of agents at once, so rate limit accordingly or you risk tripping alerts or getting blocked mid-assessment.
What context should you give your AI agents?
Upload per-target knowledge, docs, and notes describing what each application is supposed to do. This matters most for business logic flaws, which scanners miss because they don't understand intended behavior. With enough context, agents can push their false positive rate below 1%.
Should you run black-box or white-box testing?
White-box testing finds more because agents have full codebase access and know exactly where to attack. Black-box testing more faithfully mirrors an outside threat actor with no internal knowledge. Most mature programs run both: white-box for deep coverage, black-box to validate what's actually reachable from outside.
Which credentials should you provision for AI agents?
Provision at least two accounts, one admin and one regular user, so agents can test for privilege escalation. A single-account test hides authorization flaws, and broken access control has sat at the top of the OWASP Top 10 since 2021. Capable agent platforms can handle any auth type, including MFA, SSO, SMS, and magic links.
What happens when AI agents report a finding?
Findings should route straight into your workflow: a ticket in Linear or Jira, or an automated pull request you review and merge. Because the finding was actually exploited, not just pattern-matched, it's validated rather than a guess. Agents can also retest a specific finding after you patch it, to confirm the fix holds.
How often should AI security agents run?
Continuously, ideally triggered on every push via an MCP or API call, rather than on a fixed schedule. Code scanning alone won't catch everything, because it misses the runtime interactions across your live infrastructure that pentesting in runtime surfaces. Agents that self-learn across runs also get better with each test.
Can AI agents handle one-off security tasks?
Yes. Point a small set of agents at a narrow objective, like triaging an inbound bug report or validating a fix, instead of kicking off a full assessment. For bug triage, agents reproduce the report, confirm exploitability, dedupe against known findings, and attach a risk score. Trigger tasks from Slack, an MCP-compatible coding agent like Cursor or Claude Code, or the API directly.
About the author

Brandon Veiseh
Co-Founder & CEO · MindFort
Founded his first startup building NLP models for network packet inspection. Led product at ProjectDiscovery, built their enterprise platform from scratch. At NetSPI, led development of AI tools for offensive security.