The Permission You Forgot You Granted: A 30-Minute Audit of Every App Connected to Your Accounts
The Permission You Forgot You Granted
Changing your password does not log out the apps you connected to your account. Neither does turning on two-factor authentication. An OAuth grant — the thing that happens when you click "Continue with Google" or "Allow" on a permissions screen — issues a token that keeps working on its own schedule, independent of your password and usually independent of your second factor. Most people have granted dozens of them. Almost nobody has read the list back.
This is a single-topic tutorial: find every third-party app holding access to your Google, Microsoft and Apple accounts, work out what each one can actually reach, and cut the ones that no longer earn their place. It takes about thirty minutes the first time and five minutes a year after that.
On April 19, 2026, Vercel published a security bulletin confirming unauthorized access to internal systems. The chain it describes is worth reading slowly, because it did not begin with a password.
By Vercel's own account, the incident originated with the compromise of Context.ai, a third-party AI tool used by one Vercel employee. The attacker used that access to take over the employee's individual Google Workspace account, which in turn opened the door to that employee's Vercel account. From there they pivoted into a Vercel environment and enumerated and decrypted non-sensitive environment variables. Vercel assessed the attacker as highly sophisticated, engaged Google Mandiant and notified law enforcement.
The detail that matters for this tutorial is in Vercel's indicators-of-compromise section. The company published a single Google OAuth client ID — 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com — and recommended that Google Workspace administrators and Google Account owners check for usage of that app immediately. Vercel noted the compromised tool's OAuth app potentially affected hundreds of users across many organizations. In other words: the remediation Vercel asked the wider world to perform was exactly the audit below.
- A desktop browser signed in to the accounts you want to audit. The web consoles show more detail than the mobile apps.
- Your phone nearby for re-authentication prompts. Expect to be challenged more than once.
- For Apple: an iPhone, iPad or Mac, or a browser at account.apple.com. Apple's list is viewable on the web but the removal flow is documented on-device.
- For a work Microsoft 365 account: nothing extra, but note in advance that you will not be able to revoke everything (see step 06).
- Thirty minutes. Do not start this five minutes before a meeting — you will break something and want time to fix it.
One thing to settle before you begin: this audit covers account permissions, not device permissions. Camera and microphone access on your phone is a separate list. Browser extensions are a third. We covered the extension side separately, and the two audits complement each other rather than overlapping.
| Account | Where the list lives | What you can revoke | What revoking will not undo |
|---|---|---|---|
| myaccount.google.com → Security → linked apps | Every linked app and Sign in with Google grant | Data the app already copied out | |
| Microsoft (personal) | account.microsoft.com → Privacy → app access | Permissions you personally granted | Data the app already exported |
| Microsoft (work/school) | myapplications.microsoft.com | Only what you consented to yourself | Anything your admin consented to for you |
| Apple | Settings → your name → Sign in with Apple | Sign in with Apple links, per developer | Accounts you made with an email and password |
- Go to myaccount.google.com, open Security, and find the section for apps from other developers with access to your account. Google links this list directly as myaccount.google.com/linkedapps.
- Read the whole list before removing anything. Expect it to be longer than you remember — every "Sign in with Google" you have ever used lands here.
- Open each entry and look at the access type. Google documents three levels: basic profile only; view and copy data; and manage data, which lets an app edit, create and delete inside your account. Anything with manage rights that you do not actively use is your first cut.
- Check against reality. An invoice tool with Drive access you stopped using in 2023 is not dormant — it is a live key.
- Remove the connection. Google is explicit that once you revoke a linked app's access it can no longer reach your data — but that you may need to contact the developer separately to ask them to delete what they already hold.
Worth knowing for future grants: Google now offers time-boxed sharing in some flows. Instead of open-ended access, you can share a static one-time copy of data, or grant access for 30 or 180 days, with a notification before it lapses. When a service offers that option, take it.
Personal account. Open account.microsoft.com, go to Privacy, and open the section listing apps and services that can access your data. Select an app, review the granted permissions, and remove them. As with Google, removal stops future access but does not reach back into data the app already stored.
Work or school account. This lives at myapplications.microsoft.com. Hover an app, click the … menu, and choose Manage your application. Microsoft splits the permissions window in two: the top shows what you personally consented to, and you can clear those with Revoke Permissions. The bottom shows what your administrator consented to on your behalf — and Microsoft states plainly that you cannot revoke those, because they are often required by organisational policy.
Microsoft's own warning on that page is the honest one: removing a permission may break some of the app's functionality, and if you hit problems afterwards you should contact your admin. That is not a reason to skip the audit. It is a reason to do it on a Thursday afternoon rather than a Monday morning.
- On iPhone or iPad: open Settings, tap your name, then tap Sign in with Apple. On a Mac: Apple menu → System Settings → your name → Sign in with Apple. On the web: sign in at account.apple.com, go to Sign-In & Security, then Sign in with Apple.
- Select any app in the list to see what you originally shared with it — typically your name and either your real or a relay email address.
- To cut the link, select the app or developer and tap Delete, then confirm.
- Separately, if you used Hide My Email, forwarding is managed under Settings → iCloud → Hide My Email, where you can switch off forwarding per developer or change the destination address for all of them.
Two behaviours to expect, both documented by Apple. Stopping Sign in with Apple signs you out of that app on your device — you can sign back in later with the same Apple Account and land in the same app account. And if a developer uses one Sign in with Apple identity across several of its apps, stopping for one app applies to all of that developer's apps.
Calendar or contact sync stops. This is the most common casualty, and it is expected behaviour: the sync tool was using the grant you just removed. Re-authorising the app restores the sync. If you meant to remove it, check whether anything else — a booking page, a scheduling assistant — was quietly relying on that same connection.
An app logs you out and you cannot get back in. Common with services where "Sign in with Google" or "Sign in with Apple" was the only way you ever signed in. Before revoking, set a password inside the service itself, or confirm the service offers email-based recovery. Apple notes that some apps let you create a password for your existing account so you can sign in without the Apple Account.
A work app breaks and there is no revoke button. That is the admin-consented section of the My Apps portal. You cannot fix it yourself; contact your IT admin.
You revoke and the data is still out there. This one has no technical fix. Revocation cuts future access only. Google's guidance is to contact the developer directly and request deletion of what they already copied — and, if you believe a linked app is misusing your data, Google provides a reporting path for it.
Verification is deliberately simple. Sign out, sign back in, and reload each console. The apps you removed should be gone from the list, not merely greyed out. Then open the app itself: if it still loads your data, the grant survived — which usually means you removed a different, similarly named entry. Finally, check the security-activity or recent-sign-in log on each account for anything you do not recognise, and take a screenshot of the final lists so next year's pass has a baseline.
Who should skip this, or wait. If you administer a Google Workspace or Microsoft 365 tenant, do not start with your own account — organisation-wide app governance is a different job with different tools, and clearing your personal grants first can mask what you need to see. If you are mid-migration between devices or password managers, finish that first; revoking a sign-in path while your credentials are in flight is how people lock themselves out. And if a connected app is load-bearing for your work — the one that syncs your billing, your calendar, your CRM — leave it and audit it deliberately later, with a colleague who can restore it.
Everyone else: the list is almost certainly longer than you think, and the shortest version of this article is that you should go and read it.
The advice industry has spent five years telling ordinary users that multi-factor authentication is the finish line. The OAuth grant is the quiet exception to that story, and the platforms have not been loud about it — because the frictionless "Continue with Google" button is a product feature, and every prompt that makes people hesitate over it costs somebody a signup. The result is an asymmetry nobody designed on purpose: granting access takes one tap and lives in the flow of getting something done, while reviewing it takes thirty minutes and lives four menus deep in a settings page most people visit once a year. What the coverage of the 2026 OAuth incidents mostly misses is that this is not a user-education problem. Users behaved exactly as the interface asked them to. The gap is that consent is designed as a one-time event when it functions as a standing one — a key handed over, not a door held open. The genuinely useful fix is the one Google has started shipping quietly: time-boxed grants that expire on their own, with a notice before they lapse. Default expiry would do more for ordinary account security than another year of telling people to check a list they will not check.
What we still don't know: How many grants the median consumer account actually holds — no platform publishes that number — and whether time-limited consent will spread beyond the handful of Google flows that currently offer it, or stay a niche option that most developers never implement.
Audit the Extensions, Fence the Smart Devices, Run the AI Offline — the browser-extension half of the same problem.
The Backup You Think You Have — because losing access to an account is the failure mode this audit occasionally causes.
Sources
- Vercel Security Team — Vercel April 2026 security incident (primary)
- Google Account Help — Share some access to your Google Account data with apps from other developers (primary)
- Apple Support — Manage your apps with Sign in with Apple (primary)
- Microsoft Support — Edit or revoke application permissions in the My Apps portal (primary)
- Trend Micro Research — The Vercel Breach: OAuth Supply Chain Attack Exposes the Hidden Risk in Platform Environment Variables
- VentureBeat — Vercel breach exposes the OAuth gap most security teams cannot detect, scope or contain
Console locations and procedures verified September 17, 2026 and subject to change as platform interfaces are updated. GadgetGlow Bytes does not test hardware or receive products from manufacturers for coverage.
Comments
Post a Comment