Support available 24/7/365 1 (773) 999-3946 hello@baygramm.com Live chat
All articles AI & Automation

AI Agents Are Getting Their Own Accounts: A Governance Checklist

Google's Gemini agent and Copilot Studio agent accounts give AI agents mailboxes and directory identities. What changed and how to govern them.

In the space of a week this October, Google and Microsoft both moved AI agents out of the "assistant inside your app" model and into the org chart. On October 8, Google Cloud announced the Gemini agent, and its coworker agents receive their own Workspace account, "including an email address, calendar, Drive, and presence in your company directory." On October 15, Microsoft announced agent accounts for Copilot Studio, which "allow agents to work in Microsoft 365 with their own credentials, similar to how any person would."

Both are previews, and the details will change. But the direction is clear: the agents your teams build next year will have mailboxes, directory entries and permissions of their own. That is good news for accountability, because work can finally be attributed to the agent instead of to whichever employee set it up. It also means every agent is a new identity your security, records and finance teams have to manage. Here is what each platform shipped, where the risks sit, and what to put in place before the first agent account goes live.

What Google shipped: identity, policy and spend caps

Google Cloud CEO Thomas Kurian introduced the Gemini agent at Gemini at Work 2026 as "your new single, universal agent for work." For governance, the relevant details are in how Google describes identity:

  • Dedicated identities. Coworker agents have "their own @agents.company.com emails, their own persistent storage, and only have access to the context that you or your team members provide." A coworker agent "acts under its own identity rather than yours."
  • Least privilege and attestation. Google says every agent gets an identity that is "cryptographically attested and governed like an employee, with least-privilege permissions," and that identity is stamped into its logs and into any virtual machine it spins up to run code. Sub-agents that Gemini creates for multi-step jobs each get their own identity too.
  • Auditing. "Every action Gemini takes is written to an audit trail and attributed to the agent rather than to a person."
  • Central policy. You write a policy once, such as "agents may not open documents classified Need to Know," and Gemini applies it to every agent. Traffic in, out and between agents passes through Agent Gateway, which Google describes as an AI network firewall, and agents run inside an Agent Sandbox with its own network boundary.
  • Spend caps. Admins can set a hard limit on a project's AI spend in the Cloud Billing Console. If the cap is hit, that project's agent pauses until someone resumes it, and because tracking is per project, costs can be charged back to departments.

Availability is limited for now. Google says the Gemini agent "is now in preview for Financial Services and Legal, and coming soon to Government, Healthcare, and Retail."

What Microsoft shipped: accounts, shared memory and triggers

Microsoft's announcement pairs three features. Agent accounts let people assign work to an agent in Teams and Outlook, and @mention it in comments in Word, Excel and PowerPoint. Business process memory lets the agent carry context forward across cycles. Triggers let an external signal such as an email, or a set cadence, start the agent's work with no prompt required. Microsoft says these features are rolling out through its Frontier program.

The Copilot Studio documentation fills in what an account actually is:

  • The agent gets its own Microsoft Entra ID, mailbox and presence across Microsoft 365, so "admins can govern and audit it like any other identity." Microsoft Agent 365 provisions and governs these accounts, and Copilot Studio also creates a separate Microsoft Entra Agent ID for each one.
  • The agent's email address uses the maker's alias as a fixed prefix, and the agent reports to its maker. In the preview, neither the prefix, the reporting line nor the email address can be changed after publishing.
  • An account "does not automatically grant every tool permission." Makers choose which identity each tool uses, and tools that act as an end user still need that person's sign-in and consent.
  • Licensing is layered: makers need Microsoft 365 E5 with the Agent 365 add-on, or Microsoft 365 E7. Each published agent consumes a Microsoft 365 Frontier for AI Teammates license, and building, testing and running agents can consume metered Copilot Credits on top.

Current preview limits matter for process design. The agent does not respond to anyone outside its tenant, only replies in email conversations with up to 250 people, can generate new documents but cannot co-author existing ones, and cannot read documents protected with labels such as Confidential or Internal Only. Microsoft explicitly warns against relabeling documents as a workaround to test agents against sensitive content.

Microsoft also notes what is not there yet: "Additional access policies, quality, cost management, and lifecycle controls specific to these agents are planned for in the coming months."

The shared-memory question your data owners need to answer

The most important governance detail in either launch is easy to miss. Microsoft's FAQ explains that an agent with an account keeps one shared memory across everyone it works with, even in one-to-one chats. The agent's People card carries this notice: "Any files or chats you share can be summarized and included in the agent's responses to any user, even users without permissions to the files or chats and regardless of sensitivity label."

Key takeaway: An agent account is a shared colleague, not a private assistant. In Microsoft's preview, what one person tells the agent can surface for anyone else who works with it, and shared memory "has no privacy boundary between users."

The FAQ adds that end users cannot opt out of shared memory in the preview, and admins cannot turn it off on its own; to disable it, an admin must turn off agent accounts altogether. Anyone who interacts with the agent can view or delete its saved memories, and memories are deleted automatically after 28 days with no interaction. Microsoft says shared memory excludes items such as passwords, credentials, ID numbers and health information. That is helpful, but it is a filter, not an access control. Before an agent joins a team, decide whether that team's conversations are appropriate to pool.

Why this is an identity program, not a chatbot rollout

Once an agent has an account, the questions are the same ones you ask about any non-human identity: who owns it, what it can reach, how its access is reviewed, and how it is retired. NIST's National Cybersecurity Center of Excellence has been working on exactly this. Its February 2026 concept paper, "Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization," asked industry how existing identity standards apply to agents, with detailed questions on identification, authorization, auditing and non-repudiation, plus controls against prompt injection.

The vendor launches answer some of those questions with product features: attributed audit logs, scoped permissions, central policies, spend caps. They do not answer the organizational ones. Someone still has to decide which processes deserve an agent, who is accountable when it acts, and what happens to its mailbox, files and license when the process changes.

A checklist before your first agent account

  1. Name an owner for every agent. Microsoft ties the agent to its maker; make that formal. Record a business owner, a technical owner and the process it serves.
  2. Add agents to your identity lifecycle. Include agent accounts in joiner-mover-leaver workflows, access reviews and license reclamation. In Microsoft's preview, publishing fails if no AI Teammates license is free, so track who holds them.
  3. Scope tool access per agent. Grant only the connectors and permissions the process needs, and check which identity each tool runs under: the agent's or the end user's.
  4. Decide where shared memory is acceptable. Start with teams whose working information is already shared, and brief users on the memory notice before they start.
  5. Keep sensitivity labels intact. Do not relax labels to make an agent useful. Use approved, non-sensitive samples for testing, as Microsoft advises.
  6. Route agent logs to your SIEM. Both vendors attribute actions to the agent's identity. Make sure those logs land where your security team already watches, with alerts for unusual access.
  7. Set spending limits up front. Use project spend caps on Google Cloud, and plan for metered Copilot Credits separately from account licenses on Microsoft.
  8. Treat triggers as change control. An agent that starts on an email or a schedule acts without a prompt. Review trigger configurations the way you review scheduled jobs.
  9. Write a retirement procedure. Define what happens to the agent's mailbox, files, memory and license when a pilot ends.

Agent accounts make AI easier to delegate to and easier to audit, but only if they are governed like the identities they now are. Baygramm helps organizations design and deploy AI agents with ownership, least-privilege access and logging built in from the start, and our cybersecurity team can fold agent identities into your existing access reviews and monitoring. If you are planning a Copilot Studio or Gemini agent pilot, talk to us about setting the guardrails first.

Work with us

Talk to a Baygramm specialist

Tell us where you are and what you're trying to get done. We'll tell you honestly how we can help.

Talk to us Our AI & Automation work