Microsoft published a new security pattern for authenticated browser automation with Microsoft Foundry Hosted Agents, Browser Automation Tool, Playwright Workspaces, and Azure Key Vault on August 27, 2026.

The pattern addresses an awkward enterprise reality. Agents can call APIs, but many supplier portals, internal dashboards, ERP screens, and legacy applications still expose important workflows only through a web interface. A browser-capable agent can navigate those interfaces, yet it still needs a governed way to authenticate.

Microsoft's central recommendation is simple: keep credentials in Key Vault, let trusted application code retrieve them only when required, pass them directly into the browser workflow, and avoid exposing secret values to the model.

That boundary matters. Giving an agent a browser does not make passwords prompt data. Credentials remain privileged application state.

Browser Automation Turns Identity into the Hard Part

Browser Automation Tool, or BAT, gives a Foundry agent the ability to open websites, select controls, complete forms, extract information, and execute multi-step workflows in a cloud-hosted browser.

The browser sessions are powered by Playwright Workspaces. Hosted Agents provide the managed container runtime, identity, endpoint, scaling, session handling, and observability around the custom agent code. Foundry Toolbox provides a reusable way to expose tools to agents through an MCP-compatible endpoint.

Those pieces make interaction possible. Authentication remains a separate design problem.

Enterprise sites can depend on:

• Microsoft Entra single sign-on

• Conditional Access

• Multifactor authentication

• Device compliance

• Federated identity

• Session cookies and tokens

• Traditional usernames and passwords

A cloud-hosted browser is not automatically the human user's managed device. It should not inherit a personal browser profile, a developer's cookies, or a password copied into a prompt.

The right authentication method depends on the target system and the identity whose authority the workflow is meant to exercise.

Prefer Identity over Stored Passwords

Key Vault is the right system of record when the target application genuinely requires a secret, such as a username and password, API key, OAuth client secret, certificate, or service-account credential.

It should not become an excuse to preserve a password-based design when a stronger identity flow is available.

For Microsoft Entra-protected applications and Azure resources, prefer:

• The Hosted Agent's dedicated Microsoft Entra identity for autonomous service actions

• Managed identity for Azure resource access

• OAuth rather than password replay

• On-Behalf-Of flow when the operation must retain an interactive user's delegated permissions

• Short-lived tokens rather than long-lived credentials

Microsoft Foundry assigns each Hosted Agent a dedicated agent identity at deployment. That identity can be granted narrowly scoped access to downstream Azure resources and gives security teams a principal they can authorize, monitor, and revoke.

Use Key Vault for the remaining secret-based edge cases, not as a universal authentication layer.

The Recommended Secret Flow

Microsoft describes a six-step pattern for traditional credential workflows.

1. Store the Credentials in Azure Key Vault

Create separate, clearly named secrets for the values the automation requires. A supplier portal might use one secret for the username and another for the password.

Do not store the values in:

• Source code

• Container images

• Prompts

• Agent instructions

• Tool descriptions

• Deployment templates

• Plain-text environment variables

• Browser automation recordings

Key Vault provides encryption, access control, audit integration, versioning, and a central place to rotate credentials without rebuilding the agent image.

2. Authorize the Hosted Agent with Azure RBAC

Grant the agent identity only the data-plane permission required to read the specific secrets. Microsoft's example uses the Key Vault Secrets User role.

Keep the assignment scope as narrow as practical. A dedicated vault per environment or workload can be easier to reason about than one large vault containing unrelated credentials.

Separate roles are involved in the wider architecture. The identity used for the browser service also needs appropriate access to the Playwright Workspace, while the runtime agent identity needs access to the target Azure resources it calls. Confirm the exact principal before making each role assignment.

Avoid Contributor, Owner, or Key Vault administration rights when secret-read permission is sufficient.

3. Retrieve a Secret Just in Time

The application code can use `DefaultAzureCredential` and the Key Vault SDK to request the secret immediately before authentication.

The important property is not the exact SDK call. It is the boundary:

• Trusted code asks Key Vault for the value.

• The value stays in process memory for the shortest practical time.

• The model does not receive the value as a message.

• The secret is not returned as a tool result.

• Logging and tracing redact the value.

Avoid caching credentials across unrelated sessions. If a workflow must reuse an authenticated session, define its lifetime and isolation rules explicitly.

4. Authenticate Inside the Isolated Browser Session

The code launches the browser workflow, navigates to the approved login page, and supplies the credential to the expected fields.

Treat this as a privileged operation. Validate the destination origin before entering any secret. A malicious page or prompt-injected redirect must not be allowed to choose where credentials are submitted.

The allowlist should include exact schemes, hosts, and where necessary paths. Be careful with look-alike domains, open redirects, embedded frames, and links returned by untrusted content.

5. Perform Only the Authorized Business Action

After login, constrain the workflow to the intended task: download an approved report, reconcile a defined set of records, check an order, or submit an already approved form.

Authentication does not imply permission to do everything the account can do.

Use application-level authorization, workflow policy, target allowlists, and human approval for high-impact actions. Financial transfers, user administration, contract acceptance, data deletion, and broad exports deserve explicit gates.

6. Terminate the Session and Dispose of State

Close the browser session when the task finishes. Remove temporary downloads, screenshots, cookies, and other authentication artifacts according to the workflow's retention policy.

Hosted Agent sessions can persist state across turns. That is useful for long-running work, but it means teams should decide what may be written to the persistent session filesystem and what must remain ephemeral.

Session cleanup is part of the credential lifecycle, not an optional housekeeping step.

The Model Should Never See the Password

The most important architectural question is whether the language model can observe the credential.

It does not need to.

A safer execution boundary looks like this:

1. The model selects an approved login action. 2. Deterministic application code validates the target. 3. Code obtains the secret through the agent identity. 4. Code writes the value directly into the browser input. 5. The browser completes the authentication exchange. 6. The tool returns only a sanitized success, failure, or business result.

Never concatenate the password into a prompt and ask the model to type it. Never echo it into a trace so the agent can debug itself. Never put it in an MCP tool response.

The same rule applies to session tokens and cookies. A token can be as powerful as the password that created it.

Key Vault Does Not Solve MFA or Conditional Access

Storing a password securely does not guarantee that a cloud browser is allowed to use it.

The target application's Conditional Access policy might require a compliant device, an approved client, a phishing-resistant authentication method, a user interaction, or a particular network location. MFA might intentionally prevent unattended login.

Do not weaken those controls just to make automation succeed.

Instead, decide whether the workload should use:

• An application or workload identity

• A dedicated automation account with a narrowly scoped policy

• Delegated user authentication through OBO

• A supported service API

• A human take-control step

• No automation at all

Security architecture should drive the identity method. Browser convenience should not drive an exception to the organization's access policy.

Defend Against Prompt Injection in the Browser

A browser agent reads untrusted text and follows links. A compromised page can contain instructions designed to manipulate the model, navigate to a malicious origin, reveal data, or perform an unauthorized action.

Key Vault protects the secret at rest and during retrieval, but it cannot decide whether the page is trustworthy.

Add controls around BAT:

• Restrict navigation to approved domains.

• Validate every credential-submission origin in deterministic code.

• Separate read-only and write-capable tools.

• Require approval before consequential submissions.

• Limit downloads and uploads.

• Sanitize tool output before returning it to the model.

• Prevent secrets from appearing in screenshots, traces, console logs, and error messages.

• Treat page content as untrusted data, not higher-priority instructions.

• Use short-lived credentials and rotate them after suspected exposure.

The browser is an execution environment with access to outside content. Apply the same zero-trust thinking used for APIs, plugins, and third-party integrations.

Audit the Entire Authenticated Workflow

Microsoft recommends Key Vault logging, Azure Monitor, and Activity Logs for visibility into authenticated agent actions.

Correlate events across:

• User or initiating workload

• Agent name and immutable version

• Agent identity

• Key Vault secret request

• Browser session ID

• Approved target domain

• Business action

• Human approval record

• Result and failure reason

Do not record the secret value. Audit metadata should establish who accessed which secret version and why, without copying sensitive material into the observability platform.

Alert on unusual access patterns such as repeated authentication failures, secret reads outside expected workflows, new destination domains, downloads larger than normal, or privileged actions without approval.

Rotation Must Be Tested, Not Merely Configured

Central storage makes rotation possible, but the workflow must tolerate it.

Test what happens when:

• A password changes between two sessions.

• A secret version is disabled.

• The Key Vault role assignment is removed.

• Key Vault is temporarily unavailable.

• The target portal locks the account.

• Authentication adds a new consent or MFA step.

The agent should fail closed, avoid repeated login attempts that trigger lockout, and surface an actionable error without revealing credentials.

Assign an owner to every secret, record its purpose, define an expiry, and remove it when the automation is retired.

Preview Status Deserves Production Caution

Microsoft's current Browser Automation Tool quickstart labels the Hosted Agent browser automation experience as public preview and states that preview features have no service-level agreement and are not recommended for production workloads.

That does not prevent teams from evaluating the security pattern. It does mean production use needs a deliberate risk decision.

Start with non-destructive, low-privilege workflows in a test environment. Measure reliability, latency, browser behavior, credential exposure paths, and recovery. Keep a manual fallback until both the platform and the business process meet the required operational bar.

Who Should Care?

Agent developers should care because secret handling belongs in application code, not model context.

Identity teams should care because the agent identity, delegated user identity, service account, and browser session represent different security principals and trust boundaries.

Security engineers should care because authenticated browsers expand the attack surface to web content, redirects, downloads, and session artifacts.

Platform engineers should care because Key Vault, RBAC, Playwright Workspaces, Foundry Hosted Agents, and Toolbox need consistent deployment and monitoring standards.

Compliance teams should care because an agent can exercise real authority inside systems that may have no automation-specific audit trail of their own.

Business owners should care because the right workflow can automate a legacy process without first rebuilding the target application, but it must preserve the same approvals and accountability expected from a human operator.

Practical Cloud Engineer Takeaway

Choose one read-only portal workflow and draw its trust boundaries before writing automation.

Document:

1. The initiating identity and business purpose. 2. The target application's supported authentication methods. 3. Whether managed identity, OAuth, or OBO can replace a stored password. 4. The exact agent identity and RBAC scope. 5. The approved browser origins. 6. The secret's owner, rotation policy, and expiry. 7. The actions the browser may perform. 8. The events that require human approval. 9. The logs needed to reconstruct the run. 10. The teardown and incident-response process.

Then prove that the model never receives the credential. Inspect prompts, tool payloads, traces, screenshots, exceptions, and persisted session files.

Test a malicious redirect, a prompt-injected page, a disabled secret, a rotated password, and an account lockout. The failure mode should be controlled and observable.

Only expand to write operations after the read-only design is stable.

Bottom Line

Microsoft's new pattern connects Foundry Hosted Agents, Browser Automation Tool, Playwright Workspaces, Toolbox, and Azure Key Vault to solve authenticated browser workflows without turning passwords into prompt content.

Use the agent's Microsoft Entra identity wherever possible. When a legacy site genuinely requires a secret, store it in Key Vault, grant narrow RBAC access, retrieve it just in time through trusted code, inject it directly into an approved browser origin, and dispose of the session afterward.

Key Vault is only one layer. Domain restrictions, prompt-injection defenses, human approval, short-lived authority, complete auditing, rotation testing, and careful treatment of preview capabilities remain essential.

The design goal is not an agent that can log in anywhere. It is an agent that can complete one authorized workflow without ever needing to know the credential it uses.

Sources

Microsoft Apps on Azure Blog, published August 27, 2026: https://techcommunity.microsoft.com/blog/appsonazureblog/manage-and-retrieve-credentials-securely-inside-browser-automation-tool-bat-usin/4550858

Browser Automation Tool quickstart for Hosted Agents: https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/tools/browser-automation-hosted-agent-quickstart?pivots=python

Hosted Agents in Microsoft Foundry: https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/hosted-agents

Toolbox in Microsoft Foundry: https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/toolbox-overview

Azure Key Vault concepts: https://learn.microsoft.com/en-us/azure/key-vault/general/basic-concepts

---

Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.

Chriz Beyond Cloud with Chriz