Guides › AI connectors and MCP

AI Connector and MCP Security: Protecting Enterprise Data Behind Tool Access

Q: Does a vendor connector respect our permissions?

Native connectors from OpenAI, Anthropic and Microsoft run as the user and state that source permissions apply. That means the assistant surfaces everything those permissions allow, which in most tenants is more than intended. Custom MCP servers and apps often run as a service account and are whatever their authors made them.

Q: Can we log what the assistant fetched through a connector?

Platform admin logs record that an app was called and, on some tiers, the request and response. They don't record which of your documents or records were returned in a form you can audit against entitlements. Retrieval telemetry on your side of the boundary does.

Hunter Moore, Founder and CTO · Updated October 15, 2026

A connector is the fastest-growing route enterprise data takes to a model. Native connectors in ChatGPT, Claude and Copilot, Model Context Protocol servers, custom apps and agent tools all do the same thing: they let the assistant read a source or take an action on a user's behalf and put the result into model context, without the user ever choosing what to share. In May 2026 the NSA's AI Security Center published design guidance for MCP that says established cyber defenses do not adequately address the risks. This guide explains why a connector is a retrieval path and should be governed as one, walks through the six ways connectors fail, summarizes what the NSA guidance asks for, and lays out the controls by layer that hold.

At a glance

What a connector is. Any path by which a model reads a source or takes an action on a user's behalf: native connectors, MCP servers, custom apps, agent tools. The model decides what to fetch, so it is retrieval, governed by the same rules as a knowledge base plus identity, supply-chain and chaining questions of its own.
How it fails. Over-broad grants, service-account identity that every user inherits, instructions arriving inside tool results, unverified servers with poisoned descriptions, data flowing between tools, and no record of what was fetched.
What the NSA says. Its May 2026 MCP guidance names serialization risks, trust boundaries and agent misuse, and dynamic tool invocation, implicit trust and context sharing as novel risks that established defenses do not adequately address. Authentication, authorization and input validation remain necessary; the environment has to be secured as a whole.
What holds. Per-user identity and least-privilege scope, entitlement checks at call time, identifier substitution before results reach a third-party model, telemetry on every call, and testing with content that carries instructions.

What a connector is, and why it is a retrieval path

Four things get called connectors, and they share one property. Native connectors are the integrations a platform vendor ships and maintains: SharePoint, Google Drive, Gmail, Slack, GitHub, HubSpot and the rest, reached through the vendor's own code under a user or application grant. MCP servers implement the Model Context Protocol, an open standard in which a small server exposes tools and resources to any compatible client, so a model can call a database, a ticketing system or an internal API through the same interface. Custom apps and GPTs wrap an API behind a description the model reads to decide when to use it. Agent tools are the general case: any function an autonomous workflow can invoke, including other agents.

The shared property is that the model, rather than the user, decides what to fetch. A user asks a question; the assistant decides a connector is relevant, calls it, and receives whatever the connector returns, which then becomes context for the answer. That is retrieval, in the sense the AI knowledge base security guide uses the word, with two differences that matter. The retrieval happens live against production systems rather than against an index you built, and the result can include actions, not only reads. Every control that applies to a retrieval corpus applies here, plus a few that are specific to tool access.

Six ways connectors fail

The table names each failure mode, the mechanism, what it exposes and the control that answers it. The sections after the table expand on the ones that are least well understood.

Failure mode	How it happens	What it exposes	Control that holds
1. Over-broad grant	The connector is authorized against the whole tenant, drive or database when one site, folder or table was needed.	Everything in scope, for every user of the assistant.	Least-privilege scope per connector; read-only unless writes are required.
2. Identity mismatch	The connector authenticates as a service account or API key instead of the asking user.	Every user inherits the service account's reach.	Delegated per-user identity; where impossible, entitlement checks at call time against the user.
3. Injection through tool results	Retrieved content carries instructions the model follows, and a second tool can write, send or post.	Other documents, other users' data, credentials, sent outside the boundary.	Treat tool results as untrusted; restrict chaining to write tools; test with planted instructions.
4. Unverified servers and poisoned descriptions	An MCP server or custom app is added without review; its tool descriptions carry hidden directives or its behavior changes after review.	Whatever the server's credential can reach, plus misuse of other tools.	Reviewed catalog, pinned versions, descriptions treated as untrusted input, re-review on change.
5. Context sharing between tools	Output of one tool becomes input to another the user couldn't have used that way.	Data written or sent somewhere the user had no entitlement to put it.	Allowed tool combinations defined in advance; approval for the rest; telemetry across the chain.
6. No record of what was fetched	Platform logs show that an app was called, not which records were returned to whom.	Nothing directly; it makes every other failure undetectable.	Retrieval telemetry under opaque IDs at the tool layer, before rollout.

Identity mismatch is the quiet one

Native connectors in ChatGPT, Claude and Copilot generally run as the individual user, which means the assistant can never reach more than that person already could. Many MCP servers and custom integrations don't. They authenticate once, with a service account or an API key, and every user of the assistant inherits that account's reach. A finance analyst asking a question is, from the source system's point of view, the service account, with whatever the service account can see. The RAG permissions guide calls this the index-time problem; with connectors it is the credential-time problem, and it is why the identity model is the first thing to check on any tool integration.

Injection through tool results is the one that moves data out

A connector returns content, and content can contain instructions. A document in a shared drive, a ticket a customer filed, a web page an agent fetched: any of them can carry text that tells the model to summarize the user's other documents and send them somewhere. The model can't reliably distinguish instructions in retrieved content from instructions from the user, and an agent with a second tool that can write, send or post has an exfiltration path. The indirect prompt injection guide covers the mechanism for retrieval pipelines; with agents the surface widens because the model chooses which tools to chain and nobody reviews the chain in advance.

Unverified servers and poisoned tool descriptions

An MCP server is code. The platform that lets a user add one does not, in general, review it; OpenAI states plainly that custom apps are not verified by OpenAI and that administrators should add only apps they trust. A server's tool descriptions are read by the model as instructions about when and how to call the tool, so a description can carry hidden directives, and a server that behaves correctly during review can change behavior after. The practical rule is that a server is a dependency with the same supply-chain obligations as a library, and that its descriptions are untrusted input.

Context sharing between tools

When an agent calls several tools in one task, the result of one call is available to the next. Data the user was entitled to read through tool A can be passed as an argument to tool B, which writes it somewhere the user couldn't have written it, or to tool C, which sends it outside the boundary. The NSA guidance names context sharing, implicit trust relationships and dynamic tool invocation as the novel and systemic risks of agentic systems, and that description matches what practitioners see: the permissions on each tool are right, and the combination is wrong.

What the NSA's MCP guidance asks for

On May 20, 2026, the NSA's Artificial Intelligence Security Center released a cybersecurity information sheet titled Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation. It is a design document rather than a compliance standard, and it is the clearest federal statement so far that tool-connected AI is a distinct security problem. Its main points are summarized below; the full sheet carries the practical recommendations for high-stakes and production environments.

NSA AISC, May 20, 2026: Model Context Protocol (MCP) security design considerations

Named concerns. Serialization risks, trust boundaries and agent misuse in MCP design, implementation and operation, given as examples rather than a complete list. Dynamic tool invocation, implicit trust relationships and context sharing described as novel and systemic risks of agentic AI systems.

The core finding. Established cyber defense strategies do not adequately address these new risks, and misaligned assumptions or subtle inconsistencies at any stage can propagate and compound into exploitable conditions.

What it asks for. Authentication, authorization and input validation remain necessary. Secure the agentic environment as a continuum rather than patching individual interfaces or endpoints. Proceed with caution and heightened scrutiny, drawing on lessons from earlier distributed and plugin-based ecosystems. The full sheet carries practical recommendations for high-stakes and production environments.

Controls by layer

The failure modes above sort into six layers, and each layer has one control that answers it. Most deployments have the first two in some form and none of the last four, which is why the audit question is rarely “do we have controls” and usually “which layers are empty.” The table is the version that fits on one page; the connection procedure turns it into an order of operations, and the framework crosswalk maps each layer to MITRE ATLAS, OWASP, NIST AI RMF, ISO/IEC 42001 and the EU AI Act.

Layer	The control	Answers failure modes	Who usually owns it
Identity	Connectors run as the asking user; service accounts are the exception and are documented.	2	Identity and platform admins
Scope	Least-privilege grants per connector; read-only by default; reviewed catalog of servers with pinned versions.	1, 4	Platform admins, application security
Retrieval	Entitlement checked at call time against the live source; tool results treated as untrusted content; allowed tool chains defined.	2, 3, 5	Data security layer
Substitution	Real identifiers replaced with consistent stand-ins before results reach a third-party model; restored only for entitled readers.	3, 5 (limits what exfiltration yields)	Data security layer
Telemetry	Every call recorded with tool, arguments, user and records returned, under opaque IDs.	6, and detection for all others	Data security layer, SOC
Testing	Exposure tests with planted instructions and cross-tool questions before rollout and after every change; findings mapped to MITRE ATLAS.	All	Security engineering

A connector review checklist

Before any connector, MCP server or agent tool reaches production data, the following should have a written answer.

Whose identity does it run as, and if a service account, what can that account reach that the typical user can't?
What is the narrowest grant the source supports, and is that the one in use? Read-only where reads are all that's needed.
Who wrote the server or app, who reviewed it, and what happens when it changes? Tool descriptions are untrusted input.
Can the assistant chain this tool with any tool that writes, sends or posts? If so, which combinations are allowed, and who approves the rest?
Are entitlements checked at call time against the live source, or inherited from a credential issued months ago?
For sources holding regulated identifiers reached by a third-party model, is substitution in place before the result leaves the boundary?
Is every call recorded with the tool, the arguments, the user and the records returned, under opaque IDs?
Has anyone tested it with content that carries instructions, and measured what the assistant did?

When the agent's job is retrieval across several sources and hops, the multi-hop join problem, the per-hop entitlement check and the test method are covered on the GraphRAG and agentic retrieval security page; the reference architecture shows where the connector sits among the trust boundaries.

Where Hardshell sits

Hardshell is the retrieval, substitution, telemetry and testing layers of the table above. It connects to the systems where data already lives without migrating them, inherits their permissions and checks entitlements at query time, substitutes stand-ins for real identifiers before content reaches a model provider, and records every retrieval under opaque IDs. Exposure testing exercises a connected assistant with the questions and planted content it should refuse, counts what it returned, and maps the findings to MITRE ATLAS technique IDs. It works as a connector inside ChatGPT and Claude and as a layer in front of internal retrieval and agent systems, and deploys as a cloud service, in a private cloud or as an offline bundle for disconnected environments.

Frequently asked questions

Is MCP secure enough for enterprise use?

The protocol is a transport and a schema; the security comes from how the client, the server and the surrounding controls are built. The NSA's May 2026 guidance treats MCP as usable in production with heightened scrutiny: authentication, authorization and input validation remain necessary, and the agentic environment has to be secured as a whole rather than one endpoint at a time. The checklist above is a reasonable minimum.

Does a vendor connector respect our permissions?

The native connectors from OpenAI, Anthropic and Microsoft run as the user and state that source permissions apply. That is the right model, and it means the assistant surfaces everything those permissions allow, which in most tenants is more than intended. Custom MCP servers and apps are whatever their authors made them, and often run as a service account.

What is the difference between a connector and RAG?

RAG indexes a corpus you built and retrieves from the index. A connector retrieves live from the production source, and may act on it. Both put content the user didn't choose into model context, so the same scoping, substitution and telemetry apply. Connectors add identity, supply-chain and tool-chaining questions that an index doesn't have.

Can we log what the assistant fetched through a connector?

The platform's admin logs record that an app was called and, on some tiers, the request and response. They don't record which of your documents or records were returned in a form you can audit against entitlements. Retrieval telemetry on your side of the boundary does. The open-source telemetry client is a starting point for retrieval systems; connectors need the equivalent at the tool layer.

Should we allow users to add their own MCP servers?

Not against production data. Allow a reviewed catalog, scope each server's identity and grant to the minimum, and route anything that touches regulated sources through substitution and telemetry. A server a user added from a public listing is unreviewed code with a credential, and it should be treated the way an unreviewed browser extension on a finance workstation would be.

Sources

National Security Agency, Artificial Intelligence Security Center, press release and cybersecurity information sheet, Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation, May 20, 2026.

OpenAI Help Center, Admin controls, security, and compliance in connectors (Enterprise, Edu, and Business), accessed October 2026. Anthropic, Use Google Workspace connectors, accessed October 2026. Microsoft Learn, Microsoft 365 Copilot architecture: data protection and auditing, accessed October 2026.

MITRE ATLAS, content release 2026.08, for technique mapping of connector findings; see the MITRE ATLAS for AI data security guide.