Auditing Every Permission Your AI Agent Actually Uses

Most AI agents get more access than they need. Heres how We check every permission and cut whats not used.

A few months back, I opened the OAuth screen for an AI agent I built. It asked for full access to Gmail. Full access to Drive. Full access to Calendar. Read, write, send, delete, share. All of it.

Then I checked the code. The agent read subject lines. It made calendar events. It wrote to one sheet. That was all it did.

This is the real problem. Most AI agents ask for way more access than they use. Auditing every permission your AI agent actually uses is the fix. It's not hard. It's just skipped.

Why This Problem Sneaks Up on You

Wiring an agent up to Gmail, Sheets, Drive, or Calendar is quick. You copy the broadest scope from a tutorial. It works on the first try. You move on. I've done this myself.

But "it works" is not the same as "it's scoped right." An agent with full Gmail access can read, send, and delete every email in the account. Even if your prompt only asks it to summarize unread messages.

Here's the real risk. If that agent gets hacked, breaks, or makes a bad call, the damage covers the whole mailbox. Not just the three things you built it to do. That's the whole point of least privilege: the harm a system can cause is capped by what it can access, not by what it plans to do.

What Scope Minimization Actually Means

OAuth scope minimization sounds fancy. It's simple. Every API call your agent makes should use the smallest scope that still works.

Not the scope that's easiest to grab. Not the one from an old tutorial. The narrowest one Google's own docs allow for that exact task.

I break the process into three steps:

1. List every call your agent makes to Gmail, Sheets, Drive, or Calendar.
2. Match each call to the smallest scope that covers it, using Google's own scope list.
3. Ask for consent again with the smaller scope set. Then check nothing breaks.

Step three trips people up. It means a new consent screen for users or admins. In my experience, it's worth the friction. A smaller consent screen also builds more trust. Users worry a lot less about "send email" than they do about "delete all your email."

The Audit Real Functions Mapped to Real Scopes

I want to show you the real before-and-after here, not just talk about it. "Use least privilege" is advice everyone already agrees with. Almost nobody acts on it. The details are where this gets useful.

These tables use Google's current scope docs for each API. Not a made-up example — just what the docs say is open today, checked against what a typical agent build actually calls.

Gmail Scopes Before vs. After

Notice something: gmail.modify is already better than full mailbox access. But it's still too broad for agents that only read, or only send. Google marks gmail.readonly and gmail.metadata as restricted scopes. That means stricter checks if you ever launch this publicly — one more reason to only ask for what you'll use.

Sheets Scopes Before vs. After

This one surprised me. Google's own docs suggest drive.file over the spreadsheets scope for most agents. Why? drive.file only grants access to files a user opened or made with your app, not every sheet in their account. It's also marked non-sensitive, which means an easier review if you ever ship this to other users.

Drive Scopes Before vs. After

drive and drive.readonly are both restricted scopes. That's Google's strictest review tier. If your agent's real job is reading files a user shares with it, drive.file gets you there — without ever touching the rest of their Drive.

Calendar Scopes Before vs. After

Full calendar access lets an agent delete calendars. It can change sharing rules too. Most scheduling agents never need that. calendar.events covers create-and-edit for most booking bots, without handing over control of calendar settings.

How to Run This Audit Yourself

Here's the exact sequence I follow, not a theory checklist:

1. Search your code for every API call. Every .execute(). Every fetch to a Google endpoint. If you can't find them all in fifteen minutes, that's a warning sign on its own.
2. Write down what each call does in plain words — read, list, create, update, delete, send.
3. Look up the scope for that exact task. Use Google's current scope docs, not a three-year-old blog post. Scopes change over time.
4. Compare that to what you're asking for now. Anything broader is a candidate to cut.
5. Test the smaller scope in staging first. Some SDK calls need more access than you'd expect. Check, don't guess.
6. Run this audit on every release, not just once. Scope creep happens slowly — someone adds "one more feature" and grabs the broad scope because it's already there.

What Over-Scoping Actually Costs You

This can feel like a checkbox task. It's not. The real cost shows up during an incident. If a token leaks, or gets logged somewhere it shouldn't, the question isn't "were we hacked." It's "what could they touch with what we gave them."

A read-only Gmail token in the wrong hands exposes an inbox. A full-access token exposes the inbox — and it also lets someone send from it, delete proof, and hide their tracks. Same breach. Very different outcome. That outcome got picked months earlier, when someone chose a scope out of convenience.

There's a quieter cost too. Every plugin or tool your agent connects to inherits whatever scope you already granted. Cutting scope at the source limits what every downstream tool can do too. You can't leak a permission you never asked for.

Common Mistakes I See Often

• Asking for scopes "just in case." Add scope when you build the feature, not before.
• Never checking again after launch. Teams review scopes once, then never again, even as the agent grows.
• Assuming broad scopes are easier to keep up. Narrow scopes fail fast and loud in testing. Broad scopes fail quiet, months later, in an incident report.
• Treating drive.file as a downgrade. For most agents, it's not a compromise. It's the right default.

FAQ

What is least privilege in API design? It means giving a system only the access it needs, nothing more. For OAuth, that means picking the smallest scope Google allows for each task, not a broad, do-everything scope.

Is drive.file enough for Sheets or Docs agents? Yes, for most agents. If your agent only touches files a user opened or shared through a picker, drive.file covers it. Google suggests it over broader scopes for this exact reason.

Do restricted scopes need extra review from Google? Yes. Scopes like drive, drive.readonly, gmail.readonly, and full calendar sit in sensitive or restricted tiers. Google checks these before you can use them in a public app. Cutting scope isn't just safer — it often gets you to launch faster too.

How often should I audit scope? At least every time you add a new function that touches an outside API. Also check on a set schedule, like every release. Scope creep is slow. A one-time audit at launch won't catch what gets added six months later.

Where This Leaves You

Scope minimization isn't a one-time cleanup. It's a habit. It has to survive every new feature you add later. The tables above are a start, not the finish line. Your agent's real function list is the true source of truth — check it against Google's current scope docs on a set schedule, not once and forget it.

The agents worth trusting with someone's inbox, sheets, or calendar are the ones whose access you could explain in one sentence, out loud, without flinching.

Want more notes like this? Subscribe for weekly tips on AI automation and security — practical and tested, not theory.

Sources referenced for scope classifications: Google OAuth 2.0 Scopes for Google APIs, Gmail API Auth Scopes, Drive API Auth Scopes, Sheets API Auth Scopes