Somebody’s name is already on it
An agent doing work in your organisation is doing it under somebody’s authority. Almost nobody has decided whose. Knowing what exists is a separate job, and a smaller one. This is about who answers for the thing once it is running, and what happens to it over the years it keeps running.
Start with the fact that makes it concrete. Employee-facing agent usage carries no charge for Microsoft 365 Copilot licensed users, subject to fair-use limits, when the agent runs under the licensed user’s identity. That clause is normally read as a pricing rule, and it is one. It is also a statement about accountability. The thing acting in your tenant is not an anonymous service. It is a named person’s identity, doing work that person did not personally do, sometimes at hours that person is asleep.
Every control you already have attaches to people. Leavers processes, access reviews, the disciplinary policy, your data protection obligations. The agent has quietly borrowed a person to hang all of that on, and nobody signed anything.
The person who built it is the worst available default owner
Most registers I see record the builder as the owner, because the builder is the field the system can populate automatically. It is the wrong answer almost every time, and it is wrong for a reason that has nothing to do with the builder’s competence.
An owner has to be able to do four things. Stop it, or change what it does. Answer for what it produced, to somebody who is annoyed. Fund it, including the work of checking it. And explain, without help, what it can see and what it cannot.
The builder can usually do the first and the last. The middle two belong to whoever owns the process the agent performs. If the agent drafts responses to a regulator, the owner is the person accountable for responses to that regulator. If it triages a queue, the owner is whoever answers for that queue at the end of the month. The builder is a supplier. Naming a supplier as the accountable party is a mistake we learned not to make with systems, and are cheerfully making again with agents because the build took an afternoon.
This gets sharper where the agent is anywhere near a decision about a person. Under the Data (Use and Access) Act 2025, in force from 5 February 2026, the four mandatory safeguards on automated decision-making remain: tell people it is happening, allow representations, provide meaningful human intervention, and allow the decision to be contested. Every one of those is a job for a named human with standing. The ICO’s draft guidance on automated decision-making and profiling puts it more bluntly, saying human involvement must be active rather than tokenistic, with trained, qualified reviewers who understand the system’s logic and limitations. That is still draft. The consultation closed in May 2026 and the final version has not been published.
If your named owner cannot describe what the agent can see, they are a nameplate, not an owner.
I let the builder be the owner and a reorganisation took it apart
I have made this mistake in a way I would rather not have. On one piece of work I helped set up an agent register, and I let the owner field default to whoever created the agent. It looked tidy. It passed a review. It worked for about a year.
Then the organisation moved some teams around, as organisations do. The person who had built one of the more useful agents moved to a different directorate. The agent stayed where it was, still running, still under her identity, still feeding a team she no longer had anything to do with. Its output started going wrong. Not dramatically. Consistently slightly wrong, after a form changed. The person accountable for the process had never heard of the agent, and the person named in the register had no authority over the process and no reason to look.
Nobody had done anything careless. The register was accurate. It was accurate about the wrong thing, which is worse than being out of date, because being out of date at least prompts someone to check.
What I do now is record ownership against a post, not a person, and against the process rather than the build. “Owner: Head of Customer Operations” survives a reorganisation. A named individual survives until that individual gets promoted. The register also carries the builder separately, because you do need to know who to ask how it works, and that is a genuinely different question from who answers for it.
Reassigning the owner is a button. Deciding who gets it is not
The tooling has moved ahead of the organisational design here, which is unusual and worth noticing. Since Agent 365 reached general availability for Commercial on 1 May 2026, the governance actions available to every Microsoft 365 Enterprise, Business, Education and F plan include reassigning an agent’s owner, along with conditions-based lifecycle rules. On E7 or Agent 365 it goes further and treats agents rather like staff, with Entra access packages for agents and Conditional Access for agents, per the same service description.
Read what that implies rather than what it lists. An access package needs an approver, an entitlement period and a review owner. Conditional Access needs somebody to state which conditions, on what grounds. Lifecycle rules need somebody to say what the conditions are and what should happen when they fire. None of those are administrative settings in any meaningful sense. They are joiners-movers-leavers decisions applied to a thing that is not a person, and the organisation has to supply the policy before the tenant can enforce it.
So the capability arriving does not relieve you of the design work. It makes the absence of the design work visible, which is the useful part. You can now be asked, by a system, a question you have been able to avoid until this year: on whose authority does this run, and for how long.
Nobody plans the decommissioning, and everybody needs it
Ask an agent programme how an agent ends and you will get a pause. Ask how one starts and you will get a slide.
Every agent should have an end condition written at build time, in the same document as the owner. Not a review date. An end condition: the circumstance under which this agent should stop existing. Usually one of three. The process it serves changes materially. The system it reads from is replaced. Or the demand it was built for goes away, which happens more often than people expect, because a lot of agents are built for a backlog rather than a permanent job.
Decommissioning is a service change, not a delete. Somebody was relying on the output. Something has to replace it, or somebody has to be told it is not coming. If its output fed a report, or informed a decision about a person, then the audit trail has retention obligations that outlive the agent itself. And whatever the agent was reading is still sitting there, still permissioned the way it was, which is a separate tidy-up nobody remembers to do.
The conditions-based lifecycle rules will automate part of this once you have decided what the conditions are. The deciding is the work.
The agent that outlives its process is the one that hurts you
Worry less about the rogue agent. The failure mode that costs you is the obedient one.
An agent does not resign, go on leave, or mention that the process changed in April. It carries on doing precisely what it was told to do in a world that has moved. Copilot Cowork is generally available as part of Microsoft 365 Copilot, with scheduled and event-driven tasks among other things, which means work now happens on a timetable with nobody in the room. That is the feature. It is also the exposure. Wrong output that looks exactly like right output, produced reliably, on a schedule, for months.
This is why the review cadence is not bureaucratic overhead. It is the only mechanism that catches silent failure. My working version is light and specific. Every agent gets a short quarterly check by its owner: is this still needed, is the output still correct on a sample, has anything it reads changed. Material agents get a proper annual review with somebody other than the owner in the room, and by material I mean anything touching customer data, money, or decisions about people. And three events force an unscheduled review regardless of the calendar: a reorganisation, a leaver who owns or built one, and a change to the underlying process.
The data to support that exists already. Admin centre reporting covers readiness, usage and credits, Purview holds the audit logs, and Copilot Studio has its own analytics. What is missing is not visibility. It is a named person whose diary says look.
I would also expect the rules to keep moving. The ICO lists guidance on agentic AI as in drafting, with no public consultation planned, expected Winter 2026. Whatever it says, it will land on organisations that either can or cannot name the accountable human for each agent they run. That is the question worth being ready for, and it does not require anyone to buy anything.
If you want a single test for whether you have done this, it is not the size of your register. Pick one agent, ask who owns it, and see whether the answer is a post or a person, and whether that person knows.