topicsthe AI3 numbers3 guides

AI connectors and MCP

MCP made wiring AI into business systems easy. Each connection is standing access that persists, acts, and can be manipulated.

in one lineAI connectors and MCP servers give assistants standing access into mail, files, and business tools, each connection a new access path.

the numbers

  • 79%of organizations run or test AI agents in productionPwC, 2025
  • 47%of deployed AI agents are actively monitored or securedGravitee State of Agentic AI, 2026
  • 47%of security leaders saw AI agents act outside intentSaviynt / Cybersecurity Insiders CISO AI Risk Report, 2026

all the numbers →

1what it is

A connector links an AI assistant to a business system: Gmail, Drive, Slack, the CRM, a database. The Model Context Protocol (MCP), released by Anthropic as an open standard in November 2024 and since adopted by OpenAI, Google DeepMind, and Microsoft, made these connections interoperable: one standard way for any assistant to call any tool.

That standardization is genuinely good for getting value from AI. It also means access paths into your systems can now be created as casually as installing a browser extension. Each connector holds a credential, a token, a key, or an OAuth grant, and through it the assistant does not just read. It acts: sends, edits, queries, deletes, with whatever permissions the connection was given.

2why it accumulates

Connectors are how individuals make their AI useful, so they appear wherever someone has a repetitive task: a founder wires the assistant to email, an engineer points it at the repo, an analyst at the warehouse. Community-built MCP servers multiply the options faster than any review process can keep up.

The result mirrors the broader shadow IT pattern: connections created personally, scoped broadly because narrow scoping is effort, owned by whoever clicked, and never revisited. The difference is the actor on the other end is software that processes untrusted content all day.

3what it costs you

The new risk is manipulation. Published 2026 research testing seven major MCP clients rated tool poisoning, malicious instructions hidden in tool descriptions and content, as critical severity: an assistant can be steered into reading sensitive files or exfiltrating data through its legitimate connections. Prompt injection through connected content has been documented since MCP's first months. The attacker never steals a credential; they borrow yours through the assistant that holds it.

The familiar risks still apply on top. Over-scoped connections multiply blast radius. Orphaned connectors keep working after their creator leaves. And a connector to the CRM or mailbox is a data egress path your DLP was probably never pointed at.

what it looks like when it goes wrong

Three ways this tends to go, each one taken from a real case.

your company
the gap nobody seesEach connector gives an AI standing access to a system, and its instructions are trusted by default.an AI that acts on whatever it reads
  1. howAn email with hidden instructions reaches an assistant that reads every inbox.
    what leavesanything the assistant can seewho ends up with itthe stranger who sent the email
    it happenedEchoLeak / Microsoft 365 Copilot, 2025
  2. howA tool description tells the agent to send files somewhere else.
    what leavesfiles the agent can openwho ends up with itwhoever wrote the tool
    it happenedMCP tool poisoning, 2025
  3. howAn agent with production access ignores the instruction to change nothing.
    what leavesthe live database, deletedwho ends up with ityour customers, who notice first
    it happenedReplit agent database deletion, 2025

4what works

The inventory splits along a technical line. Connectors built on OAuth appear in the IdP's connected-app view with their scopes, owners, and last-use dates; API-key connections and self-hosted MCP servers leave no directory footprint at all, so finding them takes a short survey of the teams most likely to have built them, usually engineering and data. The companies that govern connectors well treat each one like a service account: least privilege, a named owner, and an expiry date. An assistant that drafts replies needs nothing beyond the mailbox, and read-only access does the job wherever the task allows it.

Separate identities for agents and connectors make the rest of the discipline possible. A connector running on its own credentials, never a human's session, can be observed, limited, and revoked independently, which matters most on the day its creator leaves. A human on the destructive path is the other structural control that holds up: sending external mail, deleting records, and moving money stay behind explicit confirmation, however smooth the demo looked without it. From there, connectors join the same quarterly review cycle as OAuth grants and service accounts, where the stale ones get revoked rather than quietly archived.

on the record

← all topics

your turn

what you can do about it

  1. this week

    List which AI tools connect to email, files or chat, and what each connection can do.

    Treat every connector as a standing grant that needs an owner.

  2. go deeper

  3. if you're not sure where to start

    Run the offboarding checklist on one leaver. It covers every account and token to close when someone leaves.

    open the checklist →

the letter · every two weeks

one access gap in your inbox, with the fix.

Every issue takes one way access creeps in, shows a real incident where it went wrong, and ends with one thing to check that week. Written for the people who run the tools, without a security team behind them.

  • 1one mechanism, explained plainly
  • 2one real incident, taken apart
  • 3one step you can take on Monday

get the next issue

One email every two weeks. Your address stays here and is never passed to vendors. One click to unsubscribe. Privacy.