AI connectors and MCP

what 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.

why 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.

what 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 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.