Agent Frameworks vs Workflow Orchestration: Security

Many tasks now built as autonomous AI agents would be safer, cheaper and easier to audit as workflows in which code, not a language model, decides what happens next. A workflow orchestrator runs predefined steps in a fixed order and may call a model inside a step; an agent framework lets the model choose which tools to call, in what order and when to stop. That single difference changes how far prompt injection can reach, how wide the credentials must be, whether a run can be replayed for audit and how the system fails. This guide compares the two on determinism, auditability, injection exposure, credential scope and failure modes, gives controls for each, and sets decision criteria for where LLM-driven branching is worth allowing. It is for architects, AppSec engineers and AI platform teams deciding how much autonomy a use case really needs.

Key takeaways

The question is who controls the flow. In a workflow, code fixes the path and the model fills in steps; in an agent, the model decides the path at run time.
Start with the simplest thing that works. Anthropic's agent guidance and Microsoft's Agent Framework documentation both advise using a function or workflow where one will do, and an agent only when flexibility is genuinely needed.
Workflows bound injection to arguments, agents expose control flow. Injected text in a workflow can corrupt a value; in an agent it can also change which tools run, which is why NCSC treats prompt injection as a risk to design around, not filter away.
Autonomy widens credential scope. A workflow step needs only the permission for that step; an agent needs the union of everything it might decide to do.
Use bounded agents inside workflows. Most production designs put LLM branching in a narrow, well-instrumented node of a deterministic workflow, with approvals and limits around it.

The short answer

Choose workflow orchestration when the steps are known, the outcome must be repeatable or explainable to an auditor, and the system acts on high-impact resources. Choose an agent framework when the task is open-ended, the path cannot be written down in advance, and the cost of a wrong step is low or caught by a later control. In between, which covers most business processes, use a workflow that hands one bounded decision to a model: routing among fixed branches, or a small agent with a narrow tool set, an iteration limit and an approval gate before anything irreversible.

Workflow orchestration and agent frameworks side by side

Anthropic's engineering guidance defines workflows as systems where models and tools are orchestrated through predefined code paths, and agents as systems where models dynamically direct their own processes and tool usage. The LangGraph documentation draws the same line: workflows have predetermined code paths, agents define their own processes and tool use.

Dimension	Workflow orchestration	Agent framework (model-driven loop)
Who chooses the next step	Code or a declared graph	The model, at run time
Determinism	Path is fixed; model outputs inside steps still vary	Path and outputs both vary between runs
Replay and audit	Durable engines record an event history that can be replayed	Traces show what happened but cannot reproduce the decision
Prompt injection reach	Values passed between steps	Values and the choice of tools and order
Credential scope	Per step, known in advance	Union of every tool the agent can call
Typical failure	Wrong value, failed step, retry storm	Looping, unexpected tool use, goal drift, cost runaway
Testing	Path coverage like normal software	Scenario and adversarial evaluation; coverage is statistical
Cost and latency	Predictable	Higher and variable; Anthropic notes agents trade latency and cost for task performance

Microsoft's Agent Framework documentation gives a compact rule: use an agent when the task is open-ended or conversational and needs autonomous tool use and planning; use a workflow when the process has well-defined steps and you need explicit control over execution order. It adds that if you can write a function to handle the task, you should do that instead of using an AI agent.

The autonomy spectrum in practice

Real systems sit on a spectrum. The security bar rises as control of the path moves from code to model.

Pattern	Model's role	Injection can change	Minimum controls
Deterministic workflow, no model	None	Nothing via a model	Normal workflow and secrets hygiene
Workflow with model steps (prompt chaining)	Transforms content inside a step	Outputs of that step	Output validation, schema checks between steps
Model routing among fixed branches	Picks one of N predefined paths	Which allowed branch runs	Branches individually safe; fallback branch for low confidence
Bounded agent inside a workflow node	Plans within a small tool set	Tool choice within that set	Narrow tools, iteration and budget caps, approval before exit
Open agent loop	Decides tools, order and stopping	Anything its tools and credentials allow	Full agent control set: identity, policy, sandbox, kill switch

Anthropic's article lists prompt chaining, routing, parallelisation, orchestrator-workers and evaluator-optimiser as workflow patterns before reaching autonomous agents. Orchestrator-workers is the point where subtasks are decided at run time, so treat it as agent-grade for controls. The AI Agent Autonomy Levels Framework maps these levels to approval and monitoring requirements.

Threat model for each option

Workflow orchestration

Architecture in words: a scheduler or durable execution engine runs a defined graph. Each step is a task with its own connection or credential. Model calls are activities that return text or structured data, which the next step consumes. The path is fixed at deploy time and changes go through code review.

Corrupted values: an injected instruction in a document can still make the summarisation step produce a misleading summary or a wrong field. The damage is bounded to what downstream steps do with that value.
Orchestrator as a credential hub: the engine holds connections for every step, so compromise of the orchestrator is compromise of all of them. See the workflow orchestrator compromise playbook.
Over-broad shared connections: low-code automation tools often reuse one connection across many flows. The Top 10 Workflow Automation Security Risks covers these.
Brittleness pushed to people: rigid flows that fail on unusual input get bypassed by manual workarounds with wider access.

Agent framework

Architecture in words: a loop sends the goal, history and tool descriptions to a model; the model returns a tool call or a final answer; the framework executes the tool and appends the result; the loop repeats until the model stops or a limit is hit. Tool results, retrieved documents and messages from other agents all enter the same context that decides the next action.

Control-flow hijack: indirect injection in a tool result can redirect the agent to other tools. This is OWASP LLM01:2025 Prompt Injection and ASI01 Agent Goal Hijack in the OWASP Top 10 for Agentic Applications. See the AI Agent Goal Hijacking Guide.
Unexpected tool use: the model calls a tool the designer did not expect for this task, with valid credentials. OWASP LLM06:2025 Excessive Agency names excessive functionality, permissions and autonomy as root causes.
Looping and runaway cost: the loop repeats calls without converging, which OWASP LLM10:2025 Unbounded Consumption covers as denial of wallet.
Wide credential scope: the agent's identity must cover every reachable tool, so one hijacked run has the whole set.

NCSC argues that prompt injection may never be fully mitigated in the way SQL injection was, because models do not separate instructions from data, and recommends deterministic safeguards that constrain what the system can do. That is the security case for workflows: they are a deterministic safeguard on control flow.

Determinism and auditability

Durable execution engines make determinism an explicit contract. Temporal's documentation requires workflow code to make the same workflow API calls in the same sequence every time it runs, compares replayed commands with the recorded event history, and fails the execution with a non-determinism error on mismatch. External calls, including model invocations, belong in activities, which run outside the replay path and are retried.

For audit this gives three properties an agent loop does not: a complete, ordered record of which steps ran; proof that the path followed the reviewed code; and the ability to replay a run to investigate it. An agent trace records what the model chose, but rerunning the same input may produce a different path, so evidence must be captured at the time, in full, including model inputs and tool results. See the AI Agent Audit Trails for Regulators Guide for what to record.

Practical consequence: where a regulator, auditor or customer must be shown why a decision was taken, put the decision logic in code and use the model to produce inputs to it, not to make the decision path.

Credential scope

Aspect	Workflow orchestration	Agent framework
Grant unit	One connection or role per step	One identity covering all tools, unless tools are separately brokered
Known at design time	Yes, from the graph	Only the upper bound, from the tool list
Step that reads untrusted content	Can run with read-only or no credentials	Shares context with privileged tools unless separated
Delegated user access	Pass the user's token only to the step that needs it	Token available to the loop for every turn
Review	Per step, like any integration	Per agent and per tool, with policy at call time

To narrow an agent's scope, broker credentials per tool call instead of giving the loop a standing token, and enforce authorisation in the tool or downstream system. OWASP LLM06 calls this complete mediation: validate every request made through an extension against security policy rather than relying on the model to decide. See the Tool-Call Security for AI Agents guide.

Failure modes and controls

Failure mode	Workflow control	Agent control
Looping	Step retry limits with backoff; dead-letter queue	Iteration cap (LangGraph raises `GraphRecursionError` when `recursion_limit` is exceeded; its documented default is over 10,000 steps, so set a task-sized value), per-run token and cost budget
Unexpected tool use	Not possible outside the graph	Tool allowlist per task, policy check at call time, approval for high-impact tools
Injection in content	Schema validation of model outputs, constrained value sets	Separate the step that reads untrusted content from privileged tools; drop privileges after reading it
Wrong but plausible output	Business rule checks in code before acting	Evaluator step plus human review for consequential actions
Runaway cost	Predictable per-run cost alerts	Hard budget per run and per agent identity; see the Denial-of-Wallet and AI Agent Cost Runaway Guide
Stuck or harmful run	Cancel the workflow execution	Kill switch that revokes the agent's credentials; see the AI Agent Kill Switch and Containment Guide

Anthropic's guidance recommends stopping conditions such as a maximum number of iterations, and extensive testing in sandboxed environments with guardrails. Approval steps should be enforced by the runtime, not requested in the prompt; the Human-in-the-Loop for AI Agents Guide covers how.

Where to allow LLM-driven branching

Ask these questions for each decision point in a process. The more "yes" answers in the first group, the stronger the case for code; the second group justifies a model.

Keep the branch in code when:

the options can be enumerated and the rule for choosing can be written down;
the action is irreversible, financial, or changes access, configuration or production data;
the input that drives the decision comes from outside your trust boundary (email, web, uploaded files, other agents);
you must explain or replay the decision for an auditor or regulator.

Allow model branching when:

the input is unstructured and the right path depends on understanding it;
every reachable branch is individually safe, or ends in a human or deterministic check;
a wrong choice is cheap to detect and reverse;
the credentials available in that branch are limited to what it needs.

Where the input is untrusted and the action is consequential, use a pattern that stops untrusted text from choosing actions, such as a plan fixed before untrusted data is read or a dual-model split. The research paper "Design Patterns for Securing LLM Agents against Prompt Injections" states the principle that once an agent has ingested untrusted input it must be constrained so the input cannot trigger consequential actions. The Secure Agent Design Patterns Guide explains the six patterns and when to use each.

Small versus large organisations: a small team gains most by defaulting to workflows with model steps and adding agent loops only where a clear need exists, because each agent adds evaluation, monitoring and response work. Large organisations should publish a paved road: an approved orchestrator, a standard bounded-agent node with built-in limits and logging, and a review gate for open agent loops.

Worked scenario: IT service desk ticket handling

An IT team wants AI to handle incoming service desk tickets, including password resets, software requests and access requests. Tickets are free text from staff and sometimes forwarded email, so they are untrusted input.

Open agent design (rejected): one agent with tools to read tickets, reset passwords, install software and grant group membership. A forwarded email containing instructions could make it grant access; its identity needs all three admin permissions.
Workflow design (chosen): a model step classifies each ticket into one of five fixed categories with a confidence score and extracts fields into a schema. Code validates the fields against the directory.
Branches: password resets follow the existing self-service flow with identity verification; software requests go to a catalogue workflow with its own approval; access requests create a request in the governance tool for the manager to approve. Low confidence routes to a person.
Bounded agent node: a read-only troubleshooting agent drafts a reply using the knowledge base and device inventory. It has no write tools, a ten-step cap and a per-run budget, and a person sends the reply.
Result: the model still does the hard part (understanding free text), but no injected text can change which privileged action runs, each branch runs with its own narrow credential, and every privileged action has a replayable workflow record.

How to implement

Inventory: list existing agents and model-driven automations and record, for each, who controls the path, the tools reachable and the credentials held.
Classify decision points: apply the branching questions above to each, and mark which decisions move into code.
Refactor high-impact paths first: move irreversible and access-changing actions into deterministic workflow steps with approvals in the target system.
Bound remaining agents: set tool allowlists, iteration caps, budgets and per-tool credentials; run in a sandbox for anything that executes code.
Test: run adversarial cases with injected instructions in each untrusted input, in a non-production environment, and confirm that they cannot change privileged actions.
Roll out in rings: pilot with a single team, compare outcomes with the previous process, then expand. Keep the previous workflow or manual process available for rollback.

Where identity fits

Give the orchestrator and each agent their own non-human identity with an owner. In workflows, scope credentials per step and keep the orchestrator's credential store under the same controls as a secrets manager. In agents, separate the agent's identity from any user it acts for and broker per-call tokens. See the Agentic AI Identity Guide.

Detection and measurement

For workflows, log every execution with its path, step outcomes and the identity used per step, and alert on executions that start outside the normal trigger. For agents, log model inputs and outputs, every tool call with arguments, denied policy decisions and failed tool calls, which NCSC notes can reveal an attacker probing the system.

Autonomy share: percentage of high-impact actions decided by code rather than a model (target: rising).
Iteration profile: 95th percentile steps per agent run, and number of runs ending at the iteration cap.
Unexpected tool rate: tool calls outside the expected set for the task category.
Credential breadth: average number of distinct permissions available per agent run versus per workflow step.
Replayability: percentage of consequential decisions with a complete, replayable or fully captured record.

Framework mapping

Framework	Reference	Relevance
OWASP Top 10 for LLM Applications 2025	LLM01 Prompt Injection	Reach of injected text into control flow
OWASP Top 10 for LLM Applications 2025	LLM06 Excessive Agency	Excessive functionality, permissions and autonomy; complete mediation
OWASP Top 10 for LLM Applications 2025	LLM10 Unbounded Consumption	Loops and denial of wallet
OWASP Top 10 for Agentic Applications 2026	ASI01 Agent Goal Hijack, ASI02 Tool Misuse and Exploitation	Model-driven tool choice under attack
MITRE ATLAS	AML.T0051 LLM Prompt Injection, AML.T0053 AI Agent Tool Invocation	Technique view of injection and tool misuse
NIST SP 800-53 Rev. 5	AC-6 Least Privilege, CM-7 Least Functionality	Per-step credentials and narrow tool sets
NIST SP 800-53 Rev. 5	AU-12 Audit Record Generation, SI-4 System Monitoring	Execution records and agent monitoring
NIST CSF 2.0	PR.AA-05, DE.CM-09	Least privilege and monitoring of runtime environments

Common failure patterns

Instructions instead of controls: in the Replit AI agent database deletion 2025, a code freeze existed only as a chat instruction and an agent with production write access deleted live data. A workflow gate or a read-only production credential would have enforced it.
An agent where a router would do: giving a model a full tool set when the task only ever needs one of three known actions.
Treating the orchestrator as low risk: workflow engines hold more credentials than any single agent and need privileged-system controls.
No iteration or budget cap: relying on framework defaults sized for long-running graphs.
Logging only the final answer: without tool calls and inputs, an agent run cannot be reconstructed.

Practitioner checklist

For each AI use case, record whether code or the model controls the path, and justify any model-controlled branch.
Move irreversible, financial and access-changing actions into deterministic steps with approval in the target system.
Keep steps that read untrusted content away from privileged tools and credentials.
Scope credentials per workflow step and broker per-call tokens for agent tools.
Set explicit iteration caps, per-run budgets and timeouts on every agent loop.
Validate model outputs against schemas and business rules before any step acts on them.
Protect the orchestrator's credential store and admin interface as a privileged system.
Capture full execution records: workflow history, model inputs and outputs and every tool call.
Test with injected instructions in each untrusted input before release.

Agent Frameworks vs Workflow Orchestration: When Autonomy Is Worth the Risk