TL;DR: Average agentic security tasks in ProjectDiscovery’s engineering data reached 26 LLM steps and 40 tool calls, while the same architecture stretched to 14.7 hours, 2,154 steps and 2,398 tool calls in one run, showing why single-agent loops break under long-running evidence work. Separation of planning, execution and verification makes duration and quality governable instead of accidental.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on ProjectDiscovery's blog post: Agentic security workflows move from a single sandboxed agent to plan, execute and verify phases as task length, context pressure and false-positive risk rise.
Why it matters: Identity and security teams building AI-driven tooling need governance that separates execution from verification, because long-running delegated work changes how scope, evidence and accountability must be controlled.
By the numbers:
- Average tasks hit 26 LLM steps and 40 tool calls.
- The same architecture carried single runs up to 14.7 hours, 2,154 steps and 2,398 tool calls.
Context
Agentic security work breaks the assumption that one loop can both investigate and decide. Long-running assessments produce evidence that is too large to keep in a single context window, and when verification is missing, false positives can slip through as if they were findings.
The architectural problem is not just scale, but governability. Once an agent can delegate work across time, tools and subagents, the organisation has to treat task scope, state transfer and result validation as first-class controls rather than implementation details.
ProjectDiscovery's evolution is a useful marker because its starting point was a single agent with a sandbox, which is a common early-stage pattern before programmes confront the limits of duration, context and quality.
Key questions
Q: What should teams do first when an AI agent needs long-running task execution?
A: Start with task decomposition: split the long-running goal into bounded steps, define the agent’s allowed tools and data, and assign a human owner for review and escalation. Give the agent short-lived credentials, explicit stop conditions, and checkpoints so execution can be paused, resumed, or revoked without losing control.
Q: Why do multi-agent systems need structured handoffs?
A: Multi-agent systems need structured handoffs so each agent passes state, intent, and constraints in a machine-readable form instead of relying on implicit context. That reduces dropped requirements, duplicated work, and unsafe scope creep, and it lets controls such as approval gates, audit logs, and role-based delegation track responsibility across agents.
Q: How does verification reduce false positives in agentic workflows?
A: Verification reduces false positives when a separate pass checks the agent’s output against source data, policy, or a second model before action is taken. That extra validation step catches hallucinated matches, stale context, and overconfident classifications, especially in workflows that trigger tickets, alerts, or access decisions.
Q: When should security teams choose an orchestrated agent over a single agent loop?
A: Choose an orchestrated agent when the work needs coordination across tools, branching steps, or multiple specialised agents under one control plane. A single agent loop fits narrow, self-contained tasks, while orchestration is better for enforcing approvals, retry logic, observability, and bounded delegation across longer workflows.
Technical breakdown
Why a single agent fails on long-running security tasks
A single agent loop depends on keeping enough history, tool output and decision state in one context window. That works for short tasks, but security assessments generate large evidence trails, repeated tool output and branching paths that do not compress cleanly. Summarisation and truncation can extend the loop briefly, yet they also risk dropping details that later matter for validation or reproduction. Once that happens, the agent often repeats work to recover missing context, which increases cost and noise rather than reducing it.
Practical implication: Design for bounded task scope and decide early where summarisation becomes an unsafe substitute for preserved working state.
How orchestrator and subagent delegation changes runtime control
An orchestrator-subagent model splits responsibility between task management and specialised execution. The orchestrator keeps context for planning, sequencing and aggregation, while subagents handle specific tool categories or workstreams with narrower prompts and shorter summaries. That separation extends the effective runtime because the orchestrator no longer carries raw execution detail, but it also creates a handoff problem: if subagents return incomplete summaries, the orchestrator cannot reliably reason about what happened. Structured exits and working memory become part of the architecture, not optional metadata.
Practical implication: Treat handoff structure and result schema as control surfaces, because delegation without reliable summaries creates hidden rework and loss of accountability.
Why planning and verification need separate phases in agentic workflows
Planning, execution and verification are different jobs. Planning explores the task, identifies missing information and maps dependencies; execution does the work; verification checks whether the work is complete and defensible. Conflating those jobs forces one prompt to optimise for speed, coverage and judgement at once, which is where false positives and missed steps appear. A verification phase can run dedicated checks, regenerate proof and decide whether another iteration is needed, which turns completion into an explicit control rather than an assumption.
Practical implication: Separate planner, worker and verifier responsibilities so a completion decision is based on evidence, not on the last action the agent took.
NHI Mgmt Group analysis
Plan, execute and verify is a governance pattern, not just an engineering pattern. Once delegated work can run for hours and fan out across specialised agents, the control question shifts from “can the agent do the task?” to “can the system prove the task was done correctly?”. That is a direct identity and authority problem because each subagent operates with scoped tool access and must return trustworthy state. Practitioners should treat phase boundaries, summaries and verification gates as governance primitives, not implementation footnotes.
Context pressure creates a new form of operational debt: evidence decay. The longer an agentic security task runs, the more likely important outputs will be summarised, truncated or re-requested. That makes the quality of state transfer as important as the quality of the model prompt. In practice, teams need runtime architecture thinking for agent workflows so that evidence, task scope and handoff state remain inspectable across the full run.
Specialised subagents reduce drift, but they also make trust distribution explicit. When one orchestrator delegates to many workers, each worker becomes a dependency that can fail silently if its summary is weak or its scope is mis-set. That is why the real design challenge is not parallelism alone, but containment plus verifiable handoff. Practitioners should expect to govern agent estates the way they govern other distributed systems, with state, boundaries and reviewability as first-class concerns.
Verification is the control that turns agent output into operationally safe output. Security work cannot rely on “seems right” because the cost of a false positive or missed issue is externalised into response, remediation and trust. The durable pattern is to separate generation from judgement, then require the verifier to prove why the result is acceptable before it leaves the system. That is the difference between autonomous output and governed automation.
Long-running agentic tasks expose a named concept: evidence decay. This is the point at which summaries, truncation and handoffs progressively weaken the chain of proof behind a security finding. The more a workflow depends on compressed state, the easier it becomes for errors to survive into the final answer. Practitioners should design for preserved evidence paths, not just faster execution.
From our research library:
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
- Read next: AI agent runtime reference architecture
What this signals
Evidence decay: the longer an agentic security task runs, the more likely summaries, truncation and repeated delegation will weaken the proof chain behind the final result. That changes programme design from simple automation to controlled evidence preservation, and teams should expect verification to become a standing operating requirement rather than a final polish step.
As agentic systems spread into security operations, the control plane has to move closer to task state, not just model prompts. Security programmes should expect more demand for durable working memory, scoped delegation and replayable verification because those are the mechanisms that keep long-running tasks trustworthy.
AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026. That reinforces the need to govern the infrastructure around agentic systems as carefully as the models themselves.
For practitioners
- Define hard phase boundaries for agentic workflows Separate planning, execution and verification into distinct runtime stages with different success criteria, budgets and exit conditions.
- Require structured handoffs between subagents Make every delegated worker return a fixed summary, evidence pointer and completion status so the orchestrator can reason about what happened.
- Preserve working state outside the model context Store plans, intermediate findings and verification artefacts in durable task state so long-running jobs do not depend on context window retention alone.
- Gate final output on an explicit verification pass Require a second-stage check that validates evidence, reproduces critical findings and confirms whether the original task was actually completed.
Key takeaways
- Agentic security workflows break down when one loop is asked to investigate, decide and verify at the same time.
- The strongest evidence from this architecture is that longer runs require explicit phase boundaries, not just more model calls.
- Practitioners should treat verification, handoff structure and durable state as controls that shape trust in agent output.
Related NHI Mgmt Group resources: AI agent runtime reference architecture · Multi-Agent and A2A Security Guide · Know Your Agent (KYA) Guide · AI Agent Sandboxing and Code Execution Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST AI RMF sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Delegated subagents and scoped tool access create identity and privilege boundaries that this architecture must govern. |
| ASI08 — Cascading Failures | Compounding errors across planning, execution and verification fit the cascading-failure model in agentic systems. | |
| ASI10 — Rogue Agents | Independent subagents and delegated execution require controls that keep workers inside intended scope. | |
| Recommendation — Constrain delegated agent authority and verify every scoped handoff before execution continues. Design containment between phases so one weak worker does not corrupt the whole task flow. Limit autonomous worker scope and monitor for execution paths that drift beyond assigned intent. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The plan-execute-verify model is fundamentally about governance, accountability and decision traceability in AI operations. |
| Recommendation — Establish accountability, review gates and evidence retention for each phase of the agent workflow. | ||
Key terms
- Agentic workflow: An agentic workflow is a sequence of tasks executed by an AI agent with some level of tool access and decision authority. In security terms, the workflow matters because it can span multiple systems, identities, and permissions, which makes attribution and revocation harder than with ordinary automation.
- Orchestrator: The control plane that routes messages, stores workflow state, and manages tool access across multiple AI agents. Because it concentrates delegation and logging in one place, it becomes the highest-value identity surface in the system and needs privileged-service treatment, not ordinary application handling.
- Verification loop: The cycle in which an agent takes an action, sees the result, and adjusts its next move. In autonomous or semi-autonomous workflows, the loop is the real control boundary, because it determines how quickly an identity can iterate without human review.
- Evidence Decay: Evidence Decay is the weakening of proof or confidence over time as source data, logs, attestations, or context become stale. In AI governance it refers to evidence that no longer reliably supports a model output, agent action, or risk decision because the underlying conditions have changed.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.
Published by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org