Human judgment and agent execution are reshaping pentesting

At a glance

What this is: This is an analysis of how agentic systems are changing pentesting by combining autonomous execution with human accountability and preserved execution traces.

Why it matters: It matters because security teams need to decide where human approval, auditability, and rules of engagement must stay in place as offensive tooling becomes more agentic.

By the numbers:

• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.

👉 Read terra's analysis of human judgment and agent execution in pentesting

Context

Agentic pentesting is the use of software systems that can explore an application, vary inputs, observe responses, and continue testing based on what they learn. The core governance problem is not whether automation can find known issues. It is whether agent execution can be bounded tightly enough to preserve safety, accountability, and evidentiary quality when the tooling starts behaving more like a researcher.

That shift has an identity angle because the moment an automated system can exercise authenticated flows, replay sessions, or act within a defined rules of engagement, it begins to resemble a non-human identity with delegated authority. For IAM and PAM teams, the question is no longer just who has access. It is what degree of decision-making an agent can exercise before a human must approve the next step.

The starting point described here is increasingly typical in mature offensive security programmes: human judgment remains the deciding factor, but agent execution carries more of the repetition and exploration workload. That balance is becoming the operating model rather than the exception.

Key questions

Q: How should security teams govern agentic pentesting tools in production-like environments?

A: Treat them as delegated systems with explicit scope, named ownership, and approval checkpoints. The control objective is not to stop automation, but to ensure that any step affecting production stability, compliance, or rules of engagement requires a human decision before execution continues.

Q: How do IAM and PAM teams support agentic pentesting safely?

A: They should issue dedicated test identities, limit privilege to the minimum required for the assessment objective, and log every context grant as if it were production access. The testing platform should never inherit broad standing access just because it is being used for security work.

Q: What do security teams get wrong about automated compliance workflows?

A: They often assume the workflow itself is the control. In practice, the control is the combination of entitlement data, review logic, exception handling, and documented follow-through. If any of those pieces are weak, automation only accelerates the production of incomplete evidence.

Q: Who is accountable when an agentic test crosses a rules-of-engagement boundary?

A: The accountable party is the human or team that authorised the scope and allowed the next step to proceed. Regulated environments need clear decision ownership, because saying that an agent acted on its own is not a defensible accountability model.

Technical breakdown

How agentic pentesting executes authenticated workflows

Agentic pentesting differs from scripted scanning because the system can follow multi-step authenticated paths, observe state changes, and choose the next action based on what it sees. That lets it test behaviours across sessions, endpoints, and parameter combinations instead of only checking static signatures or known CVEs. The important technical point is that execution is iterative and stateful. The agent is not merely sending requests. It is building a path through the application, preserving what happened, and deciding where to probe next. This is why the model surfaces issues that classic automation misses, especially in workflow abuse and sequence-dependent failures.

Practical implication: teams need traceable test execution and explicit authorization boundaries for agent-driven offensive testing.

Human-on-the-loop control and rules of engagement

The article's central control idea is that the agent may execute, but human judgment decides when execution can continue after a risk threshold is reached. In practice, that means the workflow must surface guardrails for production stability, scope, and compliance, rather than assuming a tool can self-govern. This is conceptually closer to delegated access with enforced approval points than to fully autonomous operation. The accountability layer matters because regulated environments need a defensible record of who allowed a test to proceed, what was observed, and why a decision was made.

Practical implication: define approval checkpoints before deploying agentic testing into live or regulated environments.

Execution traces as evidence, not just telemetry

A preserved execution trace is more than logging. It is the record that shows how the agent reached a signal, which requests were modified, which endpoints were exercised, and which conditions produced the result. That makes the trace useful for triage, retesting, and auditability. Without that evidence, an offensive finding can be hard to reproduce and even harder to defend in a regulated setting. The architecture therefore combines exploration with evidentiary discipline, which is why the model is attractive to security teams that need both coverage and accountability.

Practical implication: require execution traces that can be reviewed, reproduced, and tied back to a named decision owner.

Threat narrative

Attacker objective: The objective is to identify and validate exploitable application behaviour faster than conventional tooling can, while preserving enough evidence to support responsible remediation.

1. Entry occurs when an agentic pentest tool gains authorised access to an application and begins replaying real user workflows.
2. Escalation occurs when the system mutates parameters, tests variations across endpoints, and discovers paths that human testers would normally find only after extended manual exploration.
3. Impact occurs when the tool validates an exploitable condition without breaching scope, while the human-on-the-loop framework determines whether the finding can be acted on safely.

NHI Mgmt Group analysis

Human judgment is becoming the control plane for offensive AI. Once a testing system can explore, adapt, and validate paths independently, the key governance question shifts from coverage to authorization. The useful boundary is not whether the tool can run, but when it must stop and ask a person to decide. Practitioners should treat human approval as a first-class control, not a procedural afterthought.

Agentic pentesting creates a new form of delegated non-human access. The system is not a passive scanner, because it can operate inside authenticated flows and pursue follow-up actions based on prior results. That makes its access model closer to an NHI with scoped authority than to a simple utility script. IAM and PAM teams should recognise the identity dimension and govern it with explicit scope, approval, and revocation logic.

Execution traces are now part of security evidence. When an offensive system can preserve every request, mutation, and conditional branch, the trace becomes the audit artefact that justifies the finding. This strengthens defensibility, but only if the trace is complete and tied to accountable decisions. Security programmes should treat trace quality as part of the control framework, not just a convenience feature.

Continuous validation is pushing pentesting toward an always-on operating model. The value is not just speed. It is that agent execution can revisit the same paths after every deployment and keep the test surface current. That reduces the gap between change and assurance, but it also raises the bar for change control and test governance. Teams should expect offensive validation to look more like continuous control testing over time.

Agentic offensive tooling will force clearer policy boundaries around production systems. If a tool can act before a human reviews every step, the environment must already define what it may touch, what it may not, and when escalation is mandatory. The market is moving toward accountable automation, not unconstrained autonomy. Practitioners should update rules of engagement, approval models, and evidence requirements together.

What this signals

Delegated offensive execution will push more security tooling into NHI territory. The practical change is that teams will need to govern software that can authenticate, explore, and act within a bounded workflow. That requires ownership, scope enforcement, and revocation logic that look much more like NHI governance than traditional scanner administration.

Continuous validation will raise the value of traceable decisions over raw throughput. As agents take on more repetition, security leaders will care less about how many checks ran and more about whether each high-risk branch had a defensible approval path. That makes evidence quality a programme metric, not a forensic afterthought.

Agent-driven testing also creates a clearer link between offensive assurance and identity controls, especially where authenticated flows, secrets, and session replay are involved. Teams that already struggle with non-human identity visibility should expect the same governance gaps to appear in their offensive tooling unless access boundaries are formalised.

For practitioners

• Define approval gates for agent execution Set explicit checkpoints for when an agent can continue, especially after it reaches production-like endpoints, authentication boundaries, or risky parameter changes. Approval should be tied to scope, not just session time.
• Treat offensive agents as scoped non-human identities Assign least-privilege access, named ownership, and revocation paths for testing systems that can operate inside authenticated workflows. Align the access model with PAM and NHI governance rather than ad hoc tool permissions.
• Require replayable execution traces Capture the full request sequence, parameter mutations, and decision points so findings can be reproduced and reviewed later. Without that trace, regulated teams may have a finding but lack the evidence to defend it.
• Align rules of engagement with change management Update offensive testing policies when application changes alter authentication flows, workflow depth, or production exposure. That keeps agent coverage useful without letting the tool drift beyond its approved test boundary.

Key takeaways

• Agentic pentesting changes the control problem from scan coverage to decision governance.
• Preserved execution traces make offensive findings more defensible, but only if approval points and scope limits are explicit.
• As offensive tools become more autonomous, they should be governed like scoped non-human identities with clear ownership and revocation paths.

Key terms

• Agentic Pentesting: An approach to penetration testing that uses AI-driven systems to support planning, execution, or interpretation of tests. The key issue is not automation by itself, but whether the environment provides enough context for the output to be accurate, prioritised, and operationally useful.
• Human-in-the-loop incident control: Human-in-the-loop incident control is the practice of requiring a person to validate the agent’s diagnosis or proposed change before remediation happens. For production operations, it is the boundary that keeps diagnostic assistance from turning into unsupervised action.
• Runtime Trace: A runtime trace is the record of an AI system’s prompts, decisions, tool calls, memory access, and outputs while it is operating. Security teams use it to understand what the agent did, why it did it, and whether the action stayed inside policy boundaries.
• Rules of engagement: The commercial and operational boundaries that define who can pursue, own, and support an opportunity. In identity programmes, these rules matter because unclear ownership can create remediation gaps, split accountability, and inconsistent customer support during deployment.

What's in the full article

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

• How TORCH separates ambient agents from on-demand co-pilot agents in active research workflows.
• The researcher review flow for execution traces, request mutations, and step-by-step validation.
• The operating model for deciding when an agent may continue versus when human accountability must intervene.
• The way the platform is positioned for continuous validation across deployments and code changes.

👉 The full terra article covers TORCH's operating model, execution traces, and researcher control flow

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need to connect identity controls to real operational risk across modern security programmes.