Recommend-only workflows let the agent analyse a request and suggest an action without execution rights. Approval-based workflows allow the agent to carry out the change only after a human authorises it. The practical difference is accountability: recommendation tests judgement, while approval-based execution tests both judgement and control over the actual change.
How the two workflow models split judgement from execution
Recommend-only and approval-based workflows both give an agent a role in deciding what should happen, but they draw the execution boundary in different places. Recommend-only is advisory: the agent can assess the request, gather context, and propose an action. Approval-based workflows add a second step where a human authorises the action before the agent or system carries it out, which changes the workflow from advice into controlled execution.
The distinction matters because the same model can be used for very different operating assumptions. A recommendation workflow is appropriate when the organisation wants the agent to surface options, rank outcomes, or draft a decision for a person to review. An approval workflow is appropriate when the organisation is willing to let the agent act, but only within a governed path where the human decision is the final gate.
That difference shows up in how trust is assigned. In a recommend-only design, the main question is whether the agent’s judgement is good enough to be useful. In an approval-based design, the question becomes whether the approval process is strong enough to bound the agent’s authority and prevent an unsafe change from slipping through after a superficial review. The AI Agent Authorisation Guide is useful here because it frames per-action control as a practical boundary, not just a policy statement.
Approval-based workflows also sit closer to delegated authority. If the agent can make a change after approval, you need to know exactly what the approval covers: one action, one scope, one time window, or one class of operation. The Agentic AI Identity Guide helps explain why the identity and delegation model matters once the workflow moves from suggestion to execution.
Why approval-based workflows raise the operational bar
Recommend-only workflows usually concentrate risk in decision quality. If the agent is wrong, the damage is indirect: a human may follow a bad recommendation, but the agent has not changed the environment itself. Approval-based workflows create a stronger operational obligation because the agent is now part of the control path for making real changes. That makes the approval step a security control, not just a user interface choice.
This is where accountability changes. A recommendation can be judged on usefulness, explainability, and consistency. An approval-based change must also be traceable, attributable, and reversible if the action turns out to be wrong. The practical standard is not whether the agent seemed sensible in hindsight, but whether the approval decision was informed, bounded, and recorded well enough to defend the change.
Because of that, approval-based workflows demand stronger logging and stronger separation between recommendation and execution. The AI Agent Observability, Audit and Incident Response Guide is relevant because approval only helps if you can reconstruct what the agent intended, what the approver saw, and what actually executed.
For agentic systems, the broader security lesson is that approval does not neutralise bad design. If the agent has excessive scope, poor isolation, or weak change controls, human approval becomes a thin layer over a risky execution path. The Zero Trust for AI Agents guide reinforces the point that standing privilege should be removed and each action should be evaluated on its own merits.
When to use each model in practice
Use recommend-only when the value of the agent is analysis, not action. That suits triage, drafting, ranking, summarising, or proposing options where the human must still make the final call. It is the safer default when the request is ambiguous, the blast radius is hard to estimate, or the organisation is still learning how reliably the agent behaves.
Use approval-based workflows when the organisation wants the agent to carry out well-defined operational work, but only under a human gate that confirms the action is acceptable. This model is stronger when the change is routine enough to be delegated, but important enough that an explicit authorisation should still be required. The most important design question is whether the approver can genuinely judge the specific action, or is merely rubber-stamping the agent’s recommendation.
That distinction becomes sharper when the agent can reach production systems, customer data, financial workflows, or identity and access controls. In those cases, approval should not be a vague sign-off. It should be tied to a specific request, a specific scope, and a clear record of who authorised what. The Agentic AI Security Guide is a useful companion because it treats tool use, orchestration, and identity as part of the same risk surface.
The most important implementation choice is to keep recommendation and execution visibly separate. If a system presents a recommendation and then quietly acts as though it were approved, the workflow has collapsed into an unsafe hybrid. Approval-based workflows only improve governance when the approval is explicit, meaningful, and technically enforced.
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 SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Applies because approval-based agent execution depends on controlling agent authority. |
| ASI02 — Tool Misuse | Relevant because approval workflows must constrain what tools the agent can invoke after approval. | |
| Recommendation — Enforce per-action authorization and limit agent privilege to the approved scope. Restrict tool access to the minimum functions needed for each approved action. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Directly supports limiting what an agent can do when execution is approved. |
| AU-2 — Event Logging | Relevant because approval-based execution needs auditable traces of requests and actions. | |
| Recommendation — Apply least privilege to bound agent actions to the minimum necessary access. Log approval decisions, executed actions, and actor attribution for review. | ||
| NIST Zero Trust (SP 800-207) | SC-2 — Zero Trust Architecture | Applies because each agent action should be evaluated and authorized before execution. |
| Recommendation — Verify each agent action explicitly before allowing state-changing execution. | ||
Practitioner Guidance
Decision rule: If the agent can only advise, optimise for decision quality and explanation. If the agent can change state, optimise for bounded authority, auditable approval, and reversibility before you worry about automation speed.
What to verify: Confirm that the approver is authorising a concrete action, not a broad intent. The request, scope, and target system should be visible at approval time, and the approval should expire if those details change.
Common mistake: Treating approval as a UI click rather than a control. A workflow is not meaningfully approval-based if the approver cannot see the exact change or if the agent can execute outside the approved scope.
Practitioner takeaway: Recommend-only workflows test whether the agent’s judgement is useful; approval-based workflows test whether the organisation can safely delegate execution without surrendering control of the change itself.
Related resources from NHI Mgmt Group
- What is the difference between human identity governance and AI agent governance?
- What is the difference between governing human access and governing AI agent access?
- What is the difference between managed identities and hardcoded secrets for AI agents?
- What is the difference between workload identity and API keys for AI agents?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org