Your AI Assistant Can Now Read Your Inbox and Your Database. Who Approved That?

Until recently, connecting an AI assistant to a business's actual systems — its inbox, its CRM, its internal database — meant custom engineering work: someone had to build and maintain a bespoke integration for every tool the assistant needed to reach. A protocol called MCP, short for Model Context Protocol, has mostly removed that barrier. Introduced by Anthropic in late 2024 as a standard way for an AI assistant to talk to outside tools and data sources, it has since been adopted across the major AI platforms and coding environments, and an ecosystem of thousands of ready-made connectors, called MCP servers, has grown up around it. The practical effect for a business is that giving an assistant like Claude or ChatGPT the ability to read a calendar, search a shared drive, or query a database is no longer a development project. It is closer to installing a browser extension.

That is a genuine capability gain, and it is why adoption has moved as fast as it has. A connector that used to require a developer and a sprint now takes a few minutes to point an assistant at, which means the businesses benefiting most are, again, the ones that never had the engineering budget to build custom integrations in the first place. It also means the decision to connect an assistant to a sensitive system has quietly moved from a procurement or IT conversation to something an individual employee can do on their own, the same shift that made AI app builders and shadow AI a governance problem before this one.

The risk MCP introduces is specific, and it is not the same as an ordinary integration going wrong. An AI assistant connected this way does not just fetch data — it reads whatever that data contains as part of the same stream of instructions guiding what it does next. If a connected inbox contains an email, or a connected support queue contains a ticket, with text deliberately written to look like an instruction rather than content, an assistant with no reliable way to tell the difference can follow it: forward a message, alter a record, hand over a file it was never asked to share. Security researchers have taken to calling this class of problem tool poisoning or prompt injection through tool responses, and the reason it matters more here than in a typical chatbot conversation is that a connected assistant does not just answer with bad text — it can act, inside a system that actually holds your business's data.

The second problem sits underneath the first: how much access the connector was given in the first place. Because MCP servers are simple to publish and simple to install, a large share of what a business ends up connecting is third-party code nobody on staff has reviewed, granted permissions nobody scoped down from the default. A connector added to let an assistant check calendar availability is frequently granted the same access a person would have logging into the full calendar account, because narrowing that access takes an extra step most people don't know to take, or don't realize matters. National security agencies that published MCP-specific security guidance this year made the same point in more formal terms: the protocol's adoption has outrun the tooling and habits that would normally keep access like this in check.

None of this argues for treating every connector as suspect or holding the technology at arm's length, which would just push the same convenience-driven adoption further out of view, the way banning AI chat tools outright tends to push their use onto personal devices instead of removing it. It argues for applying the same discipline a well-run business already applies to any new piece of software asking for access to its systems. Install connectors from known, reputable publishers, not whatever appears first in a search or a registry listing. Grant the narrowest scope the task actually needs — read-only wherever a connector's job is to look something up rather than change it — rather than accepting a broad default because it was the path of least resistance. And treat any connector that can take an action with real consequences — sending something, deleting something, moving money — as a materially different decision than one that can only read and summarize.

The concrete question worth asking before connecting an assistant to anything consequential is simple: if the content this assistant reads through this connector contained a hidden instruction planted by someone else, what could it be talked into doing next. For a connector that only reads a public calendar, the honest answer is usually "not much." For a connector that can send email, write to a customer record, or touch a financial system, the honest answer is often "more than we'd want," and that gap is exactly what deciding on scope and vetting is supposed to close before the connector goes live, not after.

The businesses that get real value from this shift will not be the ones that connected the most systems fastest. They will be the ones that treated each connector the way they would treat handing a new piece of software the keys to a system it now has standing access to — asking who built it, what it can actually do, and whether it needs to do that much — before it became one more thing quietly running in the background of how the business operates.