Between June and the end of September, four vendors announced persistent agents with memory. Two reach your data through an admin. Two reach it through an employee's consent click, and your tenant's defaults decide whether that click is enough.
On September 29, OpenAI began rolling out Dots to ChatGPT Pro and Business Premium users in eligible markets. OpenAI's launch post calls them "always-on agents," says "each dot works on its own cloud computer," and says they "can readily connect to over 4,000 apps." Three weeks earlier, on September 8, Meta announced Muse, a personal agent that runs on what Meta calls "a dedicated, virtual machine (VM) that houses both the agent and a person's data," and that is "free for most of what people need." On a personal plan, neither one asks your IT team for anything.
If an employee points one of these agents at a work mailbox, the approval standing between the agent and your company's data is a consent screen. In a Microsoft Entra tenant on its default setting, the employee is allowed to click through it alone. What comes out the other side is standing non-human access, created by an end user, held by a vendor you have no contract with, and backed by memory that outlives the grant.
My position is simple. Treat a consumer agent's grant to a work app as a provisioning event, and move the decision from the employee's consent click to an admin's review. Not a ban. A different approver.
Two doors into the same tenant
The workplace versions of this product arrived through the admin. Anthropic's Claude Tag announcement on June 23 says "system administrators specify which tools and information the model should have access to, in which channels," and that "everything, including its memories, will stay scoped to the channels defined by the administrators." Microsoft's September 25 post says Autopilot "lives in your tenant with its own identity, memory, computer and workspace," with "permissions, audit and governance behind it." OpenAI's own admin article for ChatGPT Enterprise says "Dots access is off by default for Enterprise," and its admin controls article says that for Enterprise and Edu, "in general, new plugins and apps are disabled by default."
The consumer versions arrive through the person. OpenAI's launch post says "You choose which apps dots can access and can manage their permissions through your existing ChatGPT app controls." Meta says "people choose which apps Muse connects to and exactly how much access it gets," and for email, "whether it reads their mail or can also send on their behalf." Read and send is a write grant, approved by whoever is holding the phone.
Same capability, different approver. When the subscription is the employee's own, the workspace controls above aren't yours to set, so the only control you hold is the one at your own tenant. Even the admin door has a default worth checking: the same article says "In ChatGPT Business, apps are enabled by default."
Your tenant's defaults already answered the question
Microsoft's Entra documentation on user consent is blunt: "By default, all users are allowed to consent to applications for permissions that don't require administrator consent. For example, by default, a user can consent to allow an app to access their mailbox but can't consent to allow an app unfettered access to read and write to all files in your organization." The mailbox is the example Microsoft chose. It's also the first thing a personal agent wants.
Google Workspace runs the same way. Its admin documentation on controlling app access lists the setting for unconfigured third-party apps, and the first option, "Allow users to access any third-party apps," is marked as the default.
The grant may also predate the agent. OpenAI's workspace article says "Supported app connections that a member already uses in ChatGPT may be available to their dot," and its Dots FAQ says "Plugin permissions are shared across dots, ChatGPT, ChatGPT Work, and Codex." A mailbox connection someone approved months ago for a chat window can now feed something that works while they sleep. The same FAQ adds that you can "set up a separate Slack account for your dot, giving it its own identity and access in those services." If that account lands in your company's Slack, an end user just created a non-human member of your workspace.
Microsoft's recommendation is to "allow user consent only for applications that have been published by a verified publisher," and its built-in policy for that also limits users to permissions you classify as low impact. I'd go at least that far. A verified publisher check tells you who built the app. It doesn't tell you whether an always-on agent should hold a mailbox, so the permission classification is the part doing the work.
This risk differs from a browser agent riding your session cookies in one useful way: a consented grant leaves a record. It shows up in Entra as an enterprise app with a User consent tab, and in Google's Admin console under "Accessed apps." That's the good news. You can count it.
Tightening the setting won't touch grants already made
This is the part I'd want every identity owner to know before Monday. Entra's documentation says "Any updates to user consent settings only affect future consent operations for applications. Existing consent grants remain unchanged, and users continue to have access based on the permissions previously granted." Every grant an employee made between the Muse launch and the day you change the setting still stands.
Revocation has two more catches in Entra. Microsoft's review page says "You can't revoke permissions in the User consent tab using the portal"; you revoke them through Microsoft Graph or PowerShell. And "Revoking the current granted permission doesn't stop users from re-consenting to the application's requested permissions." So order matters: restrict user consent first, open the request path second, revoke third. Revoke first and the employee simply consents again the next morning.
Google behaves differently, which is worth knowing if you run both. Its documentation says that if you change a service's access to Restricted, "any previously installed apps that you haven't trusted stop working, and tokens are revoked." On that lever, Google's restriction reaches back to existing tokens. Entra's consent setting doesn't.
If Okta fronts your sign-in to Microsoft 365, I'd still run this review in Entra. Microsoft's review steps apply to every application "added to your Microsoft Entra tenant via user or admin consent," so that is where the grant can be read and removed. The identity provider decides who signs in. The grant decides what an app can keep doing afterwards.
Revoking the grant doesn't revoke the memory
This is where agents differ from the SaaS integrations most teams have spent years cleaning up. OpenAI's Dots privacy, security and safety FAQ says "Your dot can receive memories and recent conversation context from ChatGPT," and that it "can retain context from your conversations and plugins for as long as you keep your dot." On disconnecting a plugin, the FAQ says: "This stops new access through that connection. It does not delete information your dot has already built into its context." Turning off ChatGPT Memory "does not delete information that your dot has already received."
That's honest documentation, and it's the right design for a personal product. For an employer, it means a revoke stops the flow and leaves the reservoir. Whatever the agent pulled from a work inbox before you revoked stays in its context, on a cloud computer you never issued, in an account you don't administer. The FAQ's deletion entry reads "This deletes your dot's own context," and it's addressed to the dot's owner. Meta's announcement describes Muse from the same angle: it "remembers what matters to a person" and can "act on details that person only mentioned once."
Agent memory is already a data-residency problem when the memory store is yours. This is the harder case. The memory is real, it holds your data, and it sits on no inventory you can write to.
OpenAI's ChatGPT Space page draws a second boundary just as precisely. "Sharing a page does not give collaborators access to your private chats or personal memory," it says. "But anything you or ChatGPT write on the page is visible to people with access, including personal details drawn from memory." The share button isn't the boundary. The text is. When an agent drafts a page from what it remembers, the memory crosses into the page as prose, and everyone with access reads it. For workspace plans, the same page says "Your workspace's admin settings and sharing rules still apply." Those rules decide who can be invited, not what the agent chose to write.
The leaver checklist has no line for this
Offboarding is where this turns into an audit finding. When I modernized corporate IT and endpoint security at Altais, workstation lifecycle and asset management were part of the work, and that discipline rests on one assumption: the asset is something you can count and collect. The laptop, the badge, the account, the shared drive. A delegated grant to a personal agent isn't on that list, and the agent's memory isn't on anybody's.
Disabling the work account is still the first move. I'd add an explicit step after it: enumerate the departing user's delegated grants, revoke them, and invalidate refresh tokens, rather than assume the disable covers every path. Microsoft's review documentation covers both operations. Then accept the limit plainly. Context already copied into a personal agent leaves with the person, so the exit acknowledgment should name personal AI agents the way it names personal devices. A written commitment to delete is the control you have left.
That's why the usual agent offboarding playbook doesn't quite fit. It's written for agents you provisioned. This agent was never yours to offboard. Only the grant was.
Move the decision to an admin, then give people a yes
The controls aren't exotic. Most of them are settings you already own.
- Change who approves. In Entra, restrict user consent to verified publishers and permissions you've classified as low impact, or turn it off. Then enable the admin consent workflow. Per Microsoft, a user who can't consent "can send a request for admin approval," which goes by email to reviewers you designate and expires after a number of days you set. In Google Workspace, move unconfigured third-party apps off the default and turn on user requests, which land in "Apps pending review."
- Allowlist the agents you'll support. Pick a path you can govern: an enterprise workspace where Dots and new plugins start off, an agent that administrators scope to channels they define, or one that lives in your tenant with its own identity. Configure the approved ones in Google as "Specific Google data," which Google says "Can request data access only to scopes that you specify when configuring the app."
- Review and revoke what's already there. Pull the user-consented grants for every app with mail, calendar, or file permissions. Rank them by what each can reach, and treat send as a write grant. Revoke after the consent setting is tight, not before.
- Put the grant in the leaver runbook. Revoke delegated grants and refresh tokens by name, and add personal agents to the exit acknowledgment.
- Write the page rule down. Anything an agent writes on a shared page is shared. Classified data stays out of pages an agent drafts from memory.
We built AgentOS around scoped tool authority, an audit trail, and memory with provenance. Those are the first three things I ask about any agent with access. An agent connected by a consent click on someone's personal plan shows you none of that from your side. The admin door doesn't fix everything, but it gives you an approver, a scope, and a record.
Don't skip the yes. A rule that only blocks pushes people toward the account you can't see at all, which is the same lesson as the shadow AI line. Publish the list of agents you support, and make the request path faster than the workaround.
What I'd do Monday
In a fintech serving 1,500+ financial institutions, the question I expect in due diligence is who approved each path to a partner's data. "The employee clicked Accept" is a true answer and a bad one. So, in this order:
- Open Entra, go to Enterprise apps, Consent and permissions, User consent settings, and write down what it says. Do the same for the unconfigured third-party apps setting in Google's Admin console.
- Pull the apps holding user-consented mail, calendar, and file permissions, plus Google's "Accessed apps" list. Mark anything that's an agent.
- Tighten consent and turn on the admin consent workflow with named reviewers, before you revoke anything.
- Revoke the grants nobody can justify, through Graph or PowerShell for the Entra ones.
- Add delegated grants and personal agents to the leaver checklist.
These agents are useful, and your people will keep using them. The one thing you still control is who says yes to the grant. Make it someone whose job includes saying no.