You've found your AI agents. Do you know who they talk to?

You ran the discovery. You have the list: 23 agents and AI apps across Microsoft 365 and Google Workspace, each with a name and maybe an owner. It feels like control.

Then someone asks a simple question: where does the data go? The proposal agent reads the CRM. Does it send anything back out? The note-taker joins client calls. Where do the transcripts end up? The scheduling app has calendar access. Is it passing that to anything else?

Discovery tells you who your agents are. It doesn’t tell you who they talk to. That’s the blind spot in agent sprawl, and it’s where the next generation of incidents is coming from.

Why connections are the blind spot

Agents rarely work alone. To do anything useful they:

• Call connectors and APIs: the CRM, the accounting system, SharePoint, Google Drive.
• Call other apps, which hold their own access to your data.
• Call other agents. New standards make this easier: the Model Context Protocol (MCP) connects AI assistants to tools and data, and agent-to-agent protocols let one agent hand work to another.
• Pick up instructions from what they read. An email, a document or a calendar invite can contain hidden text that tells an agent to do something its owner never asked for.

Every one of those is a connection. Each one extends what the agent can reach, and each one is a path data can take out of the business.

A list of agents shows the dots. The risk is in the lines between them.

What happens when nobody maps the lines

The pattern is already visible in real incidents. In August 2025, Google’s Threat Intelligence Group reported that attackers used stolen OAuth tokens from the Salesloft Drift integration to export data from many companies’ Salesforce instances, and used Drift’s email tokens to read mail in a small number of Google Workspace accounts. Google stressed this wasn’t a flaw in the core Salesforce platform. The attackers simply used a connection that was already trusted.

That’s the shape of the problem. You don’t need to break an agent if you can use what it’s connected to.

The four questions to ask about every connection

For each agent on your list, map its connections and ask:

1. What does it connect to? Every app, connector, API, MCP server and agent it calls.
2. What does each connection carry? Read only, or read and write? Mail, files, customer records?
3. Who approved it? A connection added last week by the agent’s maker isn’t the same as one reviewed by its sponsor.
4. Is it new? A connection that appeared since the last review deserves the first look.

A worked example: the note-taker that passed it on

This is an illustrative example, not a real client. A 50-person wealth management firm runs discovery and finds an AI meeting note-taker, approved by an adviser in March. It’s on the list, with an owner. Box ticked.

What the list doesn’t show:

1. The note-taker joins every client call on the adviser’s calendar and stores transcripts in its own cloud.
2. In September, the adviser connects the note-taker to a CRM add-on so call summaries land on client records automatically.
3. The CRM add-on holds its own grant to the firm’s CRM, with write access to every client record, not just the adviser’s.
4. In October, the note-taker vendor adds an “AI follow-up” feature that drafts emails from the adviser’s mailbox.

Nobody did anything wrong. But the firm now has client call transcripts flowing through three vendors, one of them with write access to every client record, triggered by an app approved for “taking notes”.

Mapping connections turns this from invisible into one review: the CRM add-on’s write access is narrowed to the adviser’s own records, the email-drafting feature is switched off until it’s reviewed, and the chain gets an owner.

How to map and protect agent connections

1. Start from grants

Most agent connections in Microsoft 365 and Google Workspace show up as app grants (OAuth grants) and service accounts. List every grant to mail, files, calendars and directories, and what each allows.

2. Draw the chains

For each agent or app, note which other apps it reaches. Chains of two or three are common; chains that end at customer data are the ones to fix first.

3. Watch for change

Connections drift. A vendor adds a feature, a maker adds a connector, a user approves a new add-on. Set an alert for new connections, not just new agents.

4. Join it to people

When an agent’s sponsor has an odd sign-in, review what the agent connects to as well. A compromised sponsor plus a well-connected agent is how one stolen account becomes a data breach.

5. Be able to cut one line

The fix is rarely “delete the agent”. It’s usually cutting one connection: revoke the grant between two apps, narrow write to read, or reset one token.

Checklist: do you know who your agents talk to?

• Every agent and AI app has its connections listed, not just its name.
• Every connection shows what it carries: read or write, and which data.
• Chains that reach customer or financial data are reviewed first.
• New connections raise an alert to the agent’s owner.
• MCP servers and agent-to-agent connections staff add are on the list.
• A sponsor’s account takeover triggers a review of their agents’ connections.
• You can revoke one connection without breaking the rest.

How Centeye helps

Centeye Synthwatch maps what each agent and AI app can reach across Microsoft 365, Google Workspace and connected apps. Today it lists every app grant and what it allows, with a risk score, and traces app-to-app chains when one connected app uses its access to reach the next. It can cut the grant between two apps before a chain reaches customer data, at the setting you choose. Every revoke can be undone.

Synthagent, the guard agent inside Synthwatch, watches each agent’s connections alongside its identity, authentication and grants, and flags an agent that starts calling an app it has never used. If Centeye Gatewatch finds an agent’s sponsor was taken over, every agent that person owns is reviewed in the same case.

Seeing agents and MCP servers that run on laptops is coming. Synthwatch and Synthagent are in early access.

Frequently asked questions

What is agent sprawl?

When AI agents multiply faster than anyone tracks them. Read AI agent sprawl for where they come from.

Isn’t discovering my agents enough?

It’s the first step. Discovery tells you which agents exist. Securing them also means knowing what each one can reach, how it signs in, and who it talks to.

What is MCP, and why does it matter for security?

The Model Context Protocol is a common way to connect AI assistants to tools and data. Every MCP server an assistant uses is another connection with its own access, so it belongs on the same list as your app grants.

How do agents leak data through connections?

Usually not by being hacked directly. An agent passes data to an app, that app holds broader access than anyone realised, and the data ends up somewhere nobody approved. Or an attacker uses a trusted connection, as in the Salesloft Drift case.

What should we fix first?

Any chain that ends at customer, financial or HR data, and any connection that appeared since your last review.

New to the terms? See AI agent, OAuth grant and non-human identity in our glossary. Want to see who your agents talk to? Ask for early access.

Salesloft Drift incident as reported by Google Threat Intelligence Group, August 2025. The worked example is illustrative. Synthwatch and Synthagent are in early access; this post describes what ships today and what is coming.