On 15 October Microsoft gave Copilot Studio agents something they did not have before: their own Microsoft 365 credentials. An agent can now hold an identity, remember context between runs, and start work on its own when an email arrives or a schedule fires. That is a meaningful change in what you are governing.
Until now an agent borrowed a person’s access. It could only see what that person could see, and it only ran when that person asked. Both of those limits have gone. An agent with its own account has standing permissions and no working hours, which makes it less like a feature and more like a member of staff.
This article sets out what changed, what it means for risk, and the checklist to work through before you let agents loose. It assumes you already run Microsoft 365 and have somewhere between 50 and 2,000 staff.
Copilot agent governance is an identity problem before it is an AI problem. An agent with its own login, standing permissions and the ability to act unprompted is a new member of staff you never interviewed, and it should be onboarded like one.
What Changed in October
Microsoft’s Copilot Studio announcement on 15 October introduced four things. Agent accounts let agents work in Microsoft 365 with their own credentials and scoped permissions, rather than borrowing a maker’s or a user’s. Business process memory lets an agent carry context across runs instead of starting fresh each time. Agent refinements are planned over the coming months. And triggers mean an agent can start work from an external signal, such as an email, or on a set cadence.
Two caveats matter before anyone builds a business case. The capabilities are rolling out through Microsoft’s Frontier programme, so this is early access rather than general availability, and you should check what your own tenant can actually do today. Microsoft has also published no licensing or pricing detail alongside the announcement, so anyone quoting you a per-agent cost is guessing.
The combination is what matters. Identity plus memory plus triggers describes something that runs continuously and accumulates context, which is why Copilot agent governance is now a separate discipline from Copilot rollout.
Why an Agent With Its Own Account Is a New Kind of Insider Risk
Insider risk has never been mainly about malice. It is mostly about someone holding more access than their job needs and making an ordinary mistake with it. An agent fits that description precisely, with three differences that make it harder to manage.
It does not get tired, so a misconfiguration repeats at machine speed rather than once. It has no line manager noticing that it is behaving oddly. And because it holds its own credentials, the audit trail points at the agent rather than at a person, which means accountability has to be assigned deliberately in advance.
There is a second-order problem. An agent that remembers context between runs is accumulating a store of business information outside the places you normally govern. If you have spent effort labelling and protecting data in SharePoint and Exchange, an agent’s memory is a new location that your existing controls were not written for.
None of this argues against using agents. It argues for deciding who owns each one before it has access to anything, which is where Copilot agent governance starts.
Governing Copilot Agents Properly
Transputec runs a 24/7 Security Operations Centre in London with managed detection and response across endpoints, identity and cloud. Talk to our team about the governance work behind Copilot agents.
Get a Strategic ConsultationThe Copilot Agent Governance Checklist
Seven controls cover the risk for most organisations. None of them require new spend, and most are configuration in tooling you already pay for.
| Control | What it means in practice | Why it matters |
|---|---|---|
| A named human owner | One person accountable for what the agent does, recorded somewhere you can find it in six months | Without this, nobody disables a misbehaving agent because nobody is sure they are allowed to |
| Its own account | An agent account with scoped permissions, never a shared mailbox, a service account or a leaver’s login | Borrowed credentials make the audit trail useless and inherit permissions nobody reviewed |
| Minimum permissions | Start with read-only on one site or mailbox and add scope only when a task actually fails | Standing permissions are the whole risk; an agent keeps whatever you grant it indefinitely |
| Data scope and labels | Define which locations it may reach, and apply sensitivity labels so restricted content stays out of reach | An agent will use everything it can see, including the folder someone over-shared last year |
| Data loss prevention | DLP policies that apply to the agent’s actions, not only to human-initiated sharing | Policies written for people often do not evaluate automated activity |
| Human sign-off on changes | The agent may read and draft freely, but a person approves anything that writes, sends, pays or deletes | This single control turns most agent failures from incidents into rejected suggestions |
| Audit logs somebody reads | Log what the agent did, and put a named person or your SOC on reviewing it weekly | An unread log is evidence after the fact, not a control |
Work through it in order. The first three are the ones that prevent incidents; the last four are the ones that let you prove, to an auditor or a client, that the first three are real. If you only do one thing, make it the human sign-off on write actions.
Sorting Your Agents by Risk
Treating every agent the same is what makes governance collapse under its own weight. Sort them into three tiers and spend your attention accordingly.
Low risk: reads, drafts, suggests. An agent that summarises a mailbox or drafts a reply for a human to send. Light approval, standard logging, owner recorded.
Medium risk: writes to systems nobody outside sees. Updating a CRM record, filing a document, creating a ticket. These need scoped permissions and a review of what they touched, because errors propagate quietly.
High risk: anything external, financial or irreversible. Sending email outside the organisation, changing payment details, approving an invoice, deleting records. These need human sign-off on every action without exception, and they should be the last thing you automate rather than the first.
The tiering matters more than the policy document. Most organisations that get into trouble with Copilot agent governance do so because a high-risk action was built by someone who thought of it as a convenience.
Working Out What an Agent Costs You
Microsoft has not published pricing for agent accounts, so treat any specific per-agent figure you are quoted as unsourced. What you can do is build the comparison properly, so the number is yours rather than a vendor’s.
On the cost side, count the licence or consumption charge once Microsoft publishes it, the build time to create and test the agent, and the ongoing governance overhead, meaning the owner’s review time and the log review. That last one is the line most business cases omit and the one that persists.
On the benefit side, measure the task the agent replaces before you automate it. Time one person doing it ten times and take the median. A task that takes four minutes and happens twice a day is worth roughly a day a month; the same task happening twice a week is not worth governing.
If you want the broader picture on where Copilot has returned value for UK organisations, that is covered separately in our analysis of Microsoft Copilot ROI rather than repeated here.
Where the Cyber Security and Resilience Bill Comes In
The government is paying attention to autonomous agents, though less definitively than some coverage suggests. Its announcement of 12 October says stronger protections against emerging AI threats will be considered through the Cyber Security and Resilience Bill regime, and that it will explore strengthening parts of the Bill to protect essential services.
On agents specifically, it says work is underway with the National Cyber Security Centre and the AI Security Institute to look at how incidents involving AI agents should be responded to, and that near-miss reporting is being examined. It sets no deadline and places nothing under the Bill yet.
So the honest position is that nothing is required of you today. What is worth noting is the direction: if agent incidents do become reportable, the organisations that will cope are the ones that already know which agents they run, who owns them, and what each one touched. That register is useful regardless of what the Bill ends up saying. Our walkthrough of the Cyber Security and Resilience Bill covers the wider obligations.
A 30-Day Rollout Plan
Thirty days is enough to put Copilot agent governance around a first pilot, provided you resist starting with the interesting use case.
Week 1: find out what you already have. List every agent anyone has built, including the ones made in Copilot Studio by people outside IT. Record an owner against each. Expect to find more than you thought, which is the same pattern as shadow AI generally.
Week 2: set the rules before you build. Agree the three risk tiers, decide who approves a high-risk agent, and write it into your AI acceptable use policy. Check your sensitivity labels and DLP actually apply to agent activity, which is where Microsoft Purview does the work.
Week 3: pilot one low-risk agent properly. Own account, read-only scope, one mailbox or site, logging on, owner named. Let it run and read the logs daily.
Week 4: review and decide. Check what it actually accessed against what you intended. If those match, widen the scope or add a second agent. If they do not, you have learned something cheap, which was the point of starting small.
If Copilot itself is not bedded in yet, the Copilot readiness checklist comes first. Agents on an ungoverned tenant inherit every permissions problem already there.
How Transputec Approaches Copilot Agent Governance
Transputec treats Copilot agent governance as an extension of identity and data governance rather than a separate AI project. Engagements usually open with an initial security assessment that baselines the environment against ISO 27001 and Cyber Essentials Plus, which surfaces the permissions problems an agent would otherwise inherit.
From there the work runs through managed security services: a 24/7 Security Operations Centre in London where analysts triage alerts rather than forward them on, Managed Detection and Response covering endpoints, identity and cloud, and Microsoft Sentinel for organisations already invested in Microsoft. Agent activity is monitored as identity activity, because that is what it is.
Around that sit the periodic pieces that make governance provable: vulnerability management, penetration testing by OSCP-certified testers with remediation and a retest included, and evidence packs mapped to ISO 27001, Cyber Essentials Plus, FCA, ICO and GDPR Article 32 requirements. Reporting is monthly and written for a board rather than an engineer.
Conclusion
Agent accounts are a genuine shift, but the response is not novel. Give every agent a named owner, its own identity, the smallest scope that works, and a human in front of anything irreversible. Log what it does and have somebody read the log. That is most of Copilot agent governance, and none of it waits on legislation.
The organisations that will struggle are the ones that let agents accumulate without a register, then have to reconstruct who built what after something goes wrong.
If you want a view of what your tenant would currently allow an agent to reach, talk to our team about the identity and data governance work behind Copilot.
FAQs
Can Copilot Studio agents really have their own Microsoft 365 accounts?
Yes. Microsoft announced agent accounts on 15 October 2026, letting agents work in Microsoft 365 with their own credentials and scoped permissions rather than borrowing a user’s. The capability is rolling out through Microsoft’s Frontier programme, so check what your own tenant supports before planning around it.
What is the single most important control for Copilot agent governance?
Human sign-off before an agent writes, sends, pays or deletes anything. Reading and drafting can be left open. Requiring approval on write actions turns most agent failures from incidents into rejected suggestions, and it costs nothing to configure.
Does the Cyber Security and Resilience Bill cover AI agent incidents?
Not yet. The government’s 12 October 2026 announcement says stronger protections will be considered through the Bill regime and that it is working with the NCSC and the AI Security Institute on how agent incidents should be handled. No deadline has been set and nothing has been placed under the Bill.
How much do Copilot agents cost to run?
Microsoft has published no licensing or pricing detail for agent accounts, so any specific per-agent figure is guesswork at this stage. Build your own comparison instead: licence or consumption cost, build time, and the governance overhead of owner and log review, set against the measured time of the task being automated.
Where should an organisation with no agents yet start?
With an inventory rather than a build. Copilot agent governance starts with knowing what exists, so list what has already been created in Copilot Studio, including by people outside IT, and record an owner against each. Transputec usually finds more than the organisation expected, which is the same pattern as shadow AI.
This article was drafted with AI assistance and reviewed by the Transputec team. Featured image: AI-generated.
