Before You Grant an AI Agent Access: A Practical OAuth Scope Audit

A developer's practical guide to auditing OAuth scopes before granting AI agents access highlights the risks of broad permissions, such as email send-as-you and payment authority. The piece emphasizes the difference between app and agent access, the importance of revocation and activity logs, and the phishing threat posed by agents holding personal data.

Meta released Muse , a personal AI agent that asks for access to your email, calendars, payments and health data in order to do things for you — selling a car, booking travel. It competes with agents like OpenClaw and Instinct, and it pairs broad data requests with promises of privacy controls. Whether Muse succeeds depends on whether people decide to trust Meta with that scope. That's a fair question but not the one I care about here. The useful question applies to every agent in this category, including the ones you'll be offered next month: What exactly are you granting, and what keeps working after you stop watching? This is the distinction most people miss, and it's the whole risk model. An app asks for permission and runs when you open it. Access is bounded by your attention. If it does something unexpected, you're usually looking at the screen. An agent differs in two ways: Combine those and a compromise changes category. A leaked copy of your calendar is bad. An agent that can read your calendar, write your email and move money is closer to someone holding your phone, unlocked, for as long as the token lives. "Access your email" can mean reading it to summarise your day, or sending mail as you . These are not the same permission and they are not the same risk. If the grant screen doesn't distinguish them, assume the broader one. From an OAuth standpoint this is just scope granularity: mail.read versus mail.send . Read is already significant. Send-as-you is the one that turns a mistake into an incident. Full-mailbox access and access to one label are both "email access." Same for calendars: every calendar versus one you create specifically for the agent. If the tool supports scoping, use it. If it doesn't, that tells you how the vendor thinks about your data. People collapse these, but they're separate: The second matters more than expected, because "we don't train on your data" and "we don't train on your data by default, but you can opt in" are very different sentences that look nearly identical on a settings page. Two separate things: These are frequently different processes, and the second is usually buried. An agent you can't cleanly revoke is a commitment, not a feature. Check the connected-apps panel of the granting account and see whether revocation also invalidates the issued tokens — sometimes it doesn't. An agent that can negotiate or transact is acting toward other people in your name . That's a much larger grant than one that only organises information you already have. If payment authority is involved, look for per-action confirmation and a spend ceiling rather than blanket authorisation. You should be able to see what the agent did, when, and on whose instruction. Without a log you can't detect a wrong action and can't reconstruct one after the fact. No activity history means every action is unverifiable. An agent holding your email and calendar isn't only a privacy question. It's the best phishing pretext ever assembled. Everything a convincing lure needs — who you talk to, what you're working on, when you're away, what you bought — is exactly what these agents are being given. If that store is reachable, the messages produced will be better than anything in circulation today. Attackers are already moving from stealing passwords to borrowing legitimate access. A related operation I wrote about, BigBear, took 474 Microsoft 365 sessions with MFA fully satisfied using a relay proxy. An agent account is the most concentrated form of legitimate access most people will ever hold. An employee granting an agent access to a work mailbox is effectively granting a third party access to company data. Not always wrong — frequently useful — but it should be a decision with an owner, not something that happens during a product tour. The minimum: I'm not going to tell you not to use these tools. Some will save real time, and refusing them on principle isn't a strategy. But the permission screen is the wrong place to start thinking. By the time it appears, the decision is framed as "allow access to continue," and the interesting questions — what persists, what it can do without you, what happens on revocation — have already been settled somewhere else, usually in a settings page nobody opens. Read those first. The agent can wait thirty seconds. Originally published at CyberPicks https://cyberpicks.org/guides/ai-agent-permission-checklist .