Why AI agent permissions outlive the people who grant them
Offboarding removes the person. It almost never removes the apps the person connected. Here are five patterns the audit keeps finding in Google Workspace, why each one happens, and what to do about it in ten minutes.
When we audit a Google Workspace for AI agents, one finding shows up almost every time. It is not exotic. It is a token that is still alive for an app that someone connected months ago, held by a person who has since changed roles or left, quietly polling for new mail or new files. Nobody decided it should still have access. Nobody decided anything. It just never came up.
This guide is about why that happens, what it looks like in practice, and how to close it off. The examples are illustrative composites of what the audit surfaces, with the names of the apps kept and the companies removed.
How an agent gets access in the first place
It takes one click. An employee tries a new AI tool, chooses "Sign in with Google", and sees a consent screen listing what the tool wants: see your email, manage your files, see your calendar. They click Allow. From that moment the tool holds a key that lets it act as that person, inside your company's Google Workspace, without anyone else being told.
That key does not expire when the person stops using the tool. It does not expire when they change teams. It expires when someone revokes it, or when the account it belongs to is shut down. In practice, that often means it does not expire at all.
The consent screen is the only access review most AI tools ever get. It lasts about four seconds.
Pattern one: the grant that outlived the person
Someone connects a tool, then leaves. Offboarding checklists are good at the person: disable the account, reset the password, collect the laptop. They are rarely good at the apps. And in many companies the account itself is not shut down cleanly. It is kept open for mail forwarding, handed to a replacement, turned into a shared mailbox, or simply left for a few weeks "until the handover is done".
Every one of those cases keeps the app's key alive. The audit found an app called Instinct in one Workspace that had been connected by a contractor whose engagement ended three weeks earlier. The account was still active for forwarding. The app was still polling Gmail every few minutes.
The fix: add one line to the offboarding checklist: "Review and revoke the third-party apps this person authorized." In Google Admin it is under the user's security settings. In AuditMyAgent it is the person's card, with every app listed and a confirm-to-revoke button beside each.
Pattern two: the app nobody uses anymore
Teams try tools. Most tools do not stick. The ones that don't stick keep their access anyway, because uninstalling an app from your phone or closing a browser tab does nothing to the key the app was given.
The audit compares the permissions an app holds with what it has actually done. An app with read access to mail for fourteen people, two of whom have not touched it in a month, is a common result. Those two grants are all risk and no benefit. If the app's vendor is ever breached, the attacker gets a working key into two inboxes that nobody is watching.
The fix: revoke access for any app and person combination with no activity in 30 days. If the person needs it again, reconnecting takes one click. The asymmetry is the point: reconnecting is cheap, and leaving a dead key alive is not.
Pattern three: the scope is wider than the feature
Apps ask for more than they need, because asking is free and asking again later is awkward. A meeting scheduler asks for full Drive access. A note-taker asks to send email. The person approving has no way to know whether that is normal, and the consent screen gives them no help.
One finding we see often: a scheduling tool called Muse holding calendar and read-only Drive access for nine people, installed for a booking feature that only ever needed the calendar. Nothing bad happened. But nine people's files were reachable by a tool that had no reason to reach them.
The fix: for each app, write down the one thing it is for, then compare that to its permissions. Where they don't match, either find a narrower way to connect it or decide, consciously, that the gap is acceptable. The audit puts the permission and the actual activity side by side so the gap is visible without any research.
Pattern four: one person said yes for everyone
Administrators can install an app for the entire company at once. It is convenient, and it is sometimes the right call. It is also one decision that creates a key into every inbox and every Drive, including the CFO's, including HR's, including the shared folder with the board papers.
The example on our homepage is drawn from this pattern: an app called Dots with full Drive access and the ability to send email, installed company-wide, with hundreds of Drive actions in its first month including a handful of files shared outside the organization. Some of those shares were probably intended. The point is that nobody could say which.
The fix: treat company-wide installations as a change that needs a second pair of eyes, and review them on a schedule. The audit shows how many people each app can act for, so the company-wide ones are at the top of the list without looking for them.
Pattern five: "read-only" is not small
Read-only access sounds safe, and it is safer than write access. But an app that can read every email in an inbox can read the password resets, the invoices, the offer letters and the legal threads. For an AI tool specifically, read access is the whole product: it is what the tool sends back to its own servers to summarize, search or answer questions about.
The audit shows read access for what it is. A tool with read-only mail access for the finance team is a finding worth a conversation, even if the tool is well known and the vendor is reputable.
The fix: decide which teams' mail and files are sensitive enough that AI read access needs approval, and check the audit for apps that already have it. Then write that down as a policy, so the next person who connects a tool to the finance inbox gets flagged the same day.
Why this keeps happening
None of these patterns come from carelessness. They come from the shape of the problem. Permissions are granted one person at a time, in private, with no notification to anyone else. They persist by default. And the only built-in place to review them is a per-user screen in Google Admin that nobody visits unless something has already gone wrong.
The result is that most companies have a growing pile of live keys into their own data, held by tools they half remember trying, on behalf of people who may or may not still work there. The pile does not shrink on its own.
The ten-minute version
- Get a list of every AI app connected to your Workspace and how many people each one covers.
- Revoke anything granted by someone who has left.
- Revoke anything with no activity in 30 days.
- For anything company-wide or with send or write access, write down why it is there.
- Add "revoke their apps" to the offboarding checklist.
- Put a date in the calendar to do it again next quarter, or connect something that does it continuously.
Steps one through three are what the permission audit does the moment you connect. Step six is what the Control plan is for.
The findings in this guide are illustrative composites drawn from what the audit surfaces. App names are real products; the companies and people are not identifiable. Your own findings are built from your Workspace's own records, with the original entry behind every line.