Audit What Your AI Can Already Reach

Permissions accumulate one reasonable decision at a time. You connected your calendar because scheduling was tedious. Then your email, so it could draft replies. Then your files, because it kept asking for context you had to paste.

Each grant was sensible in isolation. Nobody has ever looked at the combined list, and the combined list is the thing that matters — because the question isn't what any one integration can do, it's what someone who compromised any part of it could reach.

Do the inventory first

Half an hour, once, and most people find something they'd forgotten.

Go to each AI tool's settings and find the connections, integrations, or connected apps list. Write down: what it's connected to, whether it can read or also write, and when you last used that connection for anything.

Then check it from the other side. Google and Microsoft accounts both have a "third-party apps with account access" page, and it's usually longer than the list you just wrote — because it includes tools you trialled once, browser extensions, and things a colleague connected on a shared workspace.

The one people most often find: a tool they stopped using months ago that still holds live access.

The three questions per connection

Does it need write, or would read do? Most integrations request write because it's simpler to ask for everything, and most tasks need read. Downgrading write to read on connections you only ever read from removes an entire category of failure at no cost to what you use it for.

What's the worst thing it could do if the instructions came from somewhere other than me? This is the prompt-injection question, and it's the one worth sitting with. An agent that reads your email and can also send from it can be instructed by an email. That's not hypothetical and it doesn't require anyone to breach anything.

Would I notice? Reads are invisible. If a connection can read a whole drive and something reads a whole drive, nothing anywhere will tell you.

The combinations that matter more than the parts

Individually-reasonable permissions get dangerous in pairs:

• Read private data + send externally. Anything that can read confidential material and also communicate outside your organisation is one bad instruction from exfiltration. This is the pair to break if you break only one.
• Read untrusted content + take actions. Email, web pages, shared documents, tickets — all of them are text written by other people. Anything that reads them and also acts is instructable by whoever wrote them.
• Broad scope + no logging. Not dangerous by itself, but it decides whether you'd ever be able to reconstruct what happened.

What to actually do about it

Revoke the unused. Anything you haven't used in three months goes. Reconnecting takes a minute and you'll only do it for things you actually want.

Narrow the scope. Most tools support connecting a folder rather than a drive, a label rather than a mailbox, a project rather than a workspace. Almost nobody uses this, and it's usually two clicks.

Break one of the dangerous pairs. If something can read sensitive material and send externally, remove one side. Draft-only rather than send is the common answer and it costs very little.

Diary a re-check. Twice a year. Permissions creep back, tools change what their integrations request, and defaults get updated in your favour or against it without an announcement.

Ravi — the tool he'd stopped using

Ravi is a finance director at a manufacturing firm. His audit turned up eleven connected applications on his work account; he could account for six.

Of the remaining five, one was a meeting-notes tool trialled the previous year and abandoned. It still had read access to his calendar and his entire email history, and had presumably had it throughout.

Nothing had gone wrong. His point about it: he had no way to know that, because reads leave no trace, and the tool had been sitting there for eleven months without a single reminder that it existed.

Marta — the pair she broke

Marta leads a client services team at an agency. Her assistant tool could read the shared inbox and send from it, which was the entire point.

What changed her mind was a demonstration of the mechanism rather than an incident: a message containing instructions, read as content, acted on as a request. Nobody had to breach anything — the tool worked exactly as designed.

She moved it to draft-only. Replies now appear in Drafts and someone presses send. Her team lost roughly ten seconds per reply and lost the property that the inbox could be instructed by its own contents.

The one thing

Permissions accumulate individually and matter collectively. The exposure isn't any single integration — it's the combination nobody has looked at.

Inventory it once, revoke anything unused, narrow the scope where you can, and break the read-sensitive-plus-send-externally pair. Then diary it for six months, because it grows back.