OpenAI has recently introduced the Agentic Commerce Protocol (ACP), which enables shopping and purchasing directly within ChatGPT. That is a step forward for agentic applications. Still, it only scratches the surface of a much broader problem: How to safely share sensitive or contextual data between services in large language model (LLM)-driven applications without exposing it to the LLM.
This blog addresses how to safely share sensitive or contextual data between services in large language model (LLM)-driven applications without exposing it to the LLM and provides answers, including:
- Mark sensitive fields such as PII so that the MCP server can flag specific fields in its response as secret that are stored in the MCP host and are never fed into the LLM context, preventing exposure.
- Map secrets to other MCP server inputs so that another MCP server can request these secrets as part of its operation, enabling workflows such as payments, internal lookups, or API calls without exposing the model to the raw data.
The Broader Challenge
ACP primarily focuses on the payment use case, but there are many other scenarios where data must be exchanged between services or tools, even though the LLM itself does not need to see the content.
Examples include:
- Personally identifiable information (PII)
- Internal URLs or private endpoints
- API tokens or short-lived credentials
- Any sensitive metadata that supports workflows but is irrelevant for the model’s reasoning
There are good reasons to keep this information out of the LLM context:
- Prompt injection: Exposing secrets in prompts could allow a malicious actor to manipulate the model into revealing or misusing sensitive information.
- Persistent chat history: In tools like ChatGPT or Claude Desktop, conversation history can be long-lived or logged, which increases the risk of accidental exposure.
At the same time, an MCP host, whether that’s Claude Desktop, ChatGPT Desktop, Visual Studio Code, or another client, is often a trusted environment. This trust allows the host to act as a safe intermediary, managing secrets while the LLM itself remains unaware.
A Proposed Approach: Secrets in MCP
One way to address this problem is to treat specific fields in MCP server responses as secrets:
- Mark sensitive fields: An MCP server can flag specific fields in its response as secret.
- Hidden to the LLM: The secret is stored in the MCP host and is never fed into the LLM context, preventing exposure.
- Map secrets to other MCP server inputs: Another MCP server can request these secrets as part of its operation, enabling workflows such as payments, internal lookups, or API calls without exposing the model to the raw data.
Example: Buying a Wombat Cookie Cutter
Consider an AI assistant is used to explore marsupials. The user sees a picture of a wombat and decides they’d like to buy a wombat-shaped cookie cutter.
- One MCP server connects to trusted online shops. It provides APIs for searching products and placing orders.
- Another MCP server securely stores personal information, such as the shipping address and payment details.
Workflow:
- The LLM identifies that a purchase requires payment data and requests it from the personal-information MCP server.
- That server responds but marks the payment fields (credit card number, address) as hidden.
- The MCP host filters these fields out before the response reaches the LLM.
- The LLM prepares a purchase request for the shop MCP server, without seeing any secrets.
- The MCP host detects that the transaction requires secrets from another MCP server response, asks the user for consent, and, when approved, injects the relevant secrets into the final request.
This design allows the LLM to coordinate the workflow, finding the product, preparing the transaction, and confirming the purchase, while remaining completely unaware of any sensitive personal information.
Requirements For Practical Adoption
For this approach to work in real-world MCP hosts, a few key requirements emerge:
- User permission interface: The MCP host must allow users to explicitly grant or deny access to specific secrets to other MCP servers.
- Standard for hidden fields: A common way to mark fields as secrets across different servers and tools.
- Field semantics: A standard to define the semantics of fields to enable the MCP host to apply mappings for MCP server requests.
With these pieces in place, workflows can safely orchestrate sensitive operations across multiple MCP servers, while the LLM remains insulated from confidential data.
Looking Forward
The Agentic Commerce Protocol (ACP) is a step forward for shopping and payment workflows in agentic use cases. However, a generic solution covering more use cases dealing with sensitive data is required. The proposed approach opens up possibilities beyond commerce, enabling secure AI-driven workflows across various industries, including finance, healthcare, software development, and more. Besides an extension to the MCP standard for secrets, a standard for semantics is required. Efforts like the Open Semantic Interchange Initiative aim to define such open standards. Ideally, the initiative will build upon RDF, as it’s already a well-established standard for the semantic layer.
Additional Notes
For the sake of readability, several technical aspects have been simplified in this post.
While the discussion focuses on MCP, the same principles apply to plain tool calling as well. MCP simply provides a defined architecture and shared terminology that make it easier to explain the concept.
In describing the handling of secrets, the text refers to “hiding” or “filtering” fields. In practice, there are several possible implementation strategies, such as:
- Omitting the field entirely, as if the property never existed.
- Clearing the field’s value.
- Replacing the value with a placeholder (e.g., “[sensitive data redacted]”). Substituting the value with a token and attaching metadata so that the LLM understands the token can be used as a variable in the following steps. This approach would allow the LLM to do the mapping of the variable to the input of another tool call.