AI Connectors: The Permission Your AI Policy Forgot

By the Shadow AI Policy team

Almost every AI acceptable use policy answers one question well — which tools may people use? Very few answer the second one: what are those tools allowed to reach?

That second question is where the data actually goes. An approved AI assistant connected to company mail, files and chat can read more in a second than an employee could paste in a week, and it does so without anyone making a decision at the moment it happens. If your policy governs the tool but not the connection, the most consequential grant in the whole arrangement is the one nobody signed off on.

Why a paste-only data rule leaves a hole

Section 6 of nearly every AI policy — ours included, until this week — is a list of things employees must not enter into an AI tool: customer data, HR records, source code, contracts. It is good advice and it is worth keeping. But read it literally and notice what it assumes: that data leaves the company because a person typed or uploaded it.

A connected tool breaks that assumption. Once an assistant holds a standing authorization to a mailbox or a document store, the data path no longer runs through the keyboard. The tool fetches what it needs. An employee can follow the paste rule perfectly, all day, every day, and still be sitting on top of an exposure the policy never described.

This is the same category error that made browser extensions a governance gap — a problem we wrote about here — except that connectors are usually granted deliberately, by people who believe they are doing something routine, and are then never looked at again.

What CoSnitch showed, and what it did not

On 18 August 2026 Microsoft shipped a server-side fix for a chain of three vulnerabilities in Copilot Personal, disclosed by Varonis Threat Labs under the name CoSnitch and tracked as CVE-2026-24301. The mechanism is worth understanding precisely, because it is a cleaner illustration of the connector problem than anything we could have invented.

An undocumented URL parameter caused a prompt supplied in a link to execute the moment the page loaded, inside the victim's already-authenticated session. That injected prompt could then query the services the user had previously connected, encode what it retrieved, and use the assistant's own ability to fetch a URL to send the results to an endpoint the attacker controlled. Varonis reported the issue to Microsoft in December 2025 and found no evidence of exploitation in the wild.

Three things about that sequence matter for policy:

• Nobody pasted anything. The user clicked a link. Every paste-based control an employer might have had — training, DLP on the clipboard, a rule in Section 6 — was simply not in the path.
• The blast radius was the connection list, not the conversation. What the attacker could reach was defined entirely by which apps that account had been connected to, months earlier, by someone who was not thinking about security at the time.
• It was the personal tier. This was Copilot Personal, the consumer product — not Microsoft 365 Copilot under a commercial tenant. That distinction is the policy lesson, not a footnote.

To be clear about the state of it: this specific flaw is patched, and we have no reason to tell anyone that their Copilot deployment is currently exposed. The reason to care is that the shape of the attack is not specific to Microsoft. Any assistant that can be handed content and also holds standing access to systems has the same two halves. Vendors will keep closing individual instances; the structural risk is the grant.

The rule we added to our own template

We changed the free policy template this week rather than writing about a gap we had left open. Two additions, in the two places the gap actually lives.

In the tool tier list (Section 5)

Approval covers a tool, not everything that tool can reach. Connecting an AI tool to company email, files, calendars, chat, code repositories or any other system — through a connector, plug-in, extension or "sign in with" authorization — now requires separate approval from the policy owner, because it gives that tool standing access to data nobody pasted into it. The personal or free tier of any tool must never be connected to a company account or company data, and limited-tier and prohibited-tier tools must not be connected at all. Grants already made get reviewed on the same cycle as the tier list itself.

In the data handling rules (Section 6)

Data can leave an AI tool without anyone typing it in. A link, document, web page or message that an AI tool opens on your behalf can contain instructions the tool follows as though you had given them — including instructions to gather whatever the tool can reach and send it somewhere else. So: do not open AI-assistant links that arrive from outside the company, do not point a connected tool at content you do not trust, and if a tool does something you did not ask it to do, stop and report it.

That second clause is deliberately written without the words "prompt injection." An employee does not need the term to follow the rule, and a policy that makes people feel they need a security background to comply is a policy people quietly stop reading.

Four things to do this month

1. Pull the OAuth grant list from your identity provider. Entra ID and Google Workspace both show which third-party apps hold access to your tenant and at what scope. This is an inventory you already own and probably have never read. Expect it to be longer than you think.
2. Revoke first, ask second. Remove grants that are unused, unrecognized, or attached to a personal-tier account, then let teams tell you what they need back. Surveying first surfaces the connectors people remember, which are not the risky ones.
3. Add connector approval to the same workflow that approves tools. Not a new process — the same request, the same owner, one extra field naming what the tool will be allowed to reach.
4. Put an expiry on grants. A connection approved for a project should not outlive it. Reviewing grants on the same cycle as the tier list is the cheapest version of this that works.

The underlying point

Shadow AI stopped being only about which tools employees sign up for. The tools your company approved, paid for and rolled out are now the ones with the deepest reach into your systems, and the permission model that gives them that reach is largely invisible to the people who own the policy.

A tier list that names ChatGPT and Copilot but says nothing about what they are plugged into is answering the 2023 version of the question. Governing the connection is the 2026 version, and it is a paragraph of work, not a project.