How do you remove third-party access from a Google account (and your company’s)?

By Andrej Ruckij · October 29, 2026 · updated November 4, 2026

TL;DR: For your own Google account, open myaccount.google.com/linkedapps, go to the “Access to your Google Account” section (the “Access to” filter narrows it), open each app, select See details, then Remove access. For a company on Google Workspace, an admin goes to Security > Access and data control > API controls > Manage Third-Party App Access, downloads the “Accessed apps” list and blocks what nobody needs. Microsoft 365 keeps the same list in the Entra admin center under Enterprise apps. Removing apps is half the job; the other half is stopping new ones, which Workspace, Entra, Slack and GitHub all let an admin do. Be clear about what this buys you. The 2025 Salesloft Drift breach ran through an app its victims used on purpose, so an inventory wouldn’t have flagged it. What an inventory gives you is a list you can act on the same day a vendor announces a breach, and fewer forgotten apps holding wide access. I can’t fix my vendors’ bugs. Knowing which apps hold access, and cutting the ones nobody uses, is the part I can do.

What happened at Anthropic, and what the 12 hours means

On October 26 the Washington Post reported, from a draft report by the security startup Cathedral, that Cathedral’s AI agents found routes into “a limited set” of Anthropic’s sales, HR and IT systems in less than 12 hours. Decrypt, Gizmodo and Futurism all summarised it. Cathedral was testing Anthropic through a bug-bounty-style program. The route wasn’t Claude. It ran through third-party administrative and sales software that many other companies use. The vendors haven’t been named, and as of November 4 I found no follow-up naming them.

Re-checked against the sources, two things need saying:

The 12 hours is Cathedral’s figure, and it isn’t the whole clock. Anthropic’s account, as Gizmodo and Futurism report it, is that the researchers first spent several days failing to break into Anthropic’s own software directly, then switched to the third-party software. So the fast part was the route through the vendors, after days on the front door.
The two sides disagree on what was reached. Anthropic says business contact details and basic user account records in a limited set of systems, and no Claude users’ conversations, source code or model weights. Cathedral’s draft describes routes to meeting transcripts, salary and job-offer details, and Slack messages.

Anthropic told the Post: “Our monitoring flagged some of Cathedral’s activity before they reported it to us, and we shut off their access the same day.” It also said: “We also have no evidence that anyone exploited these vulnerabilities outside of Cathedral.” It disabled the affected software until the vendors confirmed fixes. Per Decrypt, Anthropic says Cathedral overstated the national security implications; per Decrypt and Gizmodo, it says Cathedral didn’t disclose all of its activity.

Breaches that did go through connected apps

The Anthropic case is a test, with unnamed vendors and an unknown mechanism. The cases below are real breaches, and in each a connected app or its OAuth tokens carried the attacker into the victim’s data.

Case	How it worked	What it shows
Salesloft Drift, August 2025	Attackers got into Salesloft’s GitHub account in March 2025, reached Drift’s AWS environment and stole the OAuth tokens Drift customers had granted. From August 8 to at least August 18 they used them to export Salesforce data and hunt for stored secrets such as AWS keys and Snowflake tokens. TechCrunch names victims including Cloudflare, Google, Palo Alto Networks, Proofpoint and Tenable.	The app was approved and in use. Google’s guidance afterwards: “treat any and all authentication tokens stored in or connected to the Drift platform as potentially compromised.”
Drift Email into Google Workspace, August 9, 2025	The same actor used Drift Email tokens to read mail in “a very small number” of Workspace accounts. Google says “The only accounts that were potentially accessed were those that had been specifically configured to integrate with Salesloft Drift”.	The damage stopped exactly at the accounts that had connected the app.
Gainsight, November 2025	Salesforce found “unusual activity involving Gainsight-published applications” and “revoked all active access and refresh tokens associated with Gainsight-published applications.” Gainsight had earlier said it was breached through stolen OAuth tokens linked to Salesloft Drift. ShinyHunters claimed 285 more Salesforce instances, which is the group’s claim, not a confirmed count.	One vendor’s stolen tokens led to a second vendor’s tokens.
UNC6040 voice phishing, 2025	Callers posing as IT support talked employees into entering a “connection code” on Salesforce’s connected app setup page, linking an attacker’s modified Data Loader, sometimes renamed “My Ticket Portal”. Google’s own Salesforce instance for small-business contacts was one victim.	Staff could connect apps by themselves. That’s the setting the “stop new grants” steps below change.
Midnight Blizzard at Microsoft, 2024	Password spraying got the attackers into a legacy, non-production test tenant account without multifactor authentication, where they took over “a legacy test OAuth application that had elevated access to the Microsoft corporate environment” and used it to reach corporate email.	A forgotten app with wide access is exactly what an inventory finds.

Microsoft states the uncomfortable part plainly for apps that trick users into consenting: “Normal remediation steps (for example, resetting passwords or requiring multifactor authentication (MFA)) aren’t effective against this type of attack, because these apps are external to the organization.” Revoking the grant is the fix.

What an app audit doesn’t fix

I’d rather say this before the steps than after.

It wouldn’t have stopped Drift. Drift’s victims connected it on purpose and used it. An audit marks that kind of app as needed. What helps there is narrow permissions, and a list good enough to revoke within hours of the vendor’s notice.
Stolen passwords are still a leading way in. Verizon’s 2025 Data Breach Investigations Report puts credential abuse at 22% of breaches, one of the two leading initial vectors alongside vulnerability exploitation at 20%, and says third-party involvement has doubled, to 30%. The 2024 Snowflake thefts went through no app at all: Mandiant says “every incident Mandiant responded to associated with this campaign was traced back to compromised customer credentials”, on accounts without MFA, some with passwords stolen as far back as 2020. If your team doesn’t have MFA everywhere, fix that first.
Revoking doesn’t pull back data. Google’s help page says removing Sign in with Google “doesn’t delete your data on the app”, and says nothing about apps deleting data they already copied. That’s in each vendor’s privacy policy.
Blocking everything has a cost. On its illicit-consent page, Microsoft says of turning off integrated applications in Microsoft 365: “We don’t recommend this action because it severely impairs user productivity with non-Microsoft applications.” Block too hard and people use personal accounts instead, which you see even less.

My read is still that the audit is worth an hour. Breaches like Drift and Gainsight get announced, and on that day a company with a dated list can check in minutes whether it’s affected. Without one, someone has to rebuild the list from memory and inboxes.

Who this is for

For: owners and the person who doubles as IT in a small company on Google Workspace or Microsoft 365; Slack, GitHub and HubSpot admins; anyone using a personal Gmail for work. Not for: employees without admin rights beyond the first section, which you can do on your own account. Send the rest to your admin. Also not a substitute for a vendor security review if you handle regulated data.

How to do it

How do I remove third-party access from my Google account?

Personal Gmail, or a Workspace account you use yourself. About 10 minutes.

Open myaccount.google.com/linkedapps.
Go to the Access to your Google Account section. To narrow it, use the Access to filter with Google product or Other account access.
Select an app, then See details.
If you don’t use it or don’t recognise it, select Remove access, then Confirm.
Check the Sign in with Google filter too. There, Stop using Sign in with Google stops automatic sign-in; it doesn’t delete your account on that app.
Check the Agent access filter, where Gemini and other Google AI agents that act inside apps appear. Select the app, then Stop using [app name] under Agents. Google notes this “does not disconnect or delete your Google Account’s link with that app.”

How to check it worked: reopen the page; the app should be gone from that filter. If an app looks like it’s misusing access, Report this app sits at the bottom of its details page.

How to check third-party apps in Google Workspace (admin)

Needs an admin with the Service Settings privilege. About 30 minutes the first time.

Sign in to admin.google.com, go to Menu > Security > Access and data control > API controls.
Click Manage Third-Party App Access. Configured apps (already set to Trusted, Limited or Blocked) shows first.
Open Accessed apps, click View list. These are apps your users connected, with the number of users and the Google services each requests.
Click Download list. Google says “All data in the table is downloaded (including data you don’t have displayed).” Save that CSV with a date in the file name; it’s your inventory.
Open an app’s OAuth scopes (the scopes table below says which ones matter).
For anything you don’t need: point to it, click Change access, choose Blocked (no Google services) or Limited (unrestricted services only), then Change.

How to check it worked: the app shows under Configured apps with the new setting. Google says the Accessed apps list “is updated 48 hours after a token is granted or revoked”, so it can look unchanged for two days.

How to stop staff in Google Workspace connecting new apps

This is the step that would have mattered for the UNC6040-style calls, adapted to Google: an employee can’t hand over access the admin hasn’t allowed.

Same place: API controls, then Settings, then Unconfigured third-party apps.
Choose Allow users to access third-party apps that only ask for Google sign-in info (sign-in works, data access needs your approval) or the strict Don’t allow users to access any third-party apps.
Before you switch, mark the apps you rely on as Trusted from the downloaded list, or users will be blocked from them.
Optional and stronger: Manage Google Services, tick Gmail or Drive, Change access > Restricted. Google warns that “any previously installed apps that you haven’t trusted stop working and tokens are revoked.” Gmail and Drive can also be restricted to just their high-risk scopes.

Google says app details “typically appear 24–48 hours after authorization”, and the accessed apps list “is updated 48 hours after a token is granted or revoked”.

How do I review app permissions in Microsoft 365?

Needs Cloud Application Administrator or Application Administrator. About 20 minutes.

Sign in to entra.microsoft.com.
Go to Entra ID > Enterprise apps > All applications.
Select an app, then Permissions.
The Admin consent tab shows organisation-wide access; User consent shows grants by individual people.
To cut an organisation-wide permission: in Admin consent, click … next to it, then Revoke permission.

Three catches from Microsoft’s docs. User-consent grants can’t be revoked in the portal; that takes PowerShell or Graph. Microsoft’s per-user route is Users > All users > the person > Applications, open the app, Remove. And “Revoking the current granted permission doesn’t stop users from re-consenting to the application’s requested permissions.”

Two more checks Microsoft documents. Each user can see their own app access at myapps.microsoft.com. And in the Defender portal’s Audit search, sort by activity and look for Consent to application entries where IsAdminConsent is True; Microsoft says that value means someone with Global Administrator access “might have granted broad access to data.” Audit entries take 30 minutes to 24 hours to appear.

How to stop staff in Microsoft 365 consenting to new apps

Needs a Global Administrator in the portal (Privileged Role Administrator through PowerShell).

In the Entra admin center, go to Enterprise apps > Consent and permissions > User consent settings (Microsoft’s consent doc writes it as Identity > Applications > Enterprise apps; newer menus label the top level Entra ID).
Under User consent for applications, choose Allow user consent for apps from verified publishers, for selected permissions (Microsoft’s recommendation) or turn user consent off.
Turn on the admin consent workflow, so blocked users can request an app instead of working around you.

Microsoft notes the change only affects future consents: “Existing consent grants remain unchanged.” The revocation steps above handle those.

Slack: approve apps before they get in

Workspace Owners. Five minutes.

On desktop, click Admin in the sidebar, then Apps and workflows, then App Management Settings.
Click Edit next to Require approved apps, check Only allow pre-approved apps, save.
Lighter option, all plans: Edit next to Only allow apps from the Slack Marketplace. Members can still build and install internal apps under this one.
To pre-approve or block a specific app: Admin > Apps and workflows > Browse, find the app, Approve or Restrict.

Catch: “If an app you restrict has already been installed to your workspace, members can continue using it.” Restricting isn’t removing; uninstall the ones you don’t want.

GitHub: organisation and personal

Organisation (owners): profile picture > Organizations > your org > Settings > Third-party Access > OAuth app policy > Setup application access restrictions > Restrict third-party application access. GitHub says it’s on by default for new organisations. If you turn it on for an older org, GitHub revokes organisation access for all previously authorised OAuth apps and SSH keys, so members need new SSH keys and the apps need re-approving. Do it on a quiet day.

Personal: Settings > Integrations > Applications > Authorized GitHub Apps, then Revoke on anything you don’t recognise. Only the person who authorised an app can revoke it; an org owner can uninstall it from the organisation instead.

HubSpot

Settings icon > Integrations > Connected Apps. Open an app under My apps and read App access and permissions. On the Notifications tab, Create new notification for App Install. That’s the cheapest early warning in this article.

Salesforce

I couldn’t open Salesforce’s current help page for its connected-app usage screen, so I won’t give a click path from memory. What I can give is Google’s hardening list from the Drift investigation: “Ensure that applications have the minimum necessary permissions and avoid overly permissive scopes like full access”, set connected apps to enforce IP restrictions, and take the “API Enabled” permission off profiles so only named users can export data. After UNC6040, Google also advised restricting “Manage Connected Apps” to trusted administrators.

How to tell a risky app from a needed one

The app’s name tells you little; UNC6040 named theirs “My Ticket Portal”. Look at what it can do.

Google scopes (from Google’s own scope tables; “restricted” is Google’s top tier, with its strictest verification for developers):

Scope	Google’s description	Tier
`https://mail.google.com/`	”Read, compose, send, and permanently delete all your email from Gmail.”	Restricted
`gmail.readonly`	”View your email messages and settings.”	Restricted
`gmail.modify`	”Read, compose, and send emails from your Gmail account.”	Restricted
`gmail.metadata`	Labels and headers, “but not the email body”	Restricted
`gmail.send`	”Send email on your behalf.”	Sensitive
`drive`	”View and manage all your Drive files.”	Restricted
`drive.readonly`	”View and download all your Drive files.”	Restricted
`drive.file`	Only files you open with or share to the app	Non-sensitive

Note the metadata one: headers alone show who you email and when, and Google still classes that scope as restricted.

Microsoft 365, from Microsoft’s own investigation guide: a consent type of AllPrincipals means the app reaches “everyone’s content in the tenancy”; every non-Microsoft app with it deserves a close look. Also look for “Read”, “Write” or “All” in the permission names, and for misspelled or very bland app names.

My rule of thumb, an opinion rather than a vendor rule:

Keep an app that matches its job: a calendar scheduler with calendar access, a signature tool with settings access.
Question a mismatch: a signature tool with full Gmail, a meeting note-taker with all of Drive, anything with mail delete rights.
Remove anything nobody can name an owner for, anything from someone who has left, and anything from a trial that ended.

What breaks when you revoke

Where	What happens	Watch for
Google account, Remove access	The app “can’t access your Google Account”; some features may stop working	Sync tools and schedulers fail quietly; re-connecting gives it access again
Google, stop Sign in with Google	Automatic sign-in stops; your account on the app remains	My caution: if Google sign-in is your only way into that app, set up another login first
Workspace, Block an app	The app loses access to Google services for your users	Check the user count in the CSV before blocking anything used by many
Workspace, Restricted service	Untrusted apps using it “stop working and tokens are revoked”	Mark needed apps Trusted first
Entra, Revoke permission	That organisation-wide permission goes	Users can consent again unless you change consent settings
Slack, Restrict	Nothing changes for installed copies	Uninstall separately
GitHub, enable org restrictions	Org access revoked for all OAuth apps and SSH keys	CI and deploy keys break until re-approved

Tools that automate the audit

Option	What it does	Price as listed	Who it suits
Built-in Google Workspace and Entra screens	Everything in the steps above	Included in your plan	Under ~50 people; a quarterly manual check
Microsoft’s Get-AzureADPSPermissions script	Dumps every OAuth consent grant in the tenant to one CSV	Free (linked from Microsoft’s docs)	Microsoft 365 admins comfortable with PowerShell
Microsoft Defender for Cloud Apps, app governance	Policies and alerts on OAuth app behaviour; needs a Defender for Cloud Apps licence, standalone or bundled	$3.50 a month per licence (Commercial MSRP, billed annually), from a reseller listing on Secureframe; not available in some regions (Microsoft lists Singapore, Poland, Italy, Qatar, Israel, Spain, Mexico and Taiwan)	Microsoft shops that want alerts, not just a list
Nudge Security	SaaS discovery plus “OAuth & integration risk management” for Google Workspace and Microsoft 365, included in every tier; auto-revoking overly permissive grants sits under “Integration security posture management”, which the page marks ”($)”, so my read is it costs extra	$750 a month up to 150 users; $5 per user per month for 150-1,500; billed annually; free trial	Companies with many tools and no IT person; the minimum is steep under ~50 people

I found no independent comparison of these tools’ detection quality.

How often to re-check

Microsoft’s guidance for larger tenants: “the best practice is to review consent grants in organizations on a weekly basis.” For a small company I’d do a full check every three months, plus three triggers outside the schedule:

a vendor you use announces a security incident: search the latest CSV for it the same day;
someone leaves: remove the apps only they used;
the team starts trialling an AI tool that asks for mail or Drive access: decide on purpose, and note who owns it.

When nobody can say who owns an app, I’d block it and wait to see who asks.

What I’d do this week

Download the Google Workspace CSV or run Microsoft’s consent export, sort by scope, and look only at the apps with full mail, all-Drive or organisation-wide access. Block the ones nobody claims within a day. Then switch new app connections to approval, starting with Google’s sign-in-only option or Microsoft’s verified-publishers setting, and put a reminder in the calendar for February.

Related: the agent-side version of the same problem, controls on what your own agents can touch, is in glossary/guardrails; what agents are and what they can do is in glossary/ai-agent. If you build automations on OpenAI, the rules on human review are here: https://primores.org/blog/openai-usage-policy-update/

Sources

More of this every day on the channel: https://t.me/aidaily_business