Yes, in practice. When an assistant calls a connector tool, the result comes back to the model as part of the conversation, so the chat provider's service handles that data. Treat anything a tool returns as data you are sharing with the chat provider, and check its terms before connecting.
What moves where
The MCP architecture overview describes the flow. When the model decides to use a tool, the application routes the call to the server, runs it, and returns the results to the model as part of the conversation. The model then writes its answer using that content.
With a remote connector there is a second hop. Claude's help center says connections originate from Anthropic's cloud. So the request to your security tool comes from the provider, and the answer goes back to the provider.
Two directions of exposure
| Direction | What can leak | Example |
|---|---|---|
| Tool to chat | Findings, asset names, ticket text | A list of critical issues for a project |
| Chat to tool | Anything the model puts in tool arguments | A repository name or a pasted snippet |
OpenAI's MCP documentation warns about the second direction. It says a server may receive sensitive data included in queries, and advises against putting sensitive information in tool definitions. It also says that servers may request more parameters than needed, so the parameters of each action deserve a look.
What the specification asks clients to do
The MCP tools page says clients should show tool inputs to the user before calling the server, to avoid malicious or accidental data exfiltration. It also says clients should log tool usage for audit purposes. Whether your chat app does so is something to verify, not assume.
What this does not tell you
The public documentation of the protocol and the connector guides do not state how long a chat provider keeps conversation content, who inside the provider can read it, or whether it is used for training. Those answers sit in the provider's terms, privacy documentation and your plan's agreement. Read them for the exact plan you use, because they can differ between consumer, team and enterprise plans.
A short routine before you connect
- Classify the data the connector can return. Is it internal only, or customer related?
- Read the chat provider's data terms for your plan and record the date you read them.
- Limit the connector to read tools and the projects needed.
- Run a test with a dummy project first and inspect what the assistant sends and receives.
- Tell users what not to paste into the chat, such as keys or customer data.
Where the risk really sits
Most teams already paste logs and code into chat tools. A connector makes that structured and repeatable, which helps and hurts. It helps because you can scope it. It hurts because it can pull much more than a person would copy by hand.
A worked example: following one question
This is an illustration with made up data.
An engineer asks: list critical findings in the payments project. The assistant calls a findings tool with the project name as an argument. That argument, the project name, travels from the chat provider's service to the connector. The connector returns twelve rows, each with a package, a version and a short description. The rows return to the provider's service and are shown to the model, which writes a summary.
Now list what each party saw. The connector saw the project name and the identity of the user. The chat provider saw the project name, the twelve rows and the final answer. The engineer saw the final answer and, if the app shows it, the tool call. If the engineer then pastes the summary into a ticket, a fourth party sees it.
Step by step: build a data flow note
- List every tool the connector exposes.
- For each, write what it returns, such as project names, package names, descriptions, owner names and ticket text.
- Mark each field as public, internal or restricted.
- Mark which tools take free text arguments, since those are channels from chat to the connector.
- Read the chat provider's terms for your plan and write the date.
- Decide which tools to switch off because their output includes restricted fields.
- Review again at each vendor release.
Table: sensitivity of typical fields
| Field | Example | Typical handling |
|---|---|---|
| Package name and version | a library and a number | Usually low sensitivity |
| Advisory description | Public text | Low, but may contain injected text |
| Repository and project names | Internal names | Internal |
| Owner and contact names | People | Restricted under privacy rules |
| Exploit details for unfixed flaws | Technical detail | Restricted |
This table is a starting point. Your own classification should decide.
What you can reasonably tell users
- Do not paste secrets, customer data or private keys into chat.
- Assume tool results are visible to the chat provider.
- Use the connector for the questions it was approved for.
- Report anything odd, such as an answer that mentions data you did not ask about.
What to ask the chat provider
Ask for the retention period for conversation content on your plan, who within the provider can access it, whether content is used to improve models, and how deletion requests work. Write down who answered and when. This post cannot answer those for you, since the protocol documents and connector guides do not cover them.
When the answer is no
If the data you would expose through a connector cannot be shared with the chat provider under your agreements, do not connect it. Use the security product directly, or ask the vendor about a deployment where the assistant runs under terms you have already accepted.
Where Safeguard fits
You can see what a scan reports without connecting any assistant by running the free scan at gold.safeguard.sh/scan. Safeguard also offers an MCP Guardrail for teams that want policy on which tools agents can call.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch what the assistant asks the tool and what comes back, then ask yourself which of that data you would be comfortable sharing.
Quick check
Does a read only tool avoid sharing data with the provider?
No. Read tools still return data into the conversation. Read only limits changes, not exposure.
Where do I find retention rules?
In the chat provider's terms and privacy documentation for your plan. The protocol documents do not cover them.
Can I limit what the connector returns?
Often yes, by disabling tools and narrowing scopes. Confirm with the vendor which fields each tool returns.
Sources
- MCP architecture overview
- MCP specification, tools
- Claude Help Center, custom connectors using remote MCP
- OpenAI developer docs, MCP
Last reviewed: 19 October 2026.
