The real benefit of AI in security is economic rather than magical: work that used to be rationed because it consumed expert hours stops being rationed. The real limit is judgment. Everything useful in this topic sits between those two sentences, and most writing about it skips straight past both.
What follows is a ledger rather than a case. Some of these entries are genuinely good news, some are uncomfortable, and a few are risks that did not exist five years ago.
The benefits that hold up
Coverage stops being rationed. When testing is priced in human hours, scope gets trimmed. When it is not, you can examine the whole application rather than the third you could afford. This is the single largest practical change, and it is easy to underrate because it sounds like a discount rather than a capability. See AI-driven penetration testing for what that shift looks like delivered as a service.
Cadence matches how you ship. A test can be triggered by a deploy instead of a calendar. That collapses the window between introducing a flaw and finding it from months to hours.
Triage load drops, if the tool validates. An engine that attempts an exploit and reports what actually worked hands you a short list of confirmed problems rather than a long list of possibilities. The saving is in the engineering hours nobody budgets for: the triage.
Design review gets cheap. Handing a model a design and asking what could go wrong is fast and surprisingly good. The most expensive flaws are the ones baked into a decision, with no broken line of code to point at, and this is the cheapest moment to catch them.
The limits that are real
Intent is still hard. A tool can tell you an endpoint returns a record it probably should not. Deciding whether that is a serious authorisation failure or a deliberately public resource requires understanding what the product does. This is the frontier, and it is where you should be most sceptical of confident marketing.
Confidence is not calibrated. Models present a wrong answer in the same tone as a right one. In security that is worse than in most domains, because a plausible-sounding false negative closes an investigation that should have stayed open.
Novelty is a weak spot. Anything that works by learning from what has been seen before is strongest on patterns and weakest on the genuinely unusual - which is exactly what a determined attacker is looking for.
The problems AI adds
Two are worth naming specifically because they are new rather than inherited.
The first is invented dependencies. Models sometimes produce package names that do not exist, plausible enough that nobody checks. Attackers register those names and fill them with malicious code. The mitigation is a rule rather than advice: verify a dependency exists before installing it. We wrote about this in more detail in our piece on using Claude Fable 5 safely.
The second is data exposure. Pasting source code, customer records, or infrastructure detail into whichever assistant is convenient is now an everyday occurrence in most engineering teams, usually with nobody having decided it was acceptable.
The pattern across every entry in this ledger: AI moves the cost of security work, not the need for someone to decide what matters. The teams that get burned are the ones that assumed it moved both.
How to read any AI security claim
One question separates a real capability from a repackaged scanner: what did it PROVE? A flagged possibility is a hypothesis and generates work. A validated finding is a fact and generates a fix.
If a vendor cannot draw that line clearly for you, the tool is probably on the wrong side of it. Ours is set out on the platform page, including what the engine does not attempt.