Continuous AI pentesting is redefining offensive security testing

At a glance

What this is: Novee argues that continuous AI pentesting has crossed into a market with real practitioner demand, especially for testing LLM-enabled applications and autonomous agents.

Why it matters: This matters because AI applications introduce stateful trust boundaries and new attack paths that conventional pentesting and application security workflows do not reliably model.

By the numbers:

• 34% of survey respondents on Latio’s 2026 AppSec Report listed “AI Pentesting” as the AI feature they’re most excited about.

👉 Read Novee's RSAC 2026 breakdown of AI pentesting and offensive security

Context

AI pentesting is the application of offensive testing methods to LLM-powered systems, including chatbots, copilots, autonomous agents, and AI-assisted workflows. The governance gap is that these systems do not behave like static web applications, so familiar scanning and manual testing methods miss prompt injection, agent manipulation, and trust-boundary abuse. For identity teams, the question becomes how to govern access, delegation, and tool use when AI systems act as runtime participants in the control plane.

Security leaders are being pushed toward continuous testing because point-in-time validation cannot keep pace with AI deployment. That shift matters across IAM, PAM, and NHI programmes because AI systems often consume secrets, inherit service access, and make delegated calls through non-human identities. For background on the wider identity context, the Ultimate Guide to NHIs , The NHI Market is a useful reference point.

The article’s starting position is typical of the market moment: demand is rising faster than practitioner confidence in how to evaluate vendors or evidence quality.

Key questions

Q: What breaks when AI pentesting only automates scanner workflows?

A: Teams get output that looks like offensive testing but does not prove attacker behaviour. Scanner automation may find known weaknesses, yet it often misses prompt injection, chained tool abuse, and conditional decision paths. For AI systems, that creates false confidence because the real risk is whether an attacker can steer the system into harmful actions, not whether a checklist was completed.

Q: Why do AI agents complicate existing IAM and NHI controls?

A: They complicate control design because they can select actions at runtime, call multiple APIs, and move authority across systems without a human session boundary. That breaks assumptions built into static entitlements and traditional service account management. Governance has to account for delegated action, changing context, and auditability across the full execution chain.

Q: How do security teams know whether an AI pentesting tool is credible?

A: Ask whether it can show multi-step attack chains that begin with an actual entry condition and end with a validated impact. Credible platforms should demonstrate exploitation paths against LLM applications, not just flag prompts or configuration issues. If the output cannot distinguish theory from reachability, the evidence is too weak for operational decisions.

Q: How should organisations govern AI agents alongside human identity and device access?

A: Organisations should treat AI agents as a separate identity class with their own entitlement boundaries, logging expectations, and approval model. Human IAM controls often assume interactive sign-in and review cycles, which do not fit autonomous or programmatic access. The safer approach is to define actor-specific policy and verify which access paths can be delegated without expanding trust unnecessarily.

Technical breakdown

Why LLM-powered applications change the attack surface

LLM-enabled systems add statefulness, contextual memory, and external tool use to application flows. That means the security boundary is no longer just input validation or API authorisation. Prompt injection, jailbreaks, and agent manipulation can alter behaviour without traditional code exploitation. The core issue is that the model may follow instructions embedded in content, retrieved data, or upstream prompts, then act through tools that were not designed for adversarial chaining. In practice, the risk lives at the intersection of application logic, model behaviour, and delegated access.

Practical implication: treat AI systems as dynamic execution environments, not just another application tier.

Why autonomous testing is different from scanner automation

Conventional scanners enumerate known misconfigurations and vulnerability signatures. Autonomous offensive testing tries to simulate adversarial decision-making, including chaining observations, choosing follow-on actions, and validating whether an attack path is actually exploitable. That distinction matters because many AI weaknesses only appear when a tester can adapt mid-run, infer trust relationships, and interact with tools or agents. The technical question is not whether a finding exists in theory, but whether the system can be driven into harmful behaviour under realistic attacker pressure.

Practical implication: require evidence of multi-step attack paths, not just vulnerability labels.

How AI agents create NHI governance pressure

When an AI system can call tools, access data, or trigger workflows, it begins to resemble a non-human identity in operational terms. It may hold secrets, use tokens, and act across multiple services with delegated privilege. That raises governance issues familiar to IAM and PAM teams: who approved the access, how it is constrained, and how it is revoked or monitored. The challenge is not that every AI feature is autonomous, but that tool-using systems can expand the trust boundary faster than lifecycle controls are updated.

Practical implication: classify AI systems that use credentials or APIs as governed non-human identities.

Threat narrative

Attacker objective: The attacker wants to turn a trusted AI workflow into an execution path for data theft, unauthorised actions, or broader access abuse.

1. Entry occurs when an attacker targets an LLM-powered application, copilots, or autonomous agent surface that accepts untrusted prompts or retrieved content.
2. Escalation happens when prompt injection, jailbreaks, or agent manipulation causes the system to chain actions through trusted tools or delegated credentials.
3. Impact follows when the attacker uses that trusted execution path to exfiltrate data, corrupt workflows, or trigger downstream abuse across connected systems.

NHI Mgmt Group analysis

Continuous AI pentesting is becoming a governance problem, not just a testing category. Once AI systems can reason, retrieve, and act through tools, the question shifts from finding bugs to proving whether an attacker can steer an operational workflow. That creates overlap between application security, IAM, and NHI governance, especially where service credentials or delegated tokens are involved. Practitioners should treat testing evidence as a control signal, not a marketing claim.

AI tool use creates a trust boundary that traditional pentesting was never built to test. Static scans can identify known defects, but they do not show how an LLM will behave when content, prompt context, and tool permissions are combined. That is why AI security programmes need adversarial testing that measures decision chains, not just surface exposure. The practical conclusion is that model risk and access risk now have to be assessed together.

Named concept, attacker-behaviour fidelity: the market is splitting between tools that simulate real adversary chaining and tools that merely automate vulnerability enumeration. In offensive AI security, fidelity matters because a shallow test can produce false confidence even when prompt injection or agent manipulation would succeed in production. Security leaders should demand proof of multi-step execution, privilege use, and validated remediation paths before they treat findings as trustworthy.

AI agents are increasingly functioning as non-human identities, which means IAM and PAM teams cannot leave them outside governance boundaries. If a system can authenticate, request data, and trigger actions, it needs ownership, scoping, and revocation discipline. That does not mean every AI feature is autonomous, but it does mean the identity model has changed enough to require explicit controls. Practitioners should map AI operational access into existing NHI governance processes rather than inventing a parallel exception path.

What this signals

The practical signal for security programmes is that AI security procurement is moving from experimentation to control selection. Teams will need to decide whether they are buying scan coverage, adversarial simulation, or identity-aware governance for AI systems. The strongest programmes will map those choices back to IAM and NHI ownership instead of treating AI as a separate exception domain.

Trust-boundary drift: as LLMs and agents gain access to tools and data, the boundary between application security and identity governance keeps moving. That means access reviews, secret management, and revocation workflows will increasingly need to account for non-human runtime behaviour, not just human user entitlements.

For readers operating mixed human and machine access programmes, the next step is to align AI testing evidence with operational controls already used for privileged access and workload identity. The goal is not to add another silo, but to make AI behaviour measurable within the same governance model that already tracks high-risk access.

For practitioners

• Classify AI systems by access behaviour Inventory chatbots, copilots, and agents by whether they only generate text or can also call tools, read data, and invoke workflows. Any system using credentials, tokens, or delegated API access should be brought into NHI governance, with explicit ownership and revocation points. See the Ultimate Guide to NHIs , The NHI Market for the broader identity landscape.
• Demand adversarial evidence, not feature claims Evaluate AI pentesting platforms on whether they can demonstrate prompt injection chains, tool abuse, and validated exploit paths against realistic targets. Ask for recorded attack sequences, not just finding counts. Where possible, compare results against known AI attack patterns and baseline controls from the NIST SP 800-53 Rev 5 Security and Privacy Controls.
• Separate model risk from access risk in assessments Run AI security reviews in two layers: one for model behaviour such as jailbreaks and one for delegated access such as secrets, API permissions, and downstream tool action. That split makes it easier to decide whether a finding belongs with appsec, IAM, PAM, or the AI governance owner.
• Define revocation paths for AI credentials before launch If an AI system can use service accounts or tokens, establish who can disable those credentials, how quickly that happens, and what telemetry confirms the action. This is the same lifecycle discipline used for other non-human identities, just applied to a faster-moving runtime context.

Key takeaways

• AI pentesting is no longer just about scanning applications, because LLM-powered systems introduce behavioural attack paths that require adversarial simulation.
• The identity angle is now central, since AI tools and agents often depend on delegated credentials that must be governed like other non-human identities.
• Practitioners should judge platforms by attack-chain fidelity, revocation readiness, and evidence quality rather than by generic vulnerability counts.

Key terms

• Autonomous Offensive Testing: A testing approach that uses software-driven attack logic to explore systems the way an attacker would. It goes beyond static scanning by chaining steps, adapting to findings, and validating whether a weakness can actually be exploited in context.
• LLM Trust Boundary: The point at which an LLM stops being a text generator and starts influencing real system behaviour through prompts, retrieved data, or tool calls. Once that boundary is crossed, the security model must account for decision-making, not just content generation.
• Agent Manipulation: A class of attacks where an adversary influences an AI agent’s actions, timing, or tool use by shaping prompts, data, or execution context. The risk is not only bad output, but harmful actions taken through otherwise trusted integrations.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.

What's in the full article

Novee's full article covers the operational detail this post intentionally leaves for the source:

• The live RSAC context around how buyers are separating autonomous testing from legacy scanning labels.
• The specific demo flow for mapping an attack chain from a domain name to validated findings and remediation output.
• The buyer questions the vendor says matter most when comparing AI pentesting platforms.
• The conference sessions cited as market signals for where offensive AI security is heading.

👉 Novee's full post covers the RSAC market signals, AI testing demos, and buyer questions in more detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management for practitioners who need to control non-human access. It helps security teams align identity lifecycle discipline with emerging AI and automation risks.