Replies: 2 comments
-
|
Closing in favour of: modelcontextprotocol/modelcontextprotocol#2185 |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
If it is sensitive because data can be leaked,. it's not worth the effort
not to train for the sake of saving data ,.just flood with a continuous
stream of data in case of unauthorized access, preset page,.
sub, 31. jan 2026. 21:40 Marlin Ranasinghe ***@***.***> je
napisao/la:
… Pre-submission Checklist
- I have verified that this discussion would not be more appropriate
as an issue in a specific repository
- I have searched existing discussions to avoid duplicates
Discussion Topic
Hey everyone! 😄
I am from the #financial-services-wg, and as you know, we deal with
sensitive data and are heavily regulated. We want to be able to give our
users the ability to query about their banking information in their
favorite AI assistants (ChatGPT, Claude, Gemini), via an MCP server
proposition. However, one of the friction points is that, typically by
default, most AI assistant providers train on consumer messages, which, if
possible, we would like to avoid.
In an ideal world, where all parties are cooperative, I think something
like this would mostly work:
- First, let's define a sensitive MCP server as one that does not wish
to have chats that have made use of it, be used for future training
- In the InitializeRequest, we add an attribute, where the MCP client
can express that they support the ability to not train on chats if a
sensitive MCP server requests
- Sensitive MCP servers could reject the initialization request if the
MCP client has no support to not train on chats that utilize it
- In the _meta property of InitializationResult, reserve a key such as
io.modelcontextprocol/do-not-train that sensitive MCP servers would set
- Model providers that support the ability to not train on chats would
respect the io.modelcontextprocol/do-not-train mark (if at least one
tool call was made to a sensitive MCP server during a chat, it would
exclude the rest of that particular chat from training)
- The above described approach relies on trust, and could be easily
exploited by bad actors, so as an additional step, we could whitelist our
sensitive MCP server to only respond to trusted model providers
Playing devil's advocate to the approach I described above:
- Can we rely on model providers wanting to support this? Is it in
their best interests? Can we ever get MCP servers that provide sensitive
data without this?
- In chats configured with multiple MCP servers, this still doesn't
prevent sensitive data from being fed out of a sensitive MCP server to
another MCP server that the sensitive MCP server does not trust. (Maybe an
additional mechanism to tell MCP clients to ensure that we are the only MCP
server in a chat?)
We can mostly "deal" with these issues by running users through a strong
consent flow, but I can imagine there are others who cannot.
Curious to hear the community's feelings, if anyone already has a
solution, or any other proposed solutions! 🤝
—
Reply to this email directly, view it on GitHub
<#673>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/BUS22LQS67QAZ4KW3MXISEL4JUHMVAVCNFSM6AAAAACTRRHK6SVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZZGQYTEOBVG4>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Pre-submission Checklist
Discussion Topic
Hey everyone! 😄
I am from the
#financial-services-wg, and as you know, we deal with sensitive data and are heavily regulated. We want to be able to give our users the ability to query about their banking information in their favorite AI assistants (ChatGPT, Claude, Gemini), via an MCP server proposition. However, a friction point is that, typically by default, most AI assistant providers train on consumer messages, which, if possible, we would like to avoid.In an ideal world, where all parties are cooperative, I think something like this would mostly work:
InitializeRequest, we add an attribute, where the MCP client can express that they support the ability to not train on chats if a sensitive MCP server requests_metaproperty ofInitializationResult, reserve a key such asio.modelcontextprocol/do-not-trainthat sensitive MCP servers would setio.modelcontextprocol/do-not-trainmark (if at least one tool call were made to a sensitive MCP server during a chat, it would exclude the rest of that particular chat from training)Playing devil's advocate to the approach I described above:
Curious to hear:
Beta Was this translation helpful? Give feedback.
All reactions