AI Agents With Their Own Login: Who Owns the Work When an Agent Is a Colleague?

Until recently, an AI agent at work borrowed someone's login. It ran under the person who built it, sent email as them and read whatever they could read. When that person changed role or left, the agent either broke or kept running with access nobody had meant to give it.

That is changing. In October, Microsoft and Google both announced agents that get their own work account, with an email address, a place in the company directory and their own permissions. Colleagues can @mention them, email them and hand them tasks the way they would with a new hire.

That is useful. It also moves a set of questions from IT into operations. Who is responsible for the agent? What can it see? What happens to what it remembers? And how do you switch it off cleanly? This guide covers what the two vendors have actually announced, what is still unclear, and a short checklist to work through before an agent joins your directory.

What are AI agents with their own work accounts?

On 15 October, Microsoft announced agent accounts in Copilot Studio. Agents work in Microsoft 365 with their own credentials, can be invoked in Teams and Outlook, and can be @mentioned in comments in Word, Excel and PowerPoint. Microsoft's point is attribution: work can be traced to the agent rather than to whichever person built it.

A week earlier, on 8 October, Google introduced coworker agents as part of its new Gemini agent. Google says a coworker agent "receives its own Workspace account, including an email address, calendar, Drive, and presence in your company directory." Colleagues add it to a Chat space or @mention it, and when it suggests an edit in a Doc it appears under its own name in version history.

The shared idea is simple. The agent stops being a feature inside one person's account and becomes a member of the organisation, with its own identity.

Can my organisation use agent accounts today?

Probably not yet, and it is worth being clear about that.

Microsoft's documentation for agent accounts labels the feature as part of the Frontier preview programme, Microsoft's early-access track, and marks the page as prerelease documentation that may change. The prerequisites are specific. The tenant must be enrolled in Frontier, the environment must be on the early release cycle, an admin must switch the feature on in two admin centres, and the person building the agent needs a Microsoft 365 E5 licence with the Agent 365 add-on or an E7 licence. Each published agent also takes a dedicated "Microsoft 365 Frontier for AI Teammates" licence. If none is free, publishing fails.

Google has not published plan availability, pricing or a general availability date for coworker agents in its announcement. We could not confirm which Workspace or Gemini Enterprise editions will include them, or whether an agent's account counts as a licensed user. If you run on Workspace, ask your Google account team before you plan around it.

So treat this as a preview of where both platforms are heading. The governance questions, though, apply now to any agent you already run under a person's login.

Why does an agent's identity matter for a small team?

In a 20-person firm, nobody has a dedicated identity team. Access tends to grow by habit: someone shares a folder, someone adds a mailbox, and nobody writes it down. That works for people because people are visible. You notice when a colleague is reading the wrong files.

An agent is less visible. It works around the clock, reads quickly and does not ask whether it should. For a bookkeeping practice holding client ledgers, an advisory firm with client portfolios, or a nonprofit with donor and beneficiary records, the question "what can this agent reach?" carries real weight.

A separate identity helps here, because it lets you scope the agent to its job and see what it did. Google describes every Gemini agent as having its own identity "governed like an employee, with least-privilege permissions," with every action written to an audit trail "attributed to the agent rather than to a person." Microsoft says agent accounts let admins govern and audit the agent like any other identity in Microsoft Entra. Neither benefit arrives by default, though. You still have to decide the scope.

Who should own an AI agent with its own login?

Every agent needs one named human owner. Not "IT" and not "the team". One person who answers for what it does.

Microsoft's current design makes this concrete, and slightly awkward. In the preview, the agent's email address uses the builder's own alias as a fixed prefix, and the agent reports to the builder. Microsoft notes you cannot change that prefix, the reporting line or the email address after publishing. Microsoft's Entra Agent ID documentation also records the person who created a Copilot Studio agent as its sponsor.

That matters for small firms, where the person keenest to build agents is often the operations lead or a founder. Decide before you publish whose name the agent sits under, and what happens if that person moves on. If the answer is "we would rebuild it", write that down now rather than discovering it later.

What should an agent account be allowed to access?

Start from the job, not from the person who built it. List the specific mailboxes, folders, sites and systems the process genuinely needs, and grant only those.

Two details from Microsoft's documentation are worth knowing. First, giving an agent an account does not grant every tool permission automatically. Each tool has its own authentication mode, and some still act under the end user's identity, so check which identity each tool uses. Second, agents with an account cannot read documents protected with sensitivity labels such as Confidential or Internal Only. Microsoft explicitly warns against downgrading a label just to let the agent in.

For financial back-office firms in particular, that second point is a useful guard rail rather than a nuisance. If a document is sensitive enough to carry a protective label, it is probably not where an early-stage agent should be working.

What happens to what the agent remembers?

This is the question most teams will not think to ask, and it is the one with the sharpest edge.

According to Microsoft's FAQ for agent accounts, an agent with its own account uses shared memory, even in one-to-one chats. What one person tells it can be used in later conversations with other people. Microsoft is direct about the limit: "shared memory has no privacy boundary between users." The agent's profile card warns that files or chats shared with it can be summarised in responses to any user, even users without permission to the originals.

In this preview, users cannot opt out of shared memory, and admins cannot switch it off without turning off agent accounts altogether. Shared memories are deleted automatically if nobody interacts with the agent for 28 days.

For a nonprofit handling safeguarding notes, or an advisory firm discussing a client's circumstances, that changes what staff should share. The practical rule: talk to a shared agent as you would post in a team channel. If you would not post it there, do not tell the agent.

Should a coworker agent replace a workflow you already have?

Not by default. An agent with an account is good at work that arrives in messy forms: an email asking for an update, a comment in a document, a request in a chat thread. It is less suited to steps that must happen the same way every time.

Microsoft itself says it plans to recommend that makers convert stable, repeated steps into workflows. That is the right instinct. Keep fixed, rule-based steps, such as posting a payment, sending a receipt or updating a status field, in a deterministic workflow. Give the agent the parts that need judgement and context, then have it hand back to the workflow or to a person.

We covered a similar split in when to hand a workflow decision to an agent, and the logic carries over.

A checklist before an agent joins your directory

Work through these before any agent gets its own account, whichever platform you use.

If you cannot fill in a row, the agent is not ready for its own login. That is not a reason to stop. It is a reason to keep it narrow until you can.

The real shift is organisational, not technical

Giving an agent its own account is a sensible design. It makes agents easier to scope, easier to audit and harder to lose track of when people change roles. It is a clear improvement on agents quietly running under a colleague's login.

But it also means agents now look like staff in your directory, and they deserve the same basic onboarding discipline: an owner, a role, defined access and a plan for leaving. Small teams that set those habits during the preview period will be ready when the features reach their plan. Teams that skip them will be cleaning up access later.

At Nuevexa, we help organisations design and implement agents inside the tools they already pay for, with ownership, access and hand-offs settled before anything goes live. If you want to see which of your processes suit an agent and which are better left as workflows, our AI agent implementation service and our guide to what to automate first with AI agents are good places to start.

Book an automation scan to map where an agent would help and what it should never touch.