The preview label has limits. Private website browsing is still marked preview, and so is the trace-protection workflow Microsoft recommends. This piece covers what the preview includes, how to set the tool up, and where it can fail.
What shipped
Microsoft's Foundry blog, in a post by Nandini Muralidharan, says the tool lets agents navigate sites, inspect content, complete forms and run multistep browser workflows from natural-language instructions. Playwright Workspaces supplies the browser infrastructure.
Per Microsoft Learn, Playwright Workspaces provides the cloud-hosted browser infrastructure, while the Browser Automation tool exposes the browser capabilities the agent uses to complete a task. Because the browser runs remotely, agents need no local browser or Playwright runtime. Playwright Workspaces is a separate Azure resource that you provision yourself.
The tool remains in preview. The earlier preview ran each session in a sandboxed browser hosted within your own Azure subscription. A later preview moved the tool into Foundry toolboxes as an MCP tool. That release described it as a Public Preview MCP tool in Toolboxes, working with hosted agents in Foundry Agent Service. The architecture is unchanged since; Microsoft has not announced GA.
How an agent works a page
Microsoft describes an observe-and-act loop. The agent inspects the page, picks an operation, performs it and checks the resulting state before the next step. Microsoft says this helps with dynamic content, re-renders and dialogs.
The Learn documentation lays out the flow:
- A user gives the agent a natural-language task.
- The agent calls the Browser Automation tool, which is connected to a Playwright Workspace.
- The service creates a browser session with an ID, so later operations stay in the same browser context.
- The agent repeats observe and act until the task is done.
- The session closes and its browser resources are released.
Four ways to build
Microsoft lists four supported paths:
- Prompt agent: the fastest route. You define instructions, a model and tools in Foundry.
- Prompt agent with the GitHub Copilot harness: Foundry operates the harness and its isolated execution environment for you.
- Hosted agent with Microsoft Agent Framework: custom code, with Foundry handling hosting, scaling, identity and observability.
- Hosted agent with your own framework: for teams on LangGraph, OpenAI Agents SDK, Semantic Kernel or custom code. You connect to the toolbox through your framework's MCP client.
Toolboxes and MCP
Microsoft recommends adding BAT to a Foundry toolbox, publishing it and attaching the toolbox to an agent through its MCP-compatible endpoint. The practical gain is that you curate the tool once and reuse it across agents, with centralized identity, connection management, allow lists and approval controls. Microsoft's example code builds a toolbox with the Python SDK and asks an agent to look up a stock's year-to-date change on a finance site.
Microsoft also advises a staged rollout. Start with navigation and page inspection. Enable state-changing actions such as clicking, typing, form filling or file upload only when a scenario needs them.
Setup checklist
Prerequisites from Microsoft Learn:
- An Azure subscription.
- A Foundry project with an endpoint.
- A deployed model. Learn gives gpt-5.4 as an example and says to confirm that the model and project region both support the tool.
- A Playwright Workspace.
- A project connection to that workspace.
- For Python,
azure-ai-projects>=2.8.0. The .NET SDK is still described as preview.
Roles:
- Foundry User for everyday development.
- Foundry Project Manager to create the project connection.
- Contributor on the target resource group only while creating the Playwright Workspace. Learn suggests just-in-time activation through Entra Privileged Identity Management, then deactivation.
Identity. BAT uses the Foundry project's managed identity to reach the workspace. That is separate from the dedicated identity a hosted agent receives when deployed. Learn recommends a custom role with only the needed Playwright permissions. If you have none, assign Playwright Workspace Contributor at the workspace resource scope.
Authentication options. These are an API key, the project managed identity or an agent identity. If you use a token, keep it in the Foundry project connection. Keep it out of source code, prompts and logs, and rotate or revoke it per your policy.
Regions. Learn says hosted-agent use needs a Playwright Workspace in a region that also supports hosted agents. Its list is australiaeast, eastus, japaneast, switzerlandnorth, westeurope and westus3. Regional lists change, so check the live documentation before provisioning.
Portal path. In the Foundry portal, open your project and go to Build > Tools. Create a toolbox, add Browser Automation, pick the connection name, Playwright Workspace and authentication type, then connect and publish. The connection ID then appears on the tool's details page.
Public and private sites
Microsoft says agents can work across public sites and private apps behind an Azure virtual network. That requires private network connectivity, which has to be added when you provision the Playwright Workspace. It can't be bolted on afterward.
Don't read this as GA for private networking. Microsoft Learn lists private website browsing as public preview. Earlier documentation called it private preview with an enrollment form. Check the current status before promising internal-portal automation to anyone.
Microsoft's example workflows include:
- Employee onboarding and IT administration.
- Moving data between vendor portals and private systems.
- Investigating customer issues across public and internal tools.
- Automating legacy systems that lack APIs.
Learn gives a finance example: pulling invoice details from a vendor portal, validating them against an internal system and entering them into a legacy finance app.
Human oversight and monitoring
Two features keep a person in the loop:
- Live View lets operators watch an active session in real time. Learn says to treat the Live View URL as sensitive and not share it.
- Take control lets a person step into the browser, fix an unexpected state or complete a supervised step, then hand control back.
Learn also lists screenshot recording, run summaries, traces and diagnostic logs. After a test run, use Foundry tracing to confirm the tool was actually invoked.
Security risks
An agent with a browser can act on real systems. Microsoft's own warning says the tool can take unintended actions and recommends testing and monitoring. Its transparency note adds that malicious or confusing instructions on a page can lead an agent to run commands nobody intended. That is a prompt-injection risk.
Microsoft's mitigations:
- Enable only the tools a task needs.
- Use isolated sessions.
- Apply least privilege through managed identities and Azure RBAC.
- Validate sensitive destinations.
- Keep system policies separate from page content.
- Require human approval for consequential or state-changing actions.
Foundry traces can hold prompts, model responses, system instructions and tool-call arguments or results. Microsoft points to guidance for routing sensitive content to a dedicated AppGenAIContent table with deny-by-default access. It labels that workflow preview.
One outside view is worth noting. A third-party analysis of the separate Playwright Workspaces remote MCP server, on the site Greenlit Books, argues that the main protections sit on the customer's side. That includes separating instructions from page text and allow-listing destinations. That is independent commentary, not Microsoft's position. It does match the shape of Microsoft's own guidance.
Limits and troubleshooting
Microsoft's stated limitations:
- Use the tool only with sites you trust. Avoid pages that ask for credentials, payments or other sensitive actions.
- Pages change. Layout, label or navigation changes can break a workflow, so build in error handling.
- JavaScript-heavy single-page apps with dynamic content might not render correctly.
- Sessions run on a Playwright Workspace resource, so review its pricing and usage costs before production.
If the agent never uses the browser, check these in order:
- Confirm the agent was created with Browser Automation enabled.
- Require tool use in the request, for example
tool_choice="required". - Check Foundry traces for a tool call.
- Confirm the connection ID matches the Playwright workspace connection in your project.
- Confirm the project identity has access to the workspace.
Two SDK errors are documented. A "workspace not found" error usually means the project endpoint format is wrong. Use the https://{account-name}.services.ai.azure.com/api/projects/{project-name} form and not the legacy Azure ML endpoint. Unexpected-keyword-argument errors mean you should upgrade azure-ai-projects.
Our take
Browser automation fills a real gap. Many enterprise systems will never get clean APIs, and a supervised browser agent is a reasonable bridge. Microsoft's design choices are sensible: managed browsers, toolbox governance, human take-over and RBAC.
But preview here means the managed tool is not GA-supported. It does not mean unattended automation of production portals is a good idea. The private-network piece, which enterprises most want, is still preview. A web agent also inherits every fragility of the sites it drives. A sensible pilot is a low-risk, read-only workflow with approvals on anything that changes state, tracing turned on, and cost and regional limits checked up front.
Correction (October 19, 2026): This article originally described the Browser Automation Tool as generally available. Microsoft still classifies it as preview: the SDK class is named BrowserAutomationPreviewTool, and Microsoft's June 2026 toolbox announcement lists it as 'Browser Automation (preview)'. The region list was also corrected: East Asia is not a hosted-agent region per Microsoft Learn, so eastasia was removed.