Three vendors shipped agent ownership controls in five days. Transfer is not a records update — it re-scopes what an agent can do. Here is the build sequence, the portability test, and when to delete instead.
Last Updated: September 27, 2026
Between 21 and 25 September 2026, Google, Anthropic and Microsoft each shipped a piece of agent ownership. The mechanics are now real, and they expose the thing most governance writing misses: transferring an agent is a re-scoping event, not a records update. An agent inherits the effective permissions of whoever owns it, so handing a departing analyst's agent to a finance director can silently widen its blast radius. Build four things this quarter: an inventory keyed to a named human, credentials held by a service identity rather than the builder, trigger quarantine on every transfer, and an expiry date on every agent you inherit.
Three control planes shipped ownership in five days
The most operationally specific of the three came from Google, and it is worth reading the release note rather than the press coverage. On 21 September, Gemini Enterprise gained administrator transfer of ownership for shared, employee-made agents, with the documentation naming the exact scenarios: departing employees, contractor handoffs and team restructuring. Two days later Anthropic opened the Claude Marketplace. Two days after that Microsoft put Copilot Managed Runtime into public preview and renamed Scout to Autopilot.
Google ships agent ownership transfer in Gemini Enterprise. Only holders of roles/discoveryengine.agentspaceAdmin or roles/discoveryengine.admin can perform it, and an agent owner cannot transfer their own agent unless they are also an administrator.
Anthropic launches the Claude Marketplace with more than 2,000 connectors and plugins, and the ability to spend a portion of committed Anthropic budget on Claude-powered agents and products from vendors including CrowdStrike, Cursor, Harvey and Snowflake.
Microsoft introduces Copilot Managed Runtime in public preview, with Entra identity, organizational policies for connectors and endpoints, Git-backed versioning and a central app inventory in the Microsoft 365 admin center, alongside Autopilot — a persistent agent that, per Microsoft's briefing, maintains a distinct identity, memory, computing environment and workspace inside the organisation's Microsoft 365 tenant.
Agent identity is not runtime authorization
An agent identity is a row in a directory. Runtime authorization is the answer to a different question: at the instant this agent called this tool, who had delegated that authority, for what purpose, and within what limit? The two drift apart, and offboarding is precisely the moment they drift furthest.
Microsoft's own documentation is unusually clear about the coupling. Every Entra Agent ID that Copilot Studio creates is a directory object in your tenant that counts against your Entra resource quota, and deleting the agent removes the associated Agent ID. The same page states that tokens issued for an agent identity do not grant privileges beyond those already available to the agent owner. That is the right security property, and it has a consequence nobody puts on a slide: the agent's reach is a function of the human attached to it. Change the human, change the reach.
Google's model works the same way from the other end. In Gemini Enterprise, when actions are enabled for a data source, the end user has to click through an authorization step before assistant actions on that source will run. The agent is not authorized. A person is, and the agent borrows it.
Every agent has to have an identity. Everything it does needs to be observed.
— Satya Nadella, CEO, Microsoft, VentureBeat
Directory truth vs runtime truth
Directory truth is what your IdP says the agent may do today. Runtime truth is what the agent actually did at 03:14 last Tuesday, under whose delegated grant, and whether that grant still exists. Audit questions are almost always runtime questions, and almost no agent platform logs the delegation chain in a form you can replay. If your logs record the agent principal but not the human who delegated it, you cannot answer the only question a regulator or an incident review will ask.
What actually breaks the moment you press transfer
Five things, in roughly this order of nastiness.
The agents you most need to move cannot be moved. Google's transfer only works on agents that are already shared — private, unshared agents cannot be transferred at all. That is the exact profile of the risky agent: one person built it, nobody else has seen it, it quietly reconciles something every Monday. The fix is sequencing, not tooling. Make sharing a condition of any agent that touches a system of record, and run a sweep for private agents before a builder's last day, not after their account is disabled.
Transfer does not revoke. When Google moves ownership, the previous owner is demoted to the agentUser role and keeps permission to query and run the agent, losing only the ability to edit configuration. That is sensible for a team restructure and wrong for a departure.
Treating ownership transfer as offboarding
The transfer dialog feels final, so the offboarding ticket gets closed. But the leaver remains on the agent's permissioned-user list with run rights, and if they hold any residual credential path — a personal connector grant, a shared inbox, a contractor account that outlives the employee account — the agent is still a live route into your data under their name.
Triggers stop silently. Google disables schedules and event triggers on transfer and requires the new owner to re-enable them. As a safety default this is correct — it is the one piece of genuinely thoughtful engineering in the batch, because it prevents an unattended agent from acting under a new principal before anyone has reviewed it. Operationally it creates a second failure mode: nothing throws an error, the monthly filing just never happens. You need a reconciliation report that lists every disabled trigger with an owner and a due date, and you need it to escalate, because the new owner did not ask for this agent and has no idea it existed.
Credentials die with the account, the agent does not. OAuth grants for connectors are issued to the human. Deprovision the human and the tokens go, while the agent definition, its schedule and its downstream consumers all survive. You get an agent that runs and produces empty or stale output rather than one that fails loudly.
Letting the builder's personal OAuth grant be the production credential
It happens because it is the path of least resistance. The builder clicks authorize during prototyping, the agent works, and nobody goes back to swap in a governed credential. Six months later the connection has a person's name on it and a scope nobody reviewed.
Memory inherits with the agent, and there is no redaction primitive. Autopilot carries its own memory and workspace. If a departing manager's agent accumulated context from performance conversations, a supplier negotiation or an unannounced restructure, transferring the agent transfers that context to the recipient. I have not seen a vendor ship a credible way to selectively forget. The honest guidance today is to scope memory at creation — project-bound, not person-bound — and to classify agent memory as a records-retention class with the same deletion rules as the mailbox it learned from.
The portability test: what moves, what is stuck
Run this as an exercise, not a debate. Pick your three most load-bearing employee-built agents and try to reconstruct each one on a different stack in an afternoon. What you can rebuild is portable. What you cannot is a dependency you have already accepted, whether or not you decided to.
| Component | Portability in practice | The test to run this week |
|---|---|---|
| Instructions and prompts | Fully portable. Text is text. | Export every agent definition to a Git repository you control, not the vendor's. |
| Orchestration graph | Partially portable. Low-code builders export to proprietary JSON; code-first agents move cleanly. | Attempt one export, then re-import into a different runtime and diff the behaviour. |
| Tools and connectors | Portable at the protocol layer via MCP, stuck at the catalogue layer. An MCP server you host moves; a vendor marketplace listing does not. | Count how many of your agent's tools are self-hosted MCP servers versus first-party connectors. |
| Credentials | Not portable, and you should not want them to be. Each control plane brokers its own tokens. | List every connection whose principal is a named employee. |
| Memory and state | Effectively stuck. No standard export format, no selective deletion. | Ask your vendor for a memory export and a per-record delete API. Record the answer in writing. |
| Triggers and schedules | Trivially rebuildable, but the semantics differ — and Google disables them on transfer by design. | Produce a single list of every scheduled and event trigger across all platforms, with a named owner. |
| Audit trail | Stuck. Logs live in the control plane and rarely include the delegation chain. | Try to answer “who authorised this action, and does that authority still exist” from logs alone. |
| Purchased agent entitlements | Stuck by commercial design. Committed-spend marketplace purchases are contractual positions, not configuration. | Identify who inside the business is the named owner of each marketplace entitlement. |
The marketplace row deserves emphasis because it is the least discussed. Anthropic's model lets a team apply committed spend to third-party agents. That collapses procurement into a budget line, which is genuinely useful and also means a departing manager may leave behind a live entitlement nobody in finance recognises. Model and vendor choice is now partly a procurement question; we track the landscape on our models page.
The transfer checklist
This is the sequence we build for clients who have let employees create agents freely and now need the estate to survive staff churn. It assumes you will not get a complete inventory on day one — you will not — so it front-loads containment.
Agent handover, in order
On notice of departure, disable the leaver's scheduled and event triggers across every platform. Stopping a job is reversible; an unattended run under an expiring credential often is not.
Pull the admin inventory from each control plane and specifically flag unshared agents, because those are the ones the transfer tooling refuses to move.
Rank by what the agent can change, not how often it runs. A read-only agent used daily is lower risk than a write-capable agent used quarterly.
Re-authorise every connector under a team-owned service or workload identity with narrowed scopes. Do this before ownership moves, so the new owner never depends on the leaver's grants.
Read what the agent has retained. If it holds context the recipient should not see, rebuild the agent rather than transfer it.
Move ownership, then remove the previous owner from the permission list. Two actions, two pieces of evidence.
The new owner re-enables each trigger explicitly, with a budget bound to a cost centre. Microsoft's own position is that metered services stay inactive until an administrator creates a spending policy — inherit that default rather than fighting it.
Every inherited agent gets a review date no more than 90 days out. If nobody renews it, it is deleted. Orphaned agents are created by the absence of an expiry, not by the departure.
Steps 1, 4 and 7 are where most of the engineering effort goes, and they are the steps teams skip because the vendor UI makes step 6 look like the whole job. If you are standing this up alongside existing automation, we cover the surrounding build in our services.
When the right answer is decommission, not transfer
Default to deletion. Most employee-built agents are one person's workaround for a bad process, and the correct response to their departure is to fix the process rather than adopt their scaffolding. Transfer only when three conditions hold: someone can explain what the agent does without reading its prompt, a named team accepts the operating burden, and the agent's output feeds something you would notice within a day if it stopped. If any of those fail, disable the triggers, retain the definition read-only for a records window, and delete.
Here is the candour the vendor posts leave out. Most of what I have described is service-account hygiene that competent IT organisations have practised for twenty years: do not run production on a person's credential, keep an inventory, revoke on exit, cap spend. If you are already good at that, you are most of the way there, and you should be sceptical of anyone selling agent governance as a wholly new discipline.
Two things are genuinely new. First, agents hold delegated authority and accumulated memory, which means the permission that matters in an incident is the one held at the moment of action, not the one in your directory today — and almost no platform reconstructs that for you. Second, the systems now act unprompted: Anthropic's Claude continues delegated work after you have closed your laptop, and Microsoft's Autopilot is designed to resume a project days later. A cron job that fails is visible. An agent that keeps going under a stale delegation is not.
One note on evidence. Reports circulated this week about a research agent reaching non-public material on a government statistics portal. I could not open a primary source for it during this research, so I am not building an argument on it. The general principle stands without any incident to prove it: permission is not intent, and an agent granted broad read access will eventually read something nobody meant to expose. Design for that, not for the headline.
If you are deciding this quarter whether to standardise on a vendor control plane or keep ownership portable, the practical answer is usually both: portable definitions and self-hosted tools, vendor-brokered identity and spend. Our case studies show how those layers get split in practice, and you can start a conversation here.
Frequently Asked Questions
Who owns an AI agent when the employee who built it leaves?
By default, nobody — which is the problem. In Gemini Enterprise an administrator must explicitly transfer ownership to another user, and only administrators holding the Gemini Enterprise Admin or Discovery Engine Admin role can do it. Until that transfer happens the agent keeps a departed owner on record while its credentials quietly expire with the account. Assign ownership to a team-accountable role at creation time rather than resolving it at exit.
Does transferring ownership remove the previous owner's access?
No. In Gemini Enterprise the previous owner is demoted to the agentUser role and retains permission to query and run the agent, losing only configuration rights. That is appropriate for a team reshuffle and inadequate for a departure. Treat revocation as a separate, separately evidenced step in your offboarding runbook, and verify it against the agent's permissioned-user list rather than the owner field.
Why do schedules and triggers get disabled during a handover?
Because an unattended agent that keeps firing under a new principal is a re-scoping event nobody reviewed. Google disables schedule and event triggers on transfer and requires the new owner to re-enable them. The trade-off is silence: the work simply stops without an error. Pair the quarantine with a reconciliation report listing every disabled trigger, its new owner and a deadline for an explicit decision to re-enable or retire it.
What is the difference between agent identity and runtime authorization?
Identity is the directory object representing the agent. Runtime authorization is the delegated authority actually exercised at the moment of an action. Microsoft documents that tokens issued for a Copilot Studio agent identity grant nothing beyond what the agent owner already has, so effective permission derives from a human. Your audit trail needs to record that delegation chain, otherwise you can prove which agent acted but not who authorised it.
Should we standardise on one vendor control plane for agents?
Standardise identity, policy and spend on one plane, because fragmenting those creates gaps at exactly the wrong moments. Keep agent definitions, orchestration logic and self-hosted MCP tool servers in your own repositories so a platform change is a migration rather than a rebuild. The components you genuinely cannot make portable today are memory, audit history and marketplace entitlements — price that lock-in deliberately instead of discovering it later.
How do we stop an inherited agent from burning budget?
Bind spend to a cost centre rather than a maker, so the cap survives the handover. Microsoft extended Agent 365 spending management to Autopilot, Code and the managed runtime, with Copilot Studio agents due in October 2026, and keeps metered services inactive until an administrator creates a spending policy. Inherit that default: an agent whose new owner has not attached a budget should not be able to run at all.
When should we delete an agent instead of transferring it?
Delete unless three conditions hold: someone can describe what the agent does without reading its configuration, a named team accepts the operating burden, and its output is missed within a day if it stops. Also delete rather than transfer when the agent's accumulated memory contains context the recipient should not see, because no major platform currently offers selective forgetting. Rebuilding a simple agent is usually cheaper than inheriting an unreviewed one.
Research digest
AI Research Briefing
Honest insights on AI agents, Small Language Models, and local RAG. No hype. Only when we have something worth sending.
- No hype, just measurable outcomes
- Read by 2,400+ engineers
- Unsubscribe anytime