Microsoft announced Copilot Studio autonomous agents yesterday, and IT teams and governance leads are already talking about them. That doesn't surprise me. These agents run without anyone at the keyboard, triggered by events such as a new email or a new database record rather than by a prompt, and that opens up new options. In many of the Microsoft 365 and Power Platform environments I've worked in, though, this kind of potential quickly runs into a harder problem: fitting the agents into the existing security, identity and data governance frameworks.

Autonomous agents start on events instead of user prompts

With classic Copilot or Power Automate flows, a user always kicks off the process. Autonomous agents start on their own when an event trigger fires. That gives you more flexibility, especially with the ten prebuilt agents for Dynamics 365 that Microsoft has just previewed. But whenever automation stops depending on a user prompt, the governance stakes go up considerably. To me this is a natural next step for Copilot Studio. Still, it's a preview (rollout is planned for Ignite in November), so many details are still coming out, particularly on identity, auditing and control.

The agent's identity decides whose permissions it uses

The first governance question I ask is about identity, meaning whose credentials an autonomous agent actually runs under. Even with classic flows it isn't always obvious whether an action uses the creator's account (the maker) or the credentials of the user who triggered the event. With Copilot Studio autonomous agents this matters even more, because no user action is involved at all. Microsoft says both "maker credentials" and some form of "user delegation" are in scope, but so far there are very few technical details. For sensitive workflows such as payments or data writes, you'll need to be clear about the difference between service accounts, delegated user access and privileged roles.

This simple diagram shows the agent's execution model as Microsoft currently describes it:

flowchart TD
    Trigger["Event trigger"] --> Agent["Autonomous agent"]
    Agent --> Identity["Actions under identity"]
    Identity --> Maker["Maker account"]
    Identity --> User["User delegation (if supported)"]
    Agent --> Connectors["Connector access"]

Figure: Identity and execution model of Copilot Studio autonomous agents.

An agent can act with the maker's credentials or, where supported, in a delegated user context. Either option has significant consequences for access control and auditing once you deploy it in a real environment.

DLP policies control which connectors an agent can reach

I always put control over connectors and actions near the top of the list. Data Loss Prevention (DLP) policies in the Power Platform have matured and now offer some granularity. You can decide which connectors (Outlook, SQL or Salesforce, for example) may be used or combined, and which actions are blocked. For autonomous agents this matters even more, since data can easily end up in third-party systems without a user ever looking at it. You manage all of this centrally in the Power Platform Admin Center, and managed environments now add the monitoring and enforcement that was missing. If you want the details, start with Microsoft's documentation on Copilot Studio DLP or my earlier post on Copilot Studio governance and Power Platform DLP.

My practical tip: Don't just copy your classic flow DLP policies over to autonomous agents. Map the new triggers and flows first, and expect to lock things down a lot more tightly.

A dedicated managed environment makes monitoring and audit easier

In my experience, people often don't think enough about which environment to use. Managed environments in the Power Platform now give you a baseline for central monitoring and deployment logging, and, just as important, a clean separation between production and experimental workflows. For autonomous agents I recommend a dedicated environment with its own permissions and a clear approval process. Copilot Studio audit logs record changes to agents, but full run-time auditing and monitoring still means manual review and external tools. I hope Microsoft adds better telemetry and alerting for agent activity soon.

Human approval steps and costs still need attention

One big gap, at least for now, is human-in-the-loop support. The idea is that agents run on their own but stop and wait for explicit approval at risky points. For high-stakes automation you really need this. There are technical workarounds (adaptive cards, approval flows), but they often feel bolted on next to the otherwise streamlined agent experience.

Keep an eye on cost as well. Every agent run generates messages, and those count as billable flow transactions. Copilot Studio follows the Power Platform licensing logic here, so if you plan to use autonomous agents at scale, you have to track message usage and quotas actively. Billing for the new agent preview isn't final yet, but I don't expect it to differ much from the current Power Platform model.

I would proceed but govern these agents tightly

Autonomous agents are a logical next step for Copilot Studio, but they need careful governance from the first day. Without strong identity controls, restrictive DLP policies and a clear split between production and test, they can easily turn into a shadow IT problem. If you want to run a pilot as soon as the preview is available, start with a dedicated environment, strict DLP and explicit process separation. I plan to come back to this topic once best practices take shape after Ignite, because I'll be following it closely.