What breaks when agent workflows do not separate triage, planning, and review?

When these phases are collapsed, teams lose control over quality and accountability. A single agent can move too quickly from intake to implementation, skipping the checks that catch ambiguous requirements, risky changes, or incomplete fixes. Separating phases creates clearer decision points and makes it easier to stop unsafe work before merge.

Why This Matters for Security Teams

When triage, planning, and review are collapsed into one agentic workflow, the system stops behaving like a controlled delivery process and starts behaving like an automated change engine. That creates risk at three layers: the agent may misclassify the request, choose an unsafe implementation path, or approve its own output without meaningful challenge. The result is weaker change control, less reliable audit evidence, and a much smaller window to intercept bad decisions.

This matters because agent workflows often carry tool access, repository access, or ticketing authority that can translate a low-quality decision into a real-world action. Guidance from the NIST AI Risk Management Framework is clear that governance, measurement, and monitoring must be explicit rather than implied by the model or workflow design. The same logic appears in the OWASP Agentic AI Top 10, where over-permissioned agents, unsafe autonomy, and weak oversight are treated as distinct risk conditions.

In practice, many security teams encounter the failure only after an agent has already opened a bad pull request, executed a harmful remediation, or closed a ticket that never received real human review.

How It Works in Practice

A resilient workflow separates the work into distinct checkpoints. Triage determines whether the request is valid, complete, and in scope. Planning determines what should happen, which tools are allowed, and what the success criteria are. Review determines whether the proposed or completed action is safe, accurate, and consistent with policy before it is merged, deployed, or marked complete. That separation creates decision boundaries, which is where accountability becomes enforceable.

In practice, teams usually implement this with different permissions, different prompts, and different approval rules. A triage agent should not have the same execution authority as a planning agent, and neither should be able to self-certify final output. The workflow should capture evidence at each stage, including the original request, the plan, the commands or tool calls made, and the reviewer’s disposition. This is especially important where the agent can interact with code repositories, incident systems, or cloud APIs.

• Triage should filter out vague, duplicate, or out-of-policy requests before any tool use.
• Planning should translate the request into a bounded sequence of actions with explicit constraints.
• Review should validate correctness, side effects, and policy alignment before release.
• Logs should preserve who approved what, and at which stage the decision changed.

Where threat modelling is needed, the MITRE ATLAS adversarial AI threat matrix helps teams reason about prompt injection, tool abuse, and manipulation of agent decision points, while CSA MAESTRO agentic AI threat modeling framework is useful for mapping controls across orchestration layers. These controls tend to break down when a single agent is allowed to both draft and approve production changes in fast-moving environments, because the review step becomes procedural rather than preventive.

Common Variations and Edge Cases

Tighter workflow separation often increases latency and operational overhead, so organisations have to balance speed against the need for defensible control points. That tradeoff is real, especially in high-volume support or engineering pipelines where teams want automation to reduce queue time. Best practice is evolving, but current guidance suggests that autonomy should increase only after the surrounding review model has proven reliable.

There are several edge cases. Low-risk tasks, such as summarising internal tickets, may tolerate lighter review. High-risk tasks, such as privilege changes, production remediation, or security policy updates, need stronger separation and a human checkpoint. In partially automated systems, the review phase may be asynchronous, but it still needs to be independent. If the same agent generates the plan and signs off on the result, the control is functionally weak even if the interface looks formal.

The most important exception is when the workflow touches sensitive credentials, secrets, or privileged actions. In those cases, the agent’s ability to act should be narrower than its ability to reason. That aligns with the control intent of the NIST AI Risk Management Framework and the implementation emphasis in NIST SP 800-53 Rev 5 Security and Privacy Controls. In environments with compressed delivery cycles and broad tool permissions, these controls fail when teams optimise for throughput before they have proven that each phase is independently enforceable.

Related resources from NHI Mgmt Group

• What breaks when AI agent workflows can be edited outside AppSec review?
• What breaks when shadow MCP servers are allowed into agent workflows without review?
• What breaks when agent access is managed in a separate governance process?
• What breaks when risk findings stay separate from identity workflows?