Should organisations replace manual pentests with agentic testing?

Why This Matters for Security Teams

Replacing manual pentests outright creates a false sense of assurance. agentic testing can run more often, traverse more paths, and emulate common attacker workflows at a pace humans cannot match, but it does not remove the need for scoping, escalation judgement, or business-context interpretation. That is especially true where findings affect safety, regulated data, or production identity systems. Guidance from the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 both point to governance, validation, and accountability as core requirements, not optional extras.

The key mistake is treating testing automation as equivalent to independent assurance. Agentic tools are only as good as their objectives, permissions, guardrails, and target inventory. They can find exposed services, weak controls, and predictable misconfigurations quickly, but they can also miss chained logic flaws, environment-specific exceptions, and failures that depend on human decision-making. They may also generate noisy or partially correct findings that need expert triage before they become actionable remediation work.

In practice, many security teams encounter the limits of agentic testing only after a real incident or a failed audit reveals that coverage was broad but judgement was thin.

How It Works in Practice

The hybrid model is the most defensible approach. Agentic testing is used to increase frequency, expand coverage, and validate that baseline controls still behave as expected after changes. Human pentesters then focus on chained exploitation, novel attack paths, boundary conditions, and whether a finding is actually material to the organisation. This aligns with the direction of current guidance: automate repeatable checks, but keep accountability and sign-off with qualified people.

A practical workflow usually looks like this:

• Define the test scope, authorisation boundaries, and prohibited actions before any agent is allowed to act.
• Constrain tooling to safe targets, approved credentials, and approved execution windows.
• Use the agent to enumerate assets, validate known control failures, and reproduce routine weakness patterns.
• Route uncertain, high-impact, or potentially destructive results to human reviewers.
• Correlate outputs with logging, SIEM, and vulnerability management evidence so findings are defensible.

For agentic and AI-enabled attack scenarios, mapping test cases to MITRE ATLAS adversarial AI threat matrix and the CSA MAESTRO agentic AI threat modeling framework helps teams avoid generic checks that do not reflect real misuse paths. If the environment includes LLMs or autonomous tooling, pentest design should also account for prompt injection, tool abuse, data exfiltration through outputs, and weak privilege boundaries. Those are not just AI concerns; they are control-plane concerns when agents can call APIs or trigger workflows.

The strongest programmes also validate how quickly remediation closes the loop. A high-frequency agent can verify a patch or configuration change within hours, while a human tester can assess whether the fix introduced a new exposure elsewhere. These controls tend to break down when the environment is highly dynamic, poorly inventoried, or full of exception-based access, because the agent cannot reliably distinguish intended complexity from exploitable weakness.

Common Variations and Edge Cases

Tighter automation often increases operational overhead, requiring organisations to balance speed and breadth against safety, false positives, and governance burden. That tradeoff becomes more pronounced in production systems, critical infrastructure, and environments with strong change-control requirements. In those settings, best practice is evolving rather than settled, especially for autonomous exploit execution and agent permissions.

There is no universal standard for when an agent may move from validation to active exploitation. Many teams therefore limit agentic tooling to low-risk checks unless a human explicitly approves a deeper phase. This is sensible where business disruption is unacceptable, where targets include production identity or secrets stores, or where access to third-party systems could create legal or contractual issues. The question is not whether the agent can run a test, but whether the organisation can explain and defend every action it took.

For regulated programmes, use NIST SP 800-53 Rev 5 Security and Privacy Controls to anchor authorisation, logging, separation of duties, and incident response around the testing platform itself. Where AI-specific decision support is involved, the NIST AI Risk Management Framework remains the right lens for provenance, accountability, and output validation. Manual pentests still matter most when the scenario depends on human judgement, novel chaining, or nuanced interpretation of blast radius.

Related resources from NHI Mgmt Group

• Should organisations replace static secrets before adopting more agentic workflows?
• Should organisations replace manual abuse mailbox review with AI-driven response?
• When should organisations use manual testing instead of automation for logic flaws?
• Should organisations replace playbooks with agentic AI investigations?