Skip to main content
← Back to Blog

How to Use AI Agents for Offensive Security

Brandon Veiseh, Co-Founder & CEO at MindFort

Written by

Brandon Veiseh

2026-07-06·7 min read

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. We've worked with hundreds of companies, and oftentimes, red teams aren't large enough to build such robust agent harnesses that can 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.

Guardrails settings showing rate limiting modes, scope include/exclude, and rules

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%.

Context tab showing uploaded knowledge documents for a target

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.

New assessment modal showing black-box vs. white-box assessment type selection

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.

New assessment modal showing dual credential mode with viewer and admin accounts

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.

Findings page showing a validated finding with description, breakdown, and technical details

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.

Brandon Veiseh, Co-Founder & CEO at MindFort

About the author

Brandon Veiseh

Co-Founder & CEO 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.

Autonomous SecurityFor Every Team. Now.

Agents find vulnerabilities and fix them for you.

Book a demo with our team.

First Results

Hours

Coverage

24/7

False Positives

<1%

Setup

Minutes