Securing Copilot Studio Agents: What Changes When AI Can Use Websites and Desktop Apps? 

The security model changes the moment an AI agent can click a button inside a live business system. 

Copilot Studio computer-using agents are now generally available. They can navigate websites and Windows applications, read what appears on screen, enter information and continue a task even when an interface changes. 

For enterprises, that opens up a category of automation that has always been difficult: legacy applications, supplier portals and desktop systems that offer limited APIs or no practical integration route. 

It also gives the agent a much more consequential than access to information: the ability to act through the same interfaces employees use. 

A procurement agent could check delivery status on a supplier portal. An accounts agent could enter approved invoice data into an older finance application. An operations agent could retrieve information from a desktop system and update another application. 

Each use case can remove substantial manual work. Each also creates decisions that traditional workflow automation did not require at the same level: 

• Which credentials should the agent use?  

• Which screens, websites and applications can it access?  

• Which actions can it complete without approval?  

• What should happen when the screen contains unexpected information?  

• How can security teams reconstruct an agent’s actions after an incident?  

• Who can stop the agent immediately?  

Earlier automation gave enterprises considerable control because developers defined the path in advance. Computer-using agents add interpretation to that path. They can inspect the current screen and determine how to proceed towards a goal. 

That capability makes Copilot Studio agents particularly useful for legacy system automation. It also means that access control, approval boundaries, exception handling and auditability have to become part of the agent design from the beginning. 

For CIOs, the question is therefore very practical: 

Where should an agent be allowed to act, and where should enterprise controls take over? 

That is the decision this article examines. 

Fig 1: Computer use extends Copilot Studio agents from conversational tasks into direct interaction with websites and desktop applications. 

What actually changes when an AI agent can use a computer? 

Consider a procurement agent tasked with checking supplier delivery status. 

A conventional Power Automate workflow could receive an approved purchase request, send notifications, update SharePoint and route decisions according to explicit rules. 

A computer-using agent could go further: 

1. Sign in to a vendor portal that provides no API. 

2. Search for the purchase order. 

3. read the status shown on screen. 

4. Navigate to a delivery-details page. 

5. capture the expected delivery date. 

6. open an internal desktop application. 

7. update the procurement record. 

8. continue when the supplier changes the location of a button or field 

This removes a difficult manual hand-off. 

The security question also changes. 

The organization has given an AI system credentials and an interface through which it can act. 

Microsoft itself warns that computer use may perform unintended actions when instructions are ambiguous or the screen contains unexpected information. Web pages and screenshots can also contain malicious instructions designed to influence the agent’s behaviour through prompt injection. 

For an enterprise deployment, four questions therefore matter immediately: 

• Which applications can the agent enter? 

• Whose credentials does it use? 

• Which actions can it complete autonomously? 

• How will the organization reconstruct what happened after a failure? 

Those questions should shape the architecture before the first production agent receives access. 

Where do computer-using agents actually make sense? 

Computer use has the greatest value at the stubborn end of enterprise automation: applications people still depend on even though those applications expose poor APIs, old interfaces or no practical integration method. 

Strong candidates include: 

• entering approved invoice information into a legacy finance application; 

• retrieving order or shipment status from supplier websites; 

• updating claim status in external portals; 

• copying approved employee information into older HR applications; 

• gathering procurement information from vendor portals; 

• extracting values from proprietary desktop systems; 

• completing repetitive web forms after an upstream workflow has validated the data. 

The process should already have a clear business outcome. 

Computer use should solve the last-mile interaction problem, not compensate for an undefined process. 

A practical procurement scenario: what should the agent do? 

Imagine an organization that raises procurement requests internally but must use an external supplier portal to track fulfilment. 

The agent could: 

Read: Open the supplier portal and retrieve current shipment status. 

Compare: Match the supplier reference with the approved internal purchase order. 

Record: Update delivery information in the procurement workspace. 

Escalate: Flag a late shipment or mismatch for the procurement team. 

These actions have a narrow objective and leave important business decisions with governed workflows. 

Now consider a different set of actions: 

• changing the supplier’s bank account; 

• approving an unplanned purchase; 

• accepting revised contractual terms; 

• changing an approved purchase value; 

• releasing a payment; 

• creating a new privileged vendor account. 

Those actions carry a much higher consequence if the agent makes the wrong interpretation. 

The distinction gives CIOs a useful design principle: 

Let the agent handle interpretation and repetitive interaction. Put material business commitments behind explicit controls. 

Microsoft’s own guidance says computer use is not intended for financial transactions or sensitive decision-making such as scoring in employment, healthcare or finance. 

Oman Air shows why the approval boundary matters 

Aufait Technologies faced the workflow side of this problem while digitizing procurement for Oman Air. 

The airline relied on slow, paper-heavy procurement processes across purchase requests, approvals and purchasing activities.

  

Fig 2: Oman Air’s Procurement Management System   

Aufait implemented a Microsoft Power Platform procurement management system with a central SharePoint repository, automated alerts and traceable workflows. The system gave leadership clearer visibility into expenditure while creating an auditable procurement process. 

That implementation predates Copilot Studio computer use, but it provides an important architecture lesson for agentic automation. 

If a future agent needed to retrieve supplier status from a portal that offered no API, computer use could handle that interface interaction. The approval logic, purchase authority, audit record and budget rules should continue to live in governed enterprise workflows. 

This creates a stronger architecture: 

Agent handles difficult UI interaction → Power Automate enforces process rules → authorized person approves high-impact decisions → system records the outcome 

The agent gets flexibility. The organization keeps control. 

For a deeper look at that foundation, see Aufait’s guide to Power Automate legacy system integration. Power Automate legacy system integration 

1. Credential control comes first 

Computer use needs a way to sign in to applications. 

Microsoft supports maker-provided credentials and end-user credentials. It can store credentials inside encrypted Power Platform storage or use Azure Key Vault. 

Fig 3: Computer-use agents should operate only with approved credentials and within defined website and application boundaries. 

The maker-credential option deserves particular scrutiny. 

Microsoft warns that when an organization shares an agent configured with the maker’s credentials, users of that agent may act with the original maker’s access on the configured machine. 

That makes credential design an architectural decision. 

For production agents: 

• create dedicated identities where the use case allows it; 

• grant the smallest set of permissions required for the task; 

• separate read access from write access where possible; 

• keep privileged administrator credentials away from autonomous agents; 

• store secrets through approved enterprise credential mechanisms; 

• rotate and revoke agent credentials through a documented process. 

An agent that only needs to check invoice status should not inherit permission to modify vendor master data. 

The agent’s access should match the task, not the person who built it. 

2. Restrict where the agent can act 

Microsoft allows administrators and makers to define allow lists for websites and desktop applications. Computer use also supports HTTPS enforcement. 

Use those controls aggressively. 

If an agent should work only with supplier.company.com and a procurement desktop application, give it that boundary. 

Microsoft notes an important detail: the allow list prevents the model from acting on unapproved websites or applications, although the browser may still open another site. 

Enterprises should therefore combine application allow lists with machine-level restrictions. 

Microsoft recommends dedicated machines, least-privilege accounts, restricted web access and limiting the applications installed on machines used for computer use. 

Think of the machine as part of the agent’s security perimeter. 

3. Human approval needs a precise boundary 

Copilot Studio supports human supervision. The agent can pause and ask an authorized reviewer for clarification or confirmation when it encounters uncertainty or potentially harmful instructions. 

That is useful. 

It is also insufficient as the only safety mechanism. 

Microsoft explicitly states that human-supervision requests rely on probabilistic model behaviour. The agent may fail to request a review in a situation where a person would expect one. Microsoft advises organisations to combine supervision with restricted environments, least-privilege access, allow lists and other safeguards. 

Therefore, define approval checkpoints around the business consequence, rather than expecting the AI to decide when a human is necessary. 

For example: 

Agent may autonomously: retrieve invoice status. 

Agent must escalate: invoice value differs from purchase order by more than the permitted tolerance. 

Human must approve: vendor-master change or contractual amendment. 

Agent cannot perform: payment release. 

This gives auditors and business owners a policy they can actually inspect. 

4. Exception handling becomes a business requirement 

Traditional automation teams often focus on the happy path. 

Computer-using agents make exception design more important because screens can contain unexpected content. 

Imagine an agent entering an invoice. The portal freezes after the agent clicks Submit. The agent cannot tell whether the transaction succeeded. 

A careless retry could create a duplicate. 

The architecture needs a recovery rule: 

Check transaction status → confirm whether the record exists → retry only when the system shows no successful submission → otherwise escalate. 

Every high-value process should define: 

• what counts as successful completion; 

• how the agent verifies success; 

• how many retries it can make; 

• when it must stop; 

• who receives the exception; 

• how the organisation prevents duplicate transactions. 

Adaptive automation still needs deterministic failure rules. 

5. Logging must answer “What exactly did the agent do?” 

Copilot Studio provides unusually useful visibility for computer use. 

Microsoft’s activity details can show session replay, screenshots, actions, coordinates, timestamps, websites and applications accessed, machine information and credentials used.  

Organizations can also export logs and send computer-use audit events to Microsoft Purview under the CUAOperation activity. 

This visibility should become part of the production design. 

For important agents, establish: 

• log-retention requirements; 

• security-team access to agent activity; 

• alerting for repeated failures or abnormal behaviour; 

• periodic review of sensitive actions; 

• a procedure for investigating disputed transactions. 

Remember that screenshots themselves can contain sensitive business information. Microsoft allows administrators to reduce advanced log verbosity and configure retention. 

The logging policy therefore needs to balance auditability with data minimization. 

Build Copilot Studio agents with governance designed in from day one. 

 
Aufait Technologies helps enterprises define access boundaries, approval logic, Power Automate actions and monitoring for production-ready AI agents. 

 
Explore Microsoft Copilot Agent Implementation → 

What does legacy automation look like when AI enters the UI? 

Aufait has already seen the value of automating systems that cannot communicate cleanly. 

For a global gold trading and jewellery business operating across 13 countries, the existing Microsoft Dynamics AX environment lacked direct integration with the central billing system. Staff entered information twice, invoices took longer to generate and manual errors created reconciliation problems. 

Aufait implemented an RPA solution using Power Automate and Power Automate Desktop to connect the mobile sales process with central billing. The implementation reduced customer waiting time by 85% and billing errors by 90%. 

Computer-using agents extend the options available for this type of problem. 

A traditional RPA bot works particularly well when the steps and interface remain predictable. A computer-using agent becomes attractive when the process needs visual interpretation and the UI changes frequently enough to make selector-based automation expensive to maintain. 

The enterprise still needs to choose the right tool. 

Read Dynamics 365 legacy ERP integration: what CIOs must decide first for the wider decision between APIs, middleware, RPA and other integration patterns. Dynamics 365 legacy ERP integration: what CIOs must decide first 

Computer use, RPA or API: which should CIOs choose? 

Use this decision hierarchy. 

Situation	Better starting point
Stable API exists	API or connector
Business process follows clear rules across connected systems	Power Automate
Stable desktop UI with repeatable steps	Power Automate Desktop / RPA
Website or desktop application lacks APIs and requires visual interpretation	Copilot Studio computer use
High-risk transaction needs strict deterministic execution	Governed workflow/API with explicit approvals
Process mixes reasoning, legacy UI and approvals	Hybrid agent + Power Automate architecture

Computer use should broaden the automation toolkit. It should not automatically replace working APIs, connectors or RPA. 

The strongest enterprise architecture will often combine them. 

The security checklist before a computer-using agent reaches production 

Before approving production access, CIOs should be able to answer these eight questions: 

1. What exact business outcome can the agent complete? 

2. Which websites and desktop applications can it act on? 

3. Which identity and credentials does it use? 

4. Does that identity have the minimum permissions required? 

5. Which actions require deterministic approval outside the agent’s discretion? 

6. What happens when the screen, data or process becomes ambiguous? 

7. Can we reconstruct every important action through logs and session history? 

8. Who can stop, disable or retire the agent? 

Microsoft allows administrators to disable computer use at the Power Platform environment level, which gives IT another important control over rollout. 

For organizations building broader low-code AI governance, Aufait’s analysis of enterprise security for low-code AI platforms provides additional guidance on DLP, role-based access, monitoring and human intervention. 

The real change: automation can now interpret before it acts 

Computer-using agents solve a genuine enterprise problem. 

Many organizations still run important processes through applications that will never receive modern APIs. Employees bridge those systems manually because traditional integration costs too much or breaks too easily. 

Copilot Studio gives enterprises another way through that constraint. 

The same capability also expands the control surface. 

Once an agent can see a screen, interpret what it sees, use enterprise credentials and take an action, security can no longer stop at authentication. 

The enterprise must define where the agent can go, what it can change, when it must ask, what happens when it fails and how somebody can reconstruct its actions later. 

That is the difference between experimenting with a computer-using agent and operating one as enterprise infrastructure. 

Modernise the workflow without losing control of the action 

Aufait Technologies combines Copilot Studio, Power Automate, Power Platform and legacy-system automation expertise to help enterprises identify the right agent use cases and build the controls around them. 

Talk to us about your next enterprise automation use case → 

Disclaimer: All images belong to their respective owners.  

Frequently Asked Questions