Should organisations sandbox every risky LLM workflow or redesign it first?

Redesign first when the dangerous function is not essential, because removing the feature is stronger than containing it. Use sandboxing when external execution, file access, or other high-risk operations are genuinely required. In either case, pair the design choice with minimal permissions and explicit limits on runtime behaviour.

Sandboxing is a containment choice, not a design substitute

When an LLM workflow can be simplified or de-risked by removing the dangerous capability, redesign is usually the stronger move. Sandboxing is valuable when the workflow truly needs external execution, file handling, browsing, code generation, or other high-risk actions, but it only limits blast radius. The practical question is whether the risky step is essential to the business outcome, because if it is not, containment adds complexity without eliminating the failure mode.

That distinction matters because agentic workflows can move from “assistive” to “actionable” very quickly. The AI Agents: The New Attack Surface report notes that 80% of organisations report AI agents have already performed actions beyond their intended scope, which is a strong signal that scope creep is already happening in real deployments. If the workflow can be redesigned so the model only recommends, drafts, or classifies, the control problem becomes far smaller.

In practice, teams usually discover the need for sandboxing only after the workflow has already been allowed to touch systems it should never have reached.

How to decide what stays in the workflow and what gets isolated

The right sequence is to remove unnecessary capability first, then sandbox only the remaining high-risk function. A safe workflow usually separates “reasoning” from “action”: the model can propose a step, but a narrower execution layer decides whether that step is permitted, what it can access, and how far it can reach.

Keep the model away from direct production actions unless that access is genuinely required.
Use sandboxing for browser sessions, code execution, document parsing, or third-party tool calls that could expose data or trigger side effects.
Restrict the sandbox to the minimum files, network paths, and tokens needed for the task.
Log prompts, tool calls, outputs, and permission failures so reviewers can reconstruct what happened.
Prefer short-lived access and explicit approval for irreversible steps such as deletion, payment, or data export.

This is where current guidance is converging: the best designs treat sandboxing as a boundary around a necessary action, not as permission to let an otherwise unnecessary action remain in place. The OWASP Top 10 for Agentic Applications 2026 is useful here because it frames agentic risk around excessive autonomy, unsafe tool use, and weak control over action scope. Where the workflow must touch live systems, pair the sandbox with explicit guardrails rather than assuming isolation alone will stop misuse.

For workflows that use external tools, the execution environment should be treated as part of the trust boundary. That means separate credentials, limited network egress, and a clear distinction between read-only tasks and anything that can mutate data or trigger workflow state changes. The NIST AI Risk Management Framework is helpful because it pushes organisations to manage AI risk through governance, measurement, and monitoring rather than relying on one technical control. These controls tend to break down when developers give the sandbox broader network access than the workflow actually needs.

Common edge cases where both approaches are needed

Tighter sandboxing often increases operational overhead, so organisations must balance safety against latency, complexity, and supportability. In some cases, a workflow is essential but still too dangerous to expose fully, which means redesign and sandboxing need to work together rather than compete.

Common edge cases include workflows that must browse the web, process untrusted files, execute code snippets, or call internal APIs on behalf of users. In those cases, redesign should remove any unnecessary write access, while sandboxing contains what cannot be removed. The main mistake is assuming that a heavily restricted sandbox makes an unsafe workflow acceptable when the underlying business process could have been restructured to avoid the risk entirely. The CSA MAESTRO agentic AI threat modeling framework is a useful lens when the workflow includes multi-step tool use, because the threat comes from the sequence of actions, not just the model output.

Practitioner takeaway: redesign is the default for optional risky behaviour, while sandboxing is the fallback for necessary high-risk actions that cannot be removed without breaking the use case.

Risk and Threat Considerations

The material risk is overexposure of tools, data, and execution rights when an LLM workflow is allowed to act too broadly. Once a workflow can browse, execute, or manipulate files, prompt injection, unsafe tool selection, and scope creep can turn a helper into an abuse path.

Failure mechanism: The workflow inherits more authority than the task requires, then a malicious prompt, malformed input, or ordinary model error steers that authority into unintended actions. Sandboxes reduce blast radius, but they do not remove the dangerous capability or guarantee that the model will stay within intended behaviour.

Impact: Sensitive data exposure, unauthorised actions, uncontrolled external calls, and difficult-to-audit behaviour can follow, especially when the workflow can reach production systems or handle secrets.

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 address the attack and risk surface, while NIST AI RMF, CIS Controls v8 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	A1 — Excessive Agency	Covers risky LLM workflows that can act beyond intended scope.
	A4 — Insecure Tool Usage	Applies when workflows use external tools, code, files, or browser access.
	A10 — Improper Output Handling	Relevant when workflow output can trigger unsafe downstream actions.
Recommendation — Limit agent authority so only necessary actions remain available. Constrain tool access and validate every external action path. Treat model output as untrusted before any execution or write step.
NIST AI RMF	GV — Govern	Supports governance decisions on whether a risky workflow should exist at all.
	MAP — Map	Helps identify where risky workflow capabilities and boundaries exist.
	MEASURE — Measure	Applies to monitoring sandbox behaviour and residual risk over time.
Recommendation — Establish approval criteria for redesign versus containment decisions. Map workflow inputs, outputs, tools, and trust boundaries before deployment. Measure permission scope, misuse signals, and containment effectiveness continuously.
CIS Controls v8	6 — Access Control Management	Supports least-privilege access for sandboxes and execution environments.
	8 — Audit Log Management	Needed to reconstruct tool calls and unsafe actions in LLM workflows.
Recommendation — Restrict permissions to the minimum required for each workflow step. Log prompts, tool actions, and permission failures for review and response.
NIST Zero Trust (SP 800-207)	SC-2 — Session Integrity	Relevant when runtime actions must stay bounded inside a trusted session.
Recommendation — Bind each session to explicit policy and re-evaluate access continuously.

Practitioner Guidance

What to prioritise: Decide whether the risky function is actually necessary before designing the containment layer. If the workflow only needs to summarise, classify, or draft, remove execution, browsing, or write access entirely rather than sandboxing a capability that should not exist.

What to verify: Confirm that the sandbox is narrow enough to block privilege expansion, not just obvious misuse. Verify network egress, file scope, tool permissions, and whether any secrets or production tokens are available inside the environment.

Decision rule: If the workflow can be rebuilt so the model proposes actions while a separate control plane performs them, do that first. If external execution is essential, keep the sandbox, but treat approval, logging, and short-lived permissions as mandatory design elements.

Practitioner takeaway: the safest pattern is not “sandbox everything,” it is “remove avoidable danger, then tightly contain what must remain.”