AI agent calendar and inbox access: what it can do alone

Most people worry about the wrong half of this. When you give an AI agent calendar and inbox access, your email is the part everyone guards and your calendar is the part nobody thinks about, and it turns out that's exactly backwards. I went looking for the precise line where an agent stops asking you first, and I found it in a single default value in a connector's source code: delete one meeting, and it emails a cancellation to every guest. If you're about to click Allow on a Google consent screen, this is the part of that screen nobody reads.

One thing up front, because it matters for how you read the rest. I did not run a week with a real inbox and a real calendar and then write up the drama. What I did instead is the boring version that actually holds up: I read Google's own scope definitions, pulled the source code of a popular connector, and checked what each mainstream agent is documented or publicly reported to be allowed to do. Everything I checked is linked below, down to the file and line number. No war stories.

What does an AI agent actually get when you grant calendar and inbox access?

It gets whatever the OAuth scope says, and the scope is always broader than the button that requested it. OAuth scope is just the technical name for the permission slip your Google account hands to an app, and Google publishes the exact wording for every one of them.

A common Gmail scope, gmail.modify, is described by Google as "Read, compose, and send emails from your Gmail account." Send. It's in there, in Google's own words, on a permission people approve while thinking they're granting a smart inbox reader.

Now the calendar side. The scope called https://www.googleapis.com/auth/calendar is described as "See, edit, share, and permanently delete all the calendars you can access using Google Calendar." Not the events it made. All of them. Permanently.

The Gmail equivalent refuses that power out loud: gmail.modify "does not allow immediate, permanent deletion of threads and messages, bypassing the trash." The calendar scope has no such sentence.

Why is your inbox guarded and your calendar wide open?

Because the companies building these connectors made a deliberate product choice about email and skipped the same conversation about calendars. Here is what three mainstream setups are documented, or publicly reported, to allow as of July 2026.

Read that middle column and then the right one. The inbox gets a human in the loop written into the product. The calendar gets a tool call.

There's a decent reason for the asymmetry: a sent email is irreversible and public, and a calendar event feels like furniture you can move back. I bought that logic for about ten minutes.

What does the connector's code actually allow?

It allows deleting any event on any calendar you can access, and then it tells the guests. The whole answer sits in three lines across three files of `nspady/google-calendar-mcp`, a popular community Google Calendar server for AI agents, at 1,160 GitHub stars and 327 forks as of July 2026. Everything below is from commit 5f301a0, so you can open the same lines I did.

First, the permission it requests. One scope, hardcoded in `src/auth/server.ts` line 65:

scope: ['https://www.googleapis.com/auth/calendar'],

That's the full one. See, edit, share, permanently delete, every calendar you can access.

Second, what happens when the agent calls delete-event. `src/handlers/core/DeleteEventHandler.ts` resolves which account to use, then calls calendar.events.delete() on line 41. There is no confirmation parameter, no dry run, no "are you sure" step anywhere in that path. The only thing standing between the model deciding and the event vanishing is your agent client's own approval popup, which is the first thing you switch to always-allow after the tenth popup.

Third, and this is the one that made me sit up, the default in the tool schema, `src/tools/registry.ts` line 682:

sendUpdates: z.enum(SEND_UPDATES_VALUES).default("all")

The update-event tool carries the same default("all"), ninety lines up in the same file. Move a meeting, everyone gets notified. That is an agent writing to other people's inboxes through a permission you thought was about your own schedule.

Does Google think this is fine?

No, and it says so itself. Google is remarkably direct about the risk, which is the strongest evidence that it's real. Its own remote Calendar MCP server documentation, as it reads in July 2026, warns: "When you expose a language model to untrusted data, there is a risk of an indirect prompt injection attack." It adds that those MCP hosts "can read, modify, and delete data in your Google Account," and tells you to "always carefully review the actions taken by your AI client on your behalf."

Indirect prompt injection means someone hides instructions inside content your agent reads, like an email, and your agent follows them. EchoLeak (CVE-2025-32711, scored 9.3 by Microsoft and 7.5 by NIST) was exactly that: a zero-click injection in Microsoft 365 Copilot triggered by one crafted email, disclosed by Aim Security, fixed server-side, no confirmed exploitation in the wild.

Note the gap in what Google published for its own server. The docs list three scopes, all readonly or freebusy, even though the server exposes eight tools including create_event and delete_event. Two readings fit that gap: Google is deliberately asking for less than the community connector does, or the scope list is incomplete and the write tools simply fail without a write scope. The page doesn't tell you which one it is.

What is the safest setup for AI agent calendar access?

Give the agent its own calendar instead of yours, and make read-only the default for everything else. Google built a scope for exactly this, and the connector I just read straight through doesn't use it.

1. Use `calendar.app.created` instead of `calendar`. Google describes it as letting an app "make secondary Google calendars, and see, create, change, and delete events on them," and it's limited to calendars that app created itself. Your agent gets a full sandbox. Your real meetings are untouchable, no discipline required.
2. Check the scope before you trust the README. Open the connector's source and search for googleapis.com/auth. If you find auth/calendar with nothing after it, that connector is asking for permanent delete on every calendar you can see. In the one I read it was a single line in src/auth/server.ts.
3. Set `sendUpdates` to `none` explicitly. Don't inherit a default that emails your guests. If the tool exposes the parameter, pin it in your agent's instructions for every delete and update call.
4. Keep per-action approval on for writes only. People disable approval because every read call triggers it too. Auto-approve reads, always confirm writes. Trust me on this one: a rule that fires on reads is a rule you'll switch off, so split it.
5. For anything unattended, use a workflow tool, not a chat connector. Chat connectors only act while you're there prompting them. If you want something to fire on its own schedule, that belongs in a workflow where the steps are fixed and visible. If you're picking one, n8n vs Zapier vs Make is the decision.

Build it once, win every week. Ten minutes of scope-reading now, versus explaining to four people why a robot cancelled their meeting.

Would I hand over calendar and inbox access?

Yes, but in the opposite order from how everyone does it. Email is where the industry already built the guardrails for you. The calendar is where a single tool call reaches into other people's inboxes with your name on it.

The honest limit of what I did: I read scopes, docs, and source code, not a week of live decisions. Anyone whose week-long experiment "revealed the permission model" is describing their agent's manners, not its access. Manners are a product decision that changes in a release. Scopes are the contract.

The scope line is a better use of ten minutes than the prompt. The rest of the stack is covered in how to automate your work with AI.

If you've got an agent connected right now, do you actually know which of those two scopes you clicked Allow on?