How should teams structure offensive testing when AI agents can cover more of the estate continuously?

How to split continuous offensive testing between agents and humans

Continuous offensive testing works best as a division of labour, not a replacement exercise. AI agents should run the always-on baseline: broad discovery, repeatable exploit validation, regression checks after changes, and coverage across large estates. Human testers stay on the harder work, where context, judgment, and creativity matter most, especially when a finding only becomes real after understanding business logic, trust relationships, or how people respond under pressure.

The practical advantage is cadence. Agents can keep probing the estate between scheduled human engagements, so testing becomes an operating control rather than a periodic event. That improves detection of drift, newly exposed paths, and regressions introduced by configuration or code changes. Human effort then becomes more valuable because it is reserved for tests that change based on what the environment, business process, or attacker objective actually looks like.

Teams should think in terms of test classes, not tool classes. Some scenarios are well suited to machine execution because they are deterministic and measurable, such as service reachability, exposed interfaces, known exploit chains, authentication workflow checks, and retesting known issues after remediation. Others are inherently interpretive, such as chaining weak controls into a meaningful attack path, probing for abuse of business rules, and simulating social engineering where the important signal is how people and process interact with the technology.

Where agents add the most value in offensive programmes

Agents are strongest when the objective is coverage, frequency, and consistency. They can enumerate assets continuously, validate whether a previously observed weakness still exists, and retest standard exploit patterns after every release or infrastructure change. That makes them useful for security regression testing, large-scale discovery, and the steady confirmation that expected controls still behave as intended.

That kind of testing is most effective when the rules are explicit and the pass/fail criteria are stable. If a test requires only a bounded sequence of actions and produces a clear evidence trail, an agent can usually perform it more cheaply and more often than a human. Agent observability and audit logging matter here because continuous testing only helps if teams can attribute what the agent did, what changed, and what remains unverified.

Agents also make sense when the estate is too large for periodic manual coverage alone. A continuous programme can keep scanning and validating paths that would otherwise age out between assessments. The important boundary is that the agent is proving what can be repeated and measured, not claiming to understand whether a weakness is exploitable in the real business context.

What still needs human testers, even in a highly automated programme

Human testers should own the edge cases that depend on interpretation, sequencing, or social context. This includes novel attack reasoning, business logic abuse, chained weaknesses across multiple controls, and any scenario where the meaningful question is not “does the exploit work?” but “what would a real attacker do with partial access and discretion?” Those cases usually require a tester to adapt to the environment rather than follow a fixed playbook.

Human-led work is also essential when offensive testing touches trust boundaries. A test may succeed technically but still miss the real risk if it ignores authorisation scope, delegated access, or how a user would be induced to grant consent. For agent-heavy environments, that often means testing the governance layer as much as the application layer. AI agent authorisation becomes part of the offensive question when the attack path depends on excess privilege, weak approval gates, or overbroad delegated access.

Social engineering remains human-led for a simple reason: the control objective is behavioural, not just technical. A scripted agent can assist with reconnaissance or message generation, but it cannot reliably replace a tester who adapts tone, pressure, timing, and pretext to the target organisation. The same is true for business logic testing, where the exploit often lives in the process rather than the software.

Practitioner Guidance

What to prioritise: Build a queue where agents own high-volume repeatable tests first, then escalate only the findings that require interpretation or multi-step reasoning to humans. That keeps expert time focused on attack paths that change the risk picture, not on re-running checks a machine can already confirm.

What to verify: Make sure the automated baseline has clear evidence requirements, bounded permissions, and a defined stop condition. If an agent can prove a finding but cannot explain its blast radius or business significance, the handoff to a human tester should be immediate.

Common mistake: Treating automation as a coverage metric instead of a decision support layer. More agent activity does not automatically mean better offensive testing if the programme stops short of the scenarios that actually reveal abuse potential.

Practitioner takeaway: The best structure is continuous machine-driven validation plus selective human red teaming, with the handoff determined by judgment complexity, not by who found the issue first.

Related resources from NHI Mgmt Group

• How should security teams manage permissions for AI agents?
• How should teams govern AI agents that use MCP?
• How should security teams govern AI agents that use OAuth access?
• How should security teams limit the risk from AI agents that have access to production systems?