Microsoft announced this week that computer-using agents in Copilot Studio are now generally available. The announcement landed on the Microsoft Copilot blog on 26 May, written by Nitasha Chopra, VP and COO of Microsoft Copilot Studio.
For organisations already running Copilot Studio agents, this changes what agents are capable of in practice. An agent that previously needed an API to do anything useful can now operate the user interface of a website or desktop application directly. That opens up a long list of automation scenarios that were previously out of reach, particularly anything involving legacy systems or third-party portals where no API exists.
It also opens up a different conversation about governance. UI-driven agents and API-driven agents behave differently. They fail differently. They leave different audit trails. They use credentials differently. If you have an existing governance framework for Copilot Studio agents, it was almost certainly designed around API-based interactions, and it probably needs a second look before you start putting computer-using agents into production.
What actually changed
The new capability lets an agent log into a system the way a person would. It can read the screen, click buttons, fill in forms, and move through a workflow that was never designed to be automated. Microsoft is positioning this as a fix for the gap left by legacy systems and vendor portals that lack APIs.
Three additional capabilities are being flagged alongside the GA release.
Credential management has been described as more secure, with organisations now able to manage how agents authenticate to the systems they operate.
Model selection now lets you choose the model that suits a particular automation scenario, rather than running everything through a single default.
Resilience to interface changes has been improved, so an agent is less likely to break when a screen layout shifts.
There is also a preview capability that embeds computer-using agents directly into multi-step workflows, so an automation can combine API actions, approvals, business logic, and UI interactions inside the same flow.
Why UI-driven agents behave differently from API-based ones
An API call is a structured exchange. The agent presents a scoped token, the system checks the permissions, the call returns a structured response, and the whole transaction is logged in a way that is easy to audit. If something goes wrong, the call usually returns an error.
A UI-driven agent is a different kind of actor. It logs in as a person, or as a non-human identity that has been granted person-like access, and it then sees and acts on whatever that login can see and act on. The blast radius is whatever the account can do, not what a scoped API token allows. The audit trail is whatever the underlying application happens to log for that user session. The failure mode is not always a clean error. Sometimes the screen changes, the agent misreads it, and the agent does the wrong thing quietly.
That is not a reason to avoid computer-using agents. It is a reason to think about them carefully before deploying them, particularly in regulated environments.
Credentials and identity
If a computer-using agent is going to operate a portal on behalf of the business, it needs an identity to log in with. That identity needs to exist somewhere in your IAM model. A few questions worth working through before deployment:
Does the agent have its own identity, or is it borrowing a person's account? Borrowing creates serious accountability and offboarding problems.
What is the agent allowed to do in each system it operates? The principle of least privilege still applies, possibly more so than for human users.
How are the credentials stored, scoped, and rotated? Microsoft has improved this, but improvement is not the same as setting it up correctly for your environment.
Who is accountable when the agent makes a decision a person would not have made? This is a governance question, not a technical one.
Audit trails and observability
API-based agents create reasonably clean logs at both ends. Copilot Studio records the call, the target system records what it received. A UI-driven agent creates a session log inside Copilot Studio, but the target system only sees a user session. Reconstructing what an agent actually did, particularly when something went wrong, is harder.
For organisations evaluating agents against Australia's 8 AI Ethics Principles, this is directly relevant to transparency, contestability, and human-centred values. For organisations preparing for ISO/IEC 42001 certification, it touches AI system documentation, performance monitoring, and incident management. The technical capability has moved ahead of where most internal governance frameworks currently sit.
Where to start
A few practical steps for any organisation considering computer-using agents.
Inventory the use cases you are considering, and split them into ones where a UI-driven agent is genuinely the only option, and ones where an API would do the job. Use APIs wherever they exist.
For the UI-driven cases, work through the identity, credential, and access model before you build the agent, not after.
Define what observability looks like. If the agent does the wrong thing, how will you know, and how quickly?
Put a contestability mechanism in front of any agent that touches a decision affecting a person.
Update your AI inventory and your privacy policy disclosures to reflect what these agents do. The Australian automated decision-making transparency obligations under the Privacy Act take effect on 10 December this year, and computer-using agents are well within scope.
Computer-using agents are a genuine capability shift. They open up automations that were not practical before. The capability is real, and the governance work that goes alongside it is just as real. Both deserve attention before the first production deployment.
If your organisation is deploying Copilot Studio agents and would like an independent look at how they sit against the relevant governance frameworks, that is what Aureus Govern does. The Health Check is the easiest entry point, full details at aureussolutions.com.au/govern.
References
Chopra, N. (2026, May 26). New and improved: Computer-using agents, a new workflows experience, and real-time voice experiences. Microsoft Copilot Blog. https://www.microsoft.com/en-us/microsoft-copilot/blog/copilot-studio/new-and-improved-computer-using-agents-a-new-workflows-experience-and-real-time-voice-experiences/
Microsoft. (2026). Computer-using agents in Microsoft Copilot Studio are now generally available. Microsoft Tech Community. https://techcommunity.microsoft.com/blog/copilot-studio-blog/computer-using-agents-in-microsoft-copilot-studio-are-now-generally-available/4519427
Microsoft. (2026). Computer use in Microsoft Copilot Studio. Microsoft Learn. https://learn.microsoft.com/en-us/microsoft-copilot-studio/computer-use
Department of Industry, Science and Resources. (2024). Australia's AI Ethics Principles. https://www.industry.gov.au/publications/australias-artificial-intelligence-ethics-principles/australias-ai-ethics-principles
Office of the Australian Information Commissioner. (2026). Australian Privacy Principle 1: open and transparent management of personal information. https://www.oaic.gov.au/privacy/australian-privacy-principles/australian-privacy-principles-guidelines/chapter-1-app-1-open-and-transparent-management-of-personal-information
