[dfabulich]

> For security, other than what the MCP protocol itself provides, what should be defined?

The MCP protocol itself provides no security at all.

The MCP specification includes no specified method of authorization, and no specified security rules. It lists a handful of "principles," and then the specification simply gives up on discussing the problem further.

https://modelcontextprotocol.io/specification/2025-11-25#sec...

    3.2 Implementation Guidelines

    While MCP itself cannot enforce these security principles at the protocol
    level, implementors **SHOULD**:

    1. Build robust consent and authorization flows into their applications
    2. Provide clear documentation of security implications
    3. Implement appropriate access controls and data protections
    4. Follow security best practices in their integrations
    5. Consider privacy implications in their feature designs

[notepad0x90]

it's just an http or stdio server, would there be considerations beyond that of any other http server or cli app? shouldn't the security be dependent on deployment details? Like you wouldn't require OAUTH if it is deployed on localhost only, or if there is a reverse proxy handling that bit.

There is a reason it cannot enforce those principles, an MCP is a web service. it could use SQL as a backend for some reason, or use static pages. it might be best to use mTLS, or it might make sense to make it open to the public with no authentication or authorization whatsoever, and your only concern might be availability (429 thresholds). the spec can't and shouldn't account for wildly varying implementation possibilities right?

[davidcrowe]

The difference is that MCP introduces a third party: the agent isn't the user and isn't the service, but it's acting on behalf of one to call the other. Standard HTTP auth assumes two parties. That's the gap the spec needs to address.