Configure and monitor computer use for an agent

A warranty claim has to be filed in a partner web application. There is no connector for it, no REST endpoint, no MCP server, and the vendor has no plans to publish one. The claim form is three clicks deep behind an icon in the top right corner. Somebody in your operations team files forty of these a day by hand, and you have been asked to make an agent do it.

That is the central case for computer use, and it is worth stating as a boundary rather than as a capability. Every other page in this domain connects an agent to a system that already publishes something callable: a connector operation, a REST operation, an MCP tool, a search index. This page owns what is left over. Computer use is a tool in Copilot Studio that lets your agent interact with and automate tasks on a Windows computer. It works with websites and desktop apps by selecting buttons, choosing menus, and entering text into fields on the screen^[1]. You describe the task in natural language and the tool performs it on a computer you set up, using a virtual mouse and keyboard, so that agents can complete tasks even when there's no API to connect directly to the system^[1].

Adding this tool looks like adding any other: you name it, you write the short description the orchestrator reads when deciding whether to call it, and you save. The resemblance stops at the schema. A connector operation has typed inputs and outputs that either match or fail loudly at design time. A computer use tool has a paragraph of English and a screen, and nothing on the authoring surface will tell you that the paragraph is wrong. Everything else on this page follows from that gap: the four settings that shape the paragraph, the machine the work actually happens on, the identity it borrows while it is there, the limits on what it may touch there, and the evidence a finished session leaves behind so you can see which pixels it clicked and why.

How the tool actually works, and why that matters for your instructions

Computer use is powered by a Computer-Using Agent (CUA), a model class that combines vision with reasoning to operate graphical user interfaces. This guide says computer use for the feature and computer use tool for the artifact you add to an agent, and does not use the CUA abbreviation again.

Microsoft describes the runtime as a loop of three steps: Perception: It captures screenshots to visually understand the current state of the computer screen. Reasoning: It evaluates the current state, previous actions, and screenshots through a chain-of-thought approach, which allows it to adapt its actions effectively. Action: It performs actions like clicking, typing, or scrolling until the task is complete or requires further user input^[2]. The figure below traces one turn of that loop and the two ways out of it.

Two consequences follow, and they shape every later section. First, because each cycle re-reads the screen, the tool adapts when an interface moves: Microsoft notes that when buttons or screens change, the tool continues working. Second, because each cycle decides rather than replays, the same instruction can produce different action sequences on different days. Nothing is recorded and played back.

That is why the honest framing for computer use is a capable last resort rather than a default. Microsoft publishes the reliability plainly: the tool performs best on web-based tasks (about 80% success) but drops significantly on desktop apps (about 35% success)^[2], and the same list names inconsistent performance across runs, difficulty with non-standard or dynamic controls such as dropdowns, date pickers and custom widgets, and loops or stuck states when the screen does not match expectations. If a connector or a REST call exists, use it. Add REST APIs to an agent and Configure MCP tools both describe cheaper, deterministic routes to the same data.

The prerequisite, and the placement rule hiding behind it

Computer use is only available for agents with generative orchestration turned on^[1]. Read that alongside a line from the limitations list: running computer use from a topic isn't supported^[3].

Together those two facts remove a placement option you have on almost every other tool. On Add agent flows to a topic the guide distinguishes an explicit call, where an Action node invokes a tool at an authored step, from an orchestrated call, where generative orchestration selects the tool itself. Computer use only ever gets an orchestrated call. There is no call site you can point at on a canvas, so the planner, Microsoft's word for the deciding side of generative orchestration, reaches this tool through its Description field or it does not reach it at all. That field is this page's routing description: the short text whose only job is to tell the planner when this tool is the right one, as distinct from the instructions, whose job is to tell the tool what to do once it has been chosen.

That single fact resolves the most common early symptom. When a computer use tool never fires, the instinct is to rewrite the instructions. Reach for the routing description first, because that is the text the planner matches a user request against. Microsoft's own troubleshooting entry for a test that ends with The computer use tool is not a part of the planned execution sequence is to test using the agent's test chat instead, and review the descriptions (instructions) provided to the agent to ensure it has sufficient context to trigger computer use^[3]. Routing is a description problem. Behaviour is an instructions problem. Keep the two apart and most of this page's troubleshooting becomes mechanical.

One more availability check belongs here rather than later, because it produces a confusing absence rather than an error: an administrator can turn computer use off for an environment, and the runtime error code for that state is FeatureDisabled, resolved by enabling computer use from the admin center^[3]. If Computer use is missing from the New tool list entirely, stop configuring and ask about the environment setting. Provisioning and administering the environment is not this exam's job, but knowing which absences are yours to fix is.

You add the tool the same way you add any other. On the Tools page for the agent, select Add tool, then New tool, then Computer use. You are asked for the instructions first, with instruction templates offered as a starting point, and then you select Add and configure to reach the full configuration page.

Microsoft names exactly four required fields there: Name, Description, Model, Instructions^[1]. Everything else on the page is optional, which is a sentence to read carefully, because Access control, Enforce HTTPS and Human supervision sit among those optional blocks, and they carry much of the security posture the later sections build. The figure below groups the whole surface by the question each field answers, and the rest of this page follows those four groups in order.

What each required field decides

Name is the display name, and Microsoft's stated purpose for it is narrow: it helps you differentiate it from other tools you add to your agent^[1]. It is a label for you, not a signal to the planner.

Description is the routing description, and it is the field with the most leverage per word on the whole page. Microsoft's own gloss is that it is a short description of what this tool does and when to use it. This text lets your agent know when to use this tool^[1]. Because computer use can only be reached by an orchestrated call, this text is the tool's entire discoverability. Write it in terms of the user request that should select it rather than the mechanism it uses: files a warranty claim in the partner portal tells the planner what the tool does and when to use it, where automates a web UI leaves it much less to match a request against.

Model selects which model executes the session. Microsoft offers models from more than one provider, with a tier and a status against each, and the list changes: treat the specific model names in the product as current-at-the-time rather than memorised. Two durable points survive the churn. Using a non-Microsoft provider's model requires that your administrator turned on access to external models^[1] for the environment, so an external model that is absent from the dropdown is first an environment-settings question rather than a licensing accident. And model support is not uniform across features: the human supervision article publishes a per-model support table, which is the sort of detail worth checking against the live page before you commit a design to it. Selecting a model the service does not support surfaces as the ModelNotSupported error code.

Instructions are the steps the tool performs, including URLs and application names^[1]. The next section is entirely about writing them.

Inputs: the values that change between sessions

Instructions are static text. Real tasks are not: the claim number, the date range and the customer name are different every time. That is what Inputs are for. Microsoft's description is exact about the mechanism: Use inputs to define dynamic values that change each time computer use runs. For example, if you want to fill out a form with a different value on every run, create an input for that field. At execution time, computer use combines your instructions with the input values to complete the task^[1].

The practical rule is a split. Anything stable about the task, the URL, the application, the navigation path, the order of steps, belongs in the instructions. Anything that varies per session belongs in an input, and the instructions refer to it rather than containing it. Baking a claim number into the instruction text makes the task static, so the tool has to be edited for every claim, which is not automation.

This is also where the vocabulary of this guide needs one careful note. On Monitor agent flows the word run is reserved for one execution of an agent flow, and activity for a unit of agent interaction. Microsoft's computer use articles use run and session interchangeably for one execution of a computer use tool. To keep the two apart, this guide says computer-use session for one execution of this tool, and keeps run only inside vendor labels quoted verbatim, such as the Run queue in Power Automate.

The instructions are the program. Nothing on the authoring surface validates them the way a connector operation's typed inputs and outputs are validated, so ambiguity does not surface at design time. It surfaces during execution instead, as an unintended action or a session that loops on a screen that does not match expectations.

Microsoft frames the standard usefully: Think of it as explaining a task to a colleague. Clear, step-by-step guidance helps ensure success^[1]. That analogy is a mental model, not product terminology, and it holds up because the failure modes are the same ones a vague handover produces with a person: the wrong site, the wrong button, and a form left unsubmitted because nobody said to submit it.

The four published rules

Microsoft's guidance is a short list, and each item removes one specific ambiguity.

Name the website and the application exactly. Always include the full URL of any website and the exact name of any application the tool should use^[1]. The worked example is Open https://www.microsoft.com and go to Company news. A bare hostname or a friendly application name asks the model to guess at the first step, which is the worst place to guess, because every later action inherits the mistake.

State consequential actions explicitly. If you want something done, say it explicitly, especially for actions like submitting a form or sending an email^[1]. Microsoft's own sample instruction goes further and pre-empts the hesitation: Once you fill in the form, select Submit. No need to ask for permission. This is the rule authors most often skip, because filling a form obviously implies submitting it to a human reader. It does not obviously imply it to a model that has been told to be careful, and a session that fills a form and stops has done nothing.

Break down complex interface navigation. For areas where the UI might be more complex to navigate, explain each step in detail^[1], as in Select the More icon in the top right corner. A dropdown appears. Once it opens, select the last item in the list. Nested menus, hover-reveal controls and icon-only buttons are exactly where a screen-reading model loses the thread, and they are exactly where a one-line instruction feels sufficient.

Use step-by-step formatting for longer tasks. Long instructions are easier to follow when you format them as a list^[1]. An ordered list also makes the reasoning log readable later, because the step the session is on lines up with a numbered step you wrote.

Extraction, and where the second half of the work belongs

Computer use can read as well as write. Microsoft's guidance is to describe what information you want to extract directly in the instructions for computer use^[1], and the tool can return the values as plain text or as a JSON object when you want to hand structured data to something else.

The seam is worth pinning down, because it is a common design error. If the extracted data must then be emailed, or written to a record, that second act is not part of the computer use tool. Microsoft is explicit: If you want to use the extracted data with another tool (for example, sending it by email), specify that need in the agent instructions and make sure you add both tools to the agent^[1]. Tool instructions describe what happens on the screen. Agent instructions describe how the tools compose. Putting and email it to the manager in the computer use instructions asks a screen-driving model to invent a mail client.

One closing constraint on this section, which the security sections revisit: however specific the instructions become, passwords do not belong in them. There is a dedicated Stored credentials block for sign-in secrets, and it is the place the tool looks when a login prompt appears.

Testing is not optional polish here, it is where you find out what the model actually sees. Microsoft puts it plainly: Testing computer use is a key step in the authoring journey^[1].

Once a name, description and instructions are saved, the tool has its own Test button, and the experience it opens has two panels. The left panel shows your instructions and a step-by-step log of the tool's reasoning and actions. The right panel shows a preview of the actions on the machine you set up for computer use^[1]. You are watching the reasoning and the screen side by side, which is the only moment in the lifecycle where you get both live and unmediated.

Read the left panel first when something goes wrong. The right panel tells you that the session clicked the wrong thing; the left panel tells you what it believed about the screen when it decided to. A session that clicked Save draft instead of Submit because both buttons were visible is an instruction problem you can fix in one sentence. A session that looped between two screens is more likely a task-shape problem than a wording one; refining the instructions is still the documented first move, but loops and stuck states are a published limitation of the tool.

Stopping a session that is doing damage

A computer use session is operating a real Windows machine against real systems. If it starts filing a claim against the wrong customer, waiting for it to finish is not an option. Microsoft provides the interrupt: To immediately stop all actions on the machine, you can select Stop testing while the test is in progress^[1]. When the task ends normally instead, a Test completed message appears.

Know where that control is before you need it. It is the reason the two-panel preview matters: you cannot decide to stop a session you cannot see.

The refine loop, and which field to refine

Microsoft's stated remedy for a wrong result is a loop rather than a fix: If the result isn't what you expect, go to the configuration page and refine your instructions. To improve accuracy, add more details^[1]. Publication comes after that loop settles, not before it, and the tool's own Test button is the fast half of the loop because it exercises the instructions without involving the planner.

That also means the tool test and the agent test answer different questions, and choosing the wrong one wastes an afternoon.

• The tool's Test button exercises the instructions against the machine. Use it while the wording is still moving.
• The agent's Test your agent panel exercises routing as well: whether the planner selects this tool for a realistic user request. Use it once the instructions are stable.

Microsoft's troubleshooting table joins the two. If the tool test ends abruptly with The computer use tool is not a part of the planned execution sequence, the advice is to test using the agent's test chat instead, and review the descriptions (instructions) provided to the agent^[3]. The failure looks like a broken test harness and is really the planner declining to include the tool in its plan, which points straight back at the Description field.

Two smaller test-time behaviours are worth carrying into the next sections. Tests count as real sessions against a real machine, so a rapid retry can collide with the session still finishing: Microsoft's guidance for An automation is already running on the machine is to wait 2 to 3 minutes before trying again^[3]. And if you have already turned on the two settings that restrict what a session may touch, Access control and Enforce HTTPS, both covered in full later on this page, they apply during testing too. The troubleshooting entry for a blocked action with error code CuaActionBlocked suggests, among other things, turning off Enforce HTTPS and Access control, then running computer use again to see if the problem is resolved^[3], which is a diagnostic step rather than a resting state. Turn them back on.

Every computer use session needs a Windows machine to happen on, and Microsoft gives you three ways to supply one. The choice is made in the Machine field of the tool, and it is a governance decision before it is a convenience one, because the three options differ most in what they are joined to and managed by rather than in how fast they are.

The comparison table above lays the three side by side. This section explains what each one is for; the next covers the machine you register yourself, where most of the mechanics live.

The hosted browser: fastest to start, narrowest by design

The hosted browser, a preview capability powered by Windows 365 for Agents, is the zero-setup option. It lets you get started quickly without any machine setup. It provides both web automation using Microsoft Edge and access to built-in Windows applications^[4].

Its boundary is stated just as plainly, and it is where the other two options differ. The hosted browser runs in a Microsoft-managed environment. It isn't Microsoft Entra joined to your tenant or managed by your Intune policies. It's designed for quick web automation and early experimentation, but it doesn't support enterprise resource access, custom desktop apps, or organization-specific device management^[4].

Unpack that against a requirement and the shape of the trap appears. If your organization's policy says the device must be Entra joined and Intune enrolled, and the automation has to drive a custom Windows application, the hosted browser fails on all three counts at once. It is the option that looks like the safe default because it needs no setup, and it is precisely the option that a managed-enterprise requirement rules out first.

Throughput closes the case for production. Microsoft states that the service might throttle hosted browser usage based on demand. Therefore, it might not be suitable for production use^[3], and publishes two throttling categories: a user may hold only one active hosted browser session at a time, with any subsequent session failing, and demand-based throttling can fail a session independently of that. The symptom is an error reading No machine able to run the automation has been found.

Cloud PC pool: managed machines you do not maintain

A Cloud PC pool, also a preview capability powered by Windows 365 for Agents, is the answer when you want enterprise governance without owning hardware. Microsoft defines it as a scalable group of virtual machines (VMs) hosted in Microsoft's cloud that are Microsoft Entra joined and Intune enrolled^[5], and lists the features that follow: running computer use without bringing your own machine, auto scaling the number of Cloud PCs to current workload, and work or school account integration that enables access to resources that are linked to your organization, such as Microsoft 365, SharePoint, and Azure^[5].

That is the exact inverse of the hosted browser's boundary, one row at a time: Entra joined rather than not, Intune enrolled rather than not, organizational resources reachable rather than out of scope. When a scenario names Entra join, Intune enrollment and custom Windows applications as requirements, the Cloud PC pool is the option that satisfies all three without you maintaining machines.

The maker-side gesture is small: in the Machines section of the computer use tool, open the machine dropdown, and under Cloud PC pool select Add new, name it, and create it. Provisioning is not instant, and Microsoft documents it as taking up to 30 minutes^[5], with a Refresh button in the Machines section to check status.

The administrator-side work is larger, and Microsoft is explicit about where the line falls. The prerequisites section is headed for IT administrators and opens with the instruction that if you're an agent builder or developer without IT administrator privileges, share this section with your IT administrator to complete the setup^[5]. Microsoft Entra and Intune tenant configuration, Entra authentication for remote desktop, and the required service principals are that person's job, not yours. What is yours is knowing that the dependency exists, so that a provisioning failure gets routed rather than retried.

One Cloud PC pool limitation belongs on a builder's checklist rather than an administrator's: only a Microsoft Entra user account can execute computer use. Additionally, the signed-in Microsoft Entra user must be the same account that owns the computer use connection^[5].

Bring-your-own machine: full control, full responsibility

The third option lets you use Windows machines that you own and manage. You register and manage machines in Power Automate^[4]. The operating system image, the installed applications and the device policy that the hosted browser and a Cloud PC pool arrive with already settled are now yours to decide and to maintain, which is both the appeal and the cost. The next section walks the onboarding.

A caveat that catches people who already run desktop automation: hosted machine groups are listed among the unsupported scenarios for computer use, as are multi-screen desktops. An existing Power Automate machine estate does not automatically qualify.

Bringing your own machine is a four-step path, and it crosses a product boundary in the middle: the first three steps happen in Power Automate, the last one in Copilot Studio. The figure below traces it.

Microsoft states the requirements compactly: Install Power Automate for desktop version 2.61.132.25266 or later. Include the Power Automate web extension installation for web browser interactions. After registering the machine, turn on computer use in the machine settings^[4]. Treat the exact build number as a value to re-read on the live page rather than memorise; what is durable is that a minimum version is enforced and that the browser extension is a separate component you can forget to install.

The steps

1. Install Power Automate for desktop on the machine, at or above the documented minimum version, including the web extension. During installation, Microsoft's instruction is to make sure you check the Install the machine-runtime app to connect to the Power Automate cloud portal option^[4].
2. Register the machine to the environment. Open the Power Automate machine runtime app, sign in, and register the machine to the environment you want to use with computer use.
3. Turn on Enable for computer use. In Power Automate, go to Machines, select the machine you registered, open Settings on the machine detail page, turn on Enable for computer use, and select Save.
4. Select the machine in the tool. Back in the computer use tool's Machine field, pick it. Refresh updates the machine list, Manage machines opens the machine management page in Power Automate, and See machine details opens that machine's detail page.

Step 3 is the one that is easy to skip, because step 2 already produced a machine that exists, is online, and appears in Power Automate. Registration and enablement are two separate switches, and only the second one makes the machine a candidate for computer use.

Microsoft attaches one design instruction to this path: Because computer use runs on the machine, dedicate a machine to computer use to avoid interruptions^[4]. The security case for a dedicated machine comes later on this page; this is the availability case, and it is separate. A person using the desktop while a session is driving it will collide with it.

One machine, one session at a time

This is the constraint that catches capacity planning, and it is a direct consequence of the tool driving a real Windows session. Microsoft states it as a rule: When a Machine is in use, run requests targeting the same machine are queued and executed sequentially^[4]. The published sequence is three states: The first run executes on the target machine. Subsequent runs are added to the queue and marked as Queued. When a run completes, the next run starts and is marked as Next to run^[4].

You watch that queue where it lives, which is in Power Automate rather than Copilot Studio: go to Machines, select the machine, and open the Run queue tab on its detail page.

The practical reading is that a single registered machine gives you serialised throughput, not parallel throughput. Twenty users triggering the same conversational agent at once do not get twenty sessions; they get one session and nineteen waiting. Two consequences follow. If concurrency matters, the machine choice is the lever, and this is where a Cloud PC pool earns its complexity, because it auto scales the number of Cloud PCs to current workload instead of serialising against one desktop. And if you are testing, a retry too soon lands behind your own previous session, which is what Microsoft's An automation is already running on the machine. Retry later entry and its two-to-three minute wait are describing.

Queuing is not exclusive to single machines, and it is worth being precise rather than implying pools never queue. A Cloud PC pool also has Run queue and Queue events tabs on its details page in Power Automate, where you can view all computer use sessions that are queued on the target Cloud PC pool^[5]. The difference is what the queue means: on one registered machine it is the normal mode of operation, while on a pool it is what happens once scaling has run out of room.

There are two settings on this configuration page with credentials in the name, they sit near each other, and they answer completely different questions. Getting them confused is not a small slip: it produces a failure at the wrong door and sends you debugging the wrong thing.

The two doors are these. A computer use session first has to get onto the Windows machine, and then, once it is there and browsing, it may hit a sign-in page belonging to a website or a desktop application. Credentials to use governs the first door. Stored credentials governs the second. The figure below draws them in sequence.

Door one: Credentials to use, the identity on the machine

Microsoft's framing is specify how computer use authenticates during execution, and the two values will already be familiar from tool authentication elsewhere in Copilot Studio, because they are the same tool credential mode pair used across the product.

Maker-provided credentials is the default, and Microsoft describes it as use the maker's credentials. This option is suitable for autonomous agents^[1]. It comes with a warning that deserves to be read as a design constraint rather than a footnote: If you share an agent with this setting, anyone using it can act with the original author's access on the configured machine^[1]. The agent becomes a way for its users to borrow your access to that machine. That is exactly what you want for an unattended background job, and exactly what you do not want for an agent shared broadly across a department.

End user credentials is the alternative: use the credentials of the person interacting with the agent. Each user must have access credentials to the machine^[1]. The same requirement appears from the publishing side, where Microsoft notes that in a conversational deployment each user interacting with the agent needs valid credentials for the machine used by computer use. The cost of the safer identity model is a real prerequisite: everybody who may trigger the tool needs machine access of their own. A department of two hundred people is unlikely to have that, which is the practical reason conversational computer use tends toward a narrow audience.

So the decision is not which is more secure, it is who should the machine believe is doing this. Autonomous, shared, one service identity: maker-provided. Per-user, attributable, each acting within their own machine access: end user, with the credentials prerequisite that implies.

Door two: Stored credentials, the secrets typed into a sign-in prompt

The second block answers a different question entirely. Microsoft's description: Define the credentials that computer use uses to sign in to websites and applications. During execution, if a sign-in prompt appears, computer use securely uses any credentials you defined in this section for that site or application^[1].

There are two backing stores. With the internal storage option, Power Platform encrypts and stores secrets internally^[1] and no preconfiguration is needed; you supply a Type of Website or Desktop app, a Username, a Password, and the login domain or desktop app name. With the Azure Key Vault option you supply the subscription ID, resource group and vault name, then a Username and an Azure secret name in place of the password. Microsoft notes two prerequisites for the vault route: the Azure subscription holding the vault must have the PowerPlatform resource provider registered, and the user creating the environment variable must have appropriate permissions to the Key Vault resource.

A credential is bound to a target: for a website you enter the main website address, and all pages on that site are included, with wildcards available for subdomains; for a desktop application you enter the application product name or process name. If the session meets a sign-in prompt with no credential matching that target, the error code is CUACredentialNoMatch, whose documented resolution is to make sure that there's an existing credential in the computer use tool matching the application/website^[3]. The failure is a matching failure, not an authentication failure: check that a credential for that site or desktop application exists at all, and that its Login domain or desktop app name names the target, before you touch the password.

One support boundary is worth knowing before you promise a desktop automation. Microsoft states that password fields are supported on all websites and most Windows applications, naming WinForms, WPF, UWP, WinUI and Win32, while some app types, such as Electron, Java, Unity, games, command-line interfaces, Citrix, or other virtualized environments, might not be supported^[1].

Why the password never goes in the instructions

This is the practical reason the two doors are worth separating in your head. Because Stored credentials is where computer use looks when a login prompt appears, there is no scenario in which the instruction text needs to contain a password. Keeping secrets there rather than in prose also keeps them out of a field the session evidence reproduces: the advanced computer-use activity panel covered later on this page lists the instruction text^[6] in its Summary section. Microsoft applies the same instinct to the other free-text surface on this page: reviewers responding to a human review request shouldn't submit sensitive information such as usernames, passwords, PINs, credit card information, or social security numbers^[7], because those responses may persist in Dataverse or in Purview audit logs. Credentials belong in a credential store at both doors.

A computer use session is a model with a mouse on a real Windows machine. The controls that keep that acceptable come in two layers: what you do to the machine, which is outside Copilot Studio, and what you set on the tool, which is inside it. The figure below groups them that way and names what each control actually stops, because several of them sound interchangeable and are not. Microsoft's own FAQ makes the layering explicit when it warns against leaning on human review, advising you to apply more controls appropriate for each possible scenario (for example: clear instructions, restricted environments, least-privilege accounts, allow lists, and other operational safeguards)^[2].

The machine layer: isolate it and starve it of privilege

Microsoft publishes four recommendations for securing a machine used by computer use, and they compose into a single posture rather than a menu.

Use a dedicated machine. Assign specific, isolated machines exclusively for tasks involving computer use. This approach reduces the risk of cross-contamination from unrelated software, malware, or unauthorized access. It lets you control configurations, updates, and monitoring more effectively^[1]. This is the same instruction the previous section met for availability reasons; here it is a containment measure, and the two arguments are independent.

Limit the permissions of the account the tool uses. Set up the user account for computer use to follow the principle of least privilege, grant only the permissions needed to run the required tools^[1]. This is the control that decides what a session can do after everything else has failed, and it is the one that matters most for maker-provided credentials, where the account is a shared service identity rather than a person.

Limit web access to vetted domains and limit which desktop applications are available. Microsoft names the mechanisms: Microsoft Edge policy settings delivered through Microsoft Intune for the first, application control for the second, both applied to the machines used for computer use.

Those last two overlap in purpose with the tool-side allow list below, and it is worth being clear that they are not the same control. Device policy stops the software from running at all. The tool-side allow list stops the model from acting, and, as the next part makes plain, that is a narrower promise.

The tool layer: access control, and exactly what it does not do

By default computer use can operate on any website or application. Turning on access control replaces that with an explicit list: you enter website addresses, where the main address includes all pages on that site and wildcards cover subdomains, and desktop application product or process names.

The part to read twice is the boundary, because it is the single most misread sentence in the computer use documentation. Microsoft states: Access control only prevents the model from taking actions on websites or applications that aren't in the allow list. It doesn't stop the model from opening them. For example, if only microsoft.com and Microsoft Edge are in the allow list, the model can still use the Microsoft Edge search bar to open Bing. However, once Bing is opened, any attempt to interact with it fails because it isn't in the allow list^[1].

So access control is an interaction boundary, not a navigation boundary. The unlisted page can appear on screen. The model cannot click anything on it. Two consequences follow. A screenshot of an unlisted page can still be captured and stored with the session evidence, which matters if the concern is data exposure rather than unwanted writes. And the network-level version of this control, the Intune-delivered Edge policy above, is what actually prevents the page loading, which is why Microsoft lists both rather than treating either as sufficient. The runtime signals when a boundary is hit are the error codes CuaWebsiteIsNotAllowlisted and CuaDesktopAppIsNotAllowlisted, whose documented resolution is to add the target to the allow list in the tool's settings. Microsoft's documentation spells this feature's list as both allow list and allowlist; this guide uses allow list.

Enforce HTTPS, which blocks two different things

Enforce HTTPS is the narrowest control on the page and the easiest to reason about. Microsoft: Turn on Enforce HTTPS to ensure computer use works only with HTTPS websites (whose URL starts with https://). When this setting is turned on, computer use doesn't interact with HTTP sites, helping protect against potential data exposure^[1].

The error codes reveal that this single toggle is enforced at two separate moments, which is more than the setting description suggests. CuaWebsiteIsNotSecure covers the general case, described as the website isn't served over HTTPS. CuaInsertCredentialNotAllowedInInsecureWebsites is specifically about typing a secret, described as inserting a credential on a non-HTTPS website is blocked. Both carry the same documented resolution: use the HTTPS version of the website or disable HTTPS enforcement^[3].

That second code is the one worth carrying into a design review. Even where a plain HTTP intranet page is harmless to read, it is exactly where a stored credential must not be typed, and the setting draws that line for you.

Why any of this is load-bearing: the injection case

The reason these controls are not paperwork is that the model's input is untrusted by construction. It reads whatever is on the screen, including text somebody else put there. Microsoft states the risk directly: Computer-use agents might encounter prompt injection attacks, where hidden instructions in screenshots, web pages, or other inputs attempt to influence actions in unintended ways. To minimize this risk, operate these agents within trusted, isolated environments and apply robust validation checks before executing any instructions^[7].

Read the control set through that lens and it stops looking like a checklist. The dedicated machine limits what an injected instruction can reach. The least-privilege account limits what it can change. The allow list limits which surfaces it can act on. Enforce HTTPS limits where a credential can be typed. Human supervision, the subject of the next section, is the one control that asks a person, and it is the only one of the five that is probabilistic.

Human supervision lets a session stop and ask. Microsoft's definition: When you use human supervision, the computer-using agent escalates to the person you configure in the Human supervision settings when it needs confirmation or more information^[7].

That makes it a human checkpoint in the sense Create a human-in-the-loop agent flow uses the term: a genuine pause with a person on the other side, not a formality like tool confirmation. But it differs from an authored checkpoint in one decisive way, and the difference is the whole exam-relevant point. An Approval action in an agent flow pauses because you put it at a step. A human review request happens because the model decided to raise one. The figure below traces the three ways a paused session ends.

What you configure, and the three ways it resolves

The Human supervision block asks who to contact by email if the session detects potentially harmful instructions that could alter model behaviour, and sets a response time limit. Microsoft is precise about the expiry behaviour: The response time limit defines how long the request remains active. After this period, the request expires, and the computer-use run stops if no response is received^[1]. Said from the other side: if you don't provide a response, the workflow remains paused and automatically stops when the timeout specified in the email is reached^[7]. The corresponding error code is CUAHitlRequestTimeout.

A reviewer who does respond can do so from the email itself or inline in the activity side panel, and the session then resumes its run from the paused step on the map^[2]. For a confirmation request the response is literally Yes or No typed into the email's text box.

The third outcome is the one that surprises people, and it inverts the obvious assumption that removing reviewers makes the agent more autonomous. Microsoft states the opposite: Turning off human supervision doesn't make the computer-using agent fully autonomous. The agent still pauses when it needs confirmation or clarification. If no reviewers are configured, these requests have nowhere to be routed, so the session fails when the agent pauses. Configure at least one reviewer^[7]. The matching error code is CUAClarificationNoReviewers. Leaving the reviewer list empty does not remove the checkpoint, it removes the destination.

Choosing a reviewer who can actually review

The reviewer is not a rubber stamp, and Microsoft attaches two requirements to the choice. The first is authority and context: ensure the recipient is authorized and has the necessary context to handle such requests^[1]. The second is visibility, and it is a mechanical constraint rather than advice: Each agent run and its activity is tied to the user who initiated it. If you choose a reviewer other than the person running the computer-use agent, they likely don't see the activity because they didn't initiate the run. Therefore, they can't properly verify or act on the request^[1].

A reviewer who cannot see the session cannot assess it, and will either approve blind or let the request expire. Both are worse than not having asked.

The documentation is not fully settled on how far that visibility constraint extends, so it is worth stating the tension rather than picking a side. The configuration field invites you to assign requests to reviewers, and the human supervision article describes removing all reviewers from an Assign requests to list. The same article also carries a narrower note: Only the maker of the computer use tool receives human review requests and has access to verbose logs^[7], adding that when End user credentials is selected, the person who originally set up the connection receives these requests, but only if they are also included among the designated reviewers. There is also an error code, CUAClarificationConnectionOwnerNotReviewer, whose resolution is to add the connection owner to the human supervision reviewers. The safe design under either reading is the same: make the connection owner one of the configured reviewers, and do not assume a reviewer who is neither the maker nor the initiator will see anything actionable. Check the live article before relying on a broader reviewer list.

What human supervision is not

Microsoft is unusually direct here, and the wording is worth carrying verbatim into any design conversation. Review requests are triggered by probabilistic model behaviour, so they might not trigger in every situation where a person would want a pause. They might also trigger when a pause isn't necessary. You shouldn't rely on clarification requests as a safety fail-safe or as a guarantee that the system will always request human input before proceeding^[2]. The same article adds that requests for human supervision don't guarantee enforcement of your defined rules, policies, or constraints^[2].

That is the sharpest contrast with an authored checkpoint. An Approval action in an agent flow fires every time control reaches it, because the position is the trigger. A human review request may or may not fire on any given session, because the model is the trigger. If a step must never happen without a person, the deterministic controls in the previous section, and an authored human-in-the-loop step elsewhere in the design, are what enforce it. Human supervision improves the odds of catching a surprise. It does not make a promise.

Everything up to here decided what a session was allowed to do. This section is about proving what it did. That evidence is the second half of this page's title, and it is unusually rich for a Copilot Studio tool, because a computer use session leaves screenshots.

Start from a distinction that already exists in this guide. Copilot Studio publishes two forms of activity tracking: Real-time activity map of your agent's performance during testing, and Historical activity maps and transcripts from past activities^[8]. The first lives in the Test your agent panel and shows a session while it executes. The second is the agent Activity page, which holds maps and transcripts for sessions that already finished. Both are the agent surfaces, distinct from the agent flow Activity tab covered on Monitor agent flows; Microsoft's computer use articles occasionally say Activity tab for the agent surface, and this guide says agent Activity page throughout. The figure below places the surfaces relative to each other.

Two views of a finished session

Open a session from the agent Activity page and you can switch between the Activity map and Transcript views^[6]. They answer different questions and you will use both.

The Transcript view is the narrative. For computer use specifically, it shows how computer use follows your instructions, providing a step-by-step log with reasoning messages and screenshots for each action^[6]. This is the surface that answers why did it do that, because the reasoning message sits next to the screenshot the reasoning was based on. It is the same information the left panel of the test experience showed live, preserved for a session you were not watching.

The Activity map is the structure: the sequence of nodes for the whole interaction, of which the computer use action is one. Selecting that node is what opens the detailed evidence.

The session details panel

Select the computer use action in the activity map and Microsoft opens what it calls the advanced computer-use activity panel, a side panel with comprehensive session information^[6]. Its published sections are worth knowing by name, because they are the answer to most forensic questions you will be asked:

• Description, what the tool does.
• Session replay, a series of screenshots captured during the session with navigation controls.
• Activity, listing action types, action coordinates, the user context used, action timestamps, and screenshots for each step.
• Summary, carrying the instruction text, the inputs, duration and number of actions, average time per action, number of screenshots, human escalation count, machine name and link, and machine user login.
• Websites & applications, the sites and desktop apps accessed.
• Credentials used, the credentials used to access resources such as websites.
• Export session logs, for offline review.

That set closes several loops from earlier sections at once. Machine user login and Credentials used tell you which of the two credential doors was used and as whom. Websites & applications is the audit counterpart of the allow list. Human escalation count tells you whether human supervision fired on this session at all, which is what you need when the trigger itself is probabilistic.

One dependency comes with it, and it explains a panel that is simply missing. This rich view exists because computer use logs are stored in Dataverse, which is an environment setting an administrator owns and which is on by default. Microsoft's own note is the one to remember: If the advanced computer-use activity experience doesn't appear in the activity map, your administrator might have turned off this feature for your environment^[7]. Crucially, transcripts are not affected, because Microsoft states they continue to include basic computer use logs, screenshots, and all other agent and tool logs, regardless of the configuration here^[6]. So the absence of the panel narrows your evidence, it does not eliminate it, and the transcript remains available. Configuring that setting is an administrator's job; recognising its effect on your evidence is yours.

Triaging past sessions, and why the status can lie

When you have hundreds of finished sessions rather than one, the agent Activity page has status filters. Microsoft: To narrow down sessions by status, select either of the following filter pills at the top of the session list: Failed, Blocked, In progress, Waiting for user or Completed^[8]. Two of those pills are the ones you will reach for most on this tool: Blocked when you are hunting for a session that was refused something, and Waiting for user when you are hunting for one that is paused for an answer. Microsoft does not publish a mapping from pill to cause, so treat both as starting points for a search rather than as diagnoses in themselves.

One caution before you build a triage habit on those pills. The pill vocabulary is not the only status vocabulary Microsoft publishes for activity: the same article describes an activity's own status in a different set of words, and separately tabulates agent states including Submitted, Input required, Auth required, Complete, Canceled and Rejected. Treat the five filter pills as filter labels rather than as a canonical state machine, and do not map them one-to-one onto the state table.

More importantly, Microsoft documents that the status can be wrong for computer use in particular: In the agent's Activity tab, the agent session status might show as "In progress", although the session might be completed. To validate that the computer use session is completed, select the agent session and switch to transcript mode^[3]. Read alongside the previous paragraph, that gives a clean division of labour for this page's monitoring surfaces. Use the status filters to find candidate sessions quickly. Use the Transcript view to establish what actually happened. Status is a triage signal, the transcript is the record, and on this tool the documentation explicitly tells you not to trust the first as the second.

There is a second visibility rule that catches teams rather than individuals. On the agent Activity page, only your own interactions with the agent and where the agent used your credentials for authentication appear, unless the system admin enables sharing of activity transcripts with other users. Your agent must use integrated Microsoft authentication to identify your interactions^[8]. A colleague reporting that a session is missing from their view may be seeing that rule rather than a lost session.

Finally, this page's evidence surfaces are per-session and in-product. When the requirement is aggregate telemetry across many sessions, alerting, or correlation with the rest of an application estate, that is a different mechanism entirely and belongs to Monitor agents by using Application Insights.