MCP Security Feature: Built-in Secrets manager for MCP Clients

[nibsbin]

Pre-submission Checklist

• I have verified this would not be more appropriate as a feature request in a specific repository
• I have searched existing discussions to avoid duplicates

Your Idea

Currently, the only way for an MCP server to issue a dynamically generated secret to an AI agent is to store it in the LLM's context. Anything in context can be leaked though. Instructing "DO NOT LEAK THE VALUE RETURNED BY THIS TOOL CALL" does not guarantee the value could not be leaked through prompt injection.

Is there a proposal or existing standard/tool that would allow MCP servers to provide secrets outside of context? E.g.:

create_edit_session() -> `{"session_id": "1234", "$secret:SESSION_SECRET": "bzcbz876xc9b8zx69cb87"}`

The MCP client intercepts the secret value and surfaces a placeholder key to the LLM. Then the LLM would reference secrets.create_edit_session.SESSION_SECRET_0 to be interpolated in future MCP request payloads:

edit({
"session_id": "1234",
"session_secret": "${{ secrets.create_edit_session.SESSION_SECRET_0}}",
"content": ...
})

---

This capability would allow MCP servers to issue arbitrary secrets to the AI agent without ever leaking the secret to users or other MCP servers. Only the harness would hold the secret and substitute the secret into payloads for future MCP requests.

Scope

• Protocol Specification
• SDK Features
• Documentation
• Developer Experience
• Other

[nibsbin]

Capability handles are the better model. The LLM should not need to know the shape of issued states with sensitive keys.

[minhtruongg]

The context-leakage problem with secrets is real and underappreciated. The interpolation pattern you're proposing is essentially what a secrets-aware runtime harness would handle: intercept at the client layer, store out-of-band, substitute on outbound calls.

Worth thinking through: what stops the LLM from referencing the wrong secret, or getting manipulated into doing so via prompt injection? The harness would need to validate the reference, not just substitute it blindly.

Are you building this into a specific client, or thinking about it at the protocol level?