# Azure Logic Apps Adds Sandboxed Code Interpreters to Agent Workflows > Source: > Published: 2026-05-27 09:45:00+00:00 Microsoft has [introduced code interpreters for Azure Logic Apps](https://techcommunity.microsoft.com/blog/integrationsonazureblog/introducing-code-interpreters-for-logic-apps/4519880), enabling AI agents within Logic Apps workflows to generate and execute Python, JavaScript, C#, and PowerShell code in Hyper-V isolated sandboxes. The code interpreters run as tools within the Logic Apps agent loop, meaning an LLM can receive a natural-language instruction, generate code to fulfill it, execute that code in a secure sandbox, and return the results, all within a single governed workflow. The capability is powered by Azure Container Apps (ACA) dynamic sessions. Each code interpreter session runs in its own Hyper-V boundary, a hardware-level isolation primitive that Microsoft also uses for its own untrusted workloads. When network isolation is enabled on the ACA session pool, data never leaves the defined network boundaries. The Logic Apps team [writes](https://techcommunity.microsoft.com/blog/integrationsonazureblog/introducing-code-interpreters-for-logic-apps/4519880): This brings the power of a code interpreter, similar to ChatGPT's advanced data analysis tool, right into the Logic Apps runtime. Instead of writing code or manually manipulating spreadsheets, users can now describe their intent in natural language and get executable results within the same workflow. The practical use case is straightforward. An enterprise has sales data in a spreadsheet. A Logic Apps agent workflow receives the file, uses a document analysis tool to extract the data, generates Python code to compute trends and create visualizations, executes that code in a sandboxed session, and returns the results. The person asking the question does not need to know Python. The generated code runs in isolation, not on the host process, so a hallucinated import os; os.remove('/') cannot damage anything. This positions Logic Apps differently within Microsoft's own agent platform landscape. [Somnath Saha](https://www.linkedin.com/in/iamkunalsaha/), an Azure Solution Architect at COFCO International, [analyzed the three-way choice](https://www.linkedin.com/pulse/choosing-right-ai-agent-logic-apps-loop-vs-microsoft-foundry-saha--lce5c/) facing enterprise architects: [Logic Apps Agent Loop](https://www.infoq.com/news/2025/05/azure-logic-apps-agent-loop/)for integration-heavy workflows with 450+ connectors;[Microsoft Foundry](https://learn.microsoft.com/en-us/azure/foundry/what-is-foundry)for pro-code multi-agent orchestration with full model control;- and [Copilot Studio](https://www.microsoft.com/en-us/microsoft-365-copilot/microsoft-copilot-studio)for low-code conversational agents embedded in Microsoft 365. Saha argued that Logic Apps occupies a distinct niche: Logic Apps Agent Loop is best suited when your scenario requires orchestrating across multiple enterprise systems, ERP, CRM, databases, APIs, with built-in governance, retry logic, and audit trails. It is the integration architect's agent platform. [Mattias Lögdberg](https://www.linkedin.com/in/logdberg/), Founder of DevUP Solutions and Microsoft MVP, confirmed to InfoQ that architects have full control over model selection: Behind the scenes right now, it’s the OpenAI service. So first, you can choose the models available for selection based on which models are deployed in that service. After that, you can control exactly what model to use per workflow/agent, so you have full control of what model to use. The addition of a code interpreter strengthens that positioning. Integration workflows frequently need to transform, analyze, or enrich data mid-flow. Previously, this required calling out to an Azure Function or an external API. Now the agent can generate and execute the transformation code inline, within the same workflow and the same security boundary. *(Source: Microsoft Tech Community blog post - Logic Apps agent workflow with tool branches for expense processing, including human review via adaptive card.)* The sandboxing approach is worth comparing across hyperscalers for teams evaluating where to run agent-generated code. Cloudflare uses [container-based isolation](https://www.infoq.com/news/2026/04/cloudflare-sandboxes-ga/) on its edge network, with V8 isolates for lighter workloads. Google's [GKE Agent Sandbox](https://www.infoq.com/news/2026/05/gke-agent-sandbox-hypercluster/) uses gVisor kernel interception as an open-source Kubernetes primitive. Microsoft's approach uses Hyper-V microVMs, which provide the strongest boundary of the three; however, they require [Azure Container Apps infrastructure](https://learn.microsoft.com/en-us/azure/container-apps/overview). Each makes a different tradeoff between isolation strength, portability, and operational overhead. The code interpreter supports file operations alongside code execution. Agents can upload files to the ACA session, reference them as data sources in generated code, and download results. This creates a complete data pipeline within the agent loop: ingest a file, analyze it with generated code, produce a report or visualization, and return it to the user or pass it to the next workflow step. Logic Apps code interpreters are available now in public preview. A prerequisite is an Azure Container Apps [code interpreter session pool](https://learn.microsoft.com/en-us/azure/container-apps/sessions-code-interpreter), which can be created through the Azure portal or CLI. The [Logic Apps agent labs](https://azure.github.io/logicapps-labs/docs/logicapps-ai-course/agent_functionality/extend-tools-with-code/) include a step-by-step walkthrough for configuring the integration.