This pull request adds definitions for "First-Party Hosted MCP Server" and "MCP Proxy Server", along with a clarifying architecture diagram, to the security best practices documentation. Adding this terminology helps to set the basis for further discussions on best practices.

Motivation and Context

The operational context of an MCP Server significantly impacts its security considerations. An MCP Server can either directly manage access to resources owned and controlled by the same entity operating the server ("First-Party Hosted") or act as an intermediary to connect MCP clients to third-party APIs ("MCP Proxy").

Understanding this distinction is critical for applying relevant security best practices. For example:

• Authentication and Authorization: While MCP leverages OAuth 2.1 for interactions between the Host/Client and the Server, the nature of the backend resource affects the overall authorization chain. A First-Party Hosted server is acting as the host of its own resources based on the authenticated identity, while an MCP Proxy server might delegate operations to a third-party API, requiring it to manage credentials (potentially Non-Human Identities - NHIs) for that third-party system . This introduces complexities in delegated authority and trust management
• Threat Modeling: Different deployment models are susceptible to different risks. A First-Party Hosted model primarily focuses on securing the direct interactions and access controls to owned resources. A Proxy model, however, introduces supply chain risks related to the third-party API and specific threats related to the proxy's management and use of credentials for that third party. Mitigations discussed in sources like the OWASP Agentic AI Threats document, such as securing tool execution and managing NHIs, need to be applied considering these specific architectural patterns.
• Principle of Least Privilege: Applying least privilege requires understanding the full chain of access. For a First-Party server, this means restricting the client's access to the server's capabilities. For a Proxy, it additionally means ensuring the proxy itself has only the minimum necessary permissions on the third-party system it interacts with.

Adding these definitions and the diagram provides essential common terminology and context, making the security considerations discussed further in the document clearer and helping implementers understand which best practices apply to their specific MCP deployment scenario.

How Has This Been Tested?

This change is purely documentation to provide clarity on architectural patterns. It does not involve code changes or require technical testing scenarios.

Breaking Changes

No

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• [x ] I have read the MCP Documentation
• [x ] My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• [x ] I have added or updated documentation as needed

Additional context

Adding this terminology helps to set the basis for further discussions on best practices.