Azure MCP Server 将 AI 代理连接到Azure服务、代表你执行工具，并通过授权每个调用的令牌代理访问Azure资源。 由于Azure MCP 服务器位于代理与云资源之间，因此必须保护AZURE MCP 服务器本身、授权访问的令牌以及流经代理的工具输入和输出。
本文提供了有关如何最好地保护Azure MCP 服务器部署的指导。
身份验证和授权
Azure MCP 服务器通过Azure标识库使用Microsoft Entra ID对调用方进行身份验证。 MCP 授权规范需要 OAuth 2.1，因此请将 Azure MCP 服务器视为 OAuth 2.1 资源服务器。 执行授权代码流时，客户端必须使用 PKCE（代码证明密钥Exchange）。 应用以下做法：
验证每个授权令牌。 在允许工具执行之前，请在每个传入授权令牌上验证颁发者、受众和到期时间。 不要信任缺少所需声明或针对其他资源颁发的令牌。
将授权令牌绑定到其预期受众。 使用受访问群体绑定的令牌，以便无法对另一个服务重播颁发的令牌。
强制实施严格的重定向 URI 匹配和每个客户端同意。 对于授权代码流，仅允许预注册的确切重定向 URI 并要求每个客户端同意，因此无法由其他客户端兑换截获的授权代码。
遵循最低特权 RBAC。 仅向每个调用方授予其任务所需的Azure RBAC 角色。 Azure MCP 服务器反映了你的Azure订阅权限 - 具有广泛订阅访问权限的调用方可以调用一组广泛的工具。 尽可能缩小角色分配的范围。 仅启用每个调用方所需的工具，因为每个可访问的工具都会添加到攻击面。
首选工作负荷标识。 在代理方案中，使用托管标识或工作负荷标识，而不是长期机密或共享凭据。 当静态凭据不可避免时（例如，不支持工作负荷标识的第三方服务的 API 密钥）将它们存储在Azure 密钥保管库中，并从部署配置中引用它们。 切勿在源代码或纯文本配置文件中存储凭据，并定期轮换凭据。
避免混淆副模式。 将Azure MCP 服务器自己的Azure标识和权限限定为运行所需的最低权限。 不要让服务器充当向低特权调用方提供广泛特权的副手：将服务器的执行标识与调用方授权分开，并强制执行每个调用方的权限检查，而不是只依赖服务器自己的凭据。
远程Azure MCP 服务器保护
将 Azure MCP 服务器部署为远程自承载服务器时，请考虑将其作为强制网关放在Azure API 管理（APIM）后面：
将Azure MCP 服务器置于强制网关后面。 APIM 可以在请求到达Azure MCP 服务器之前验证Entra ID令牌，这样就不需要应用程序代码来检查令牌。
应用网关策略进行速率限制和审核。 使用 APIM 策略来限制调用方发出请求的频率、限制允许的工具路径，以及记录每个请求以进行审核。
在单个窒息点集中访问控制。 网关提供单个阻塞点，用于跨多个下游 MCP 工具进行访问控制和可观测性。
保护Azure MCP 服务器客户端连接到的终结点。 替换的或欺骗的 URL 可以接收工具执行请求，并公开凭据或Azure资源数据。 若要降低该风险，请：
仅连接到受信任的Azure MCP 服务器终结点。 仅使用预配的终结点，或者团队通过 APIM 公开。 不要从用户提供的输入或未经身份验证的发现响应派生Azure MCP 服务器 URL。
验证AZURE MCP 服务器的 TLS 证书。 确保终结点与预期的主机匹配。 使用 APIM 时，通过网关路由客户端，以便无法以无提示方式重定向支持终结点。
证书错误时关闭失败。 将未经验证或无法识别Azure MCP 服务器证书视为连接失败，而不是绕过警告。
有关自承载选项，请参阅部署自承载Azure MCP 服务器。
本地部署强化
本地Azure MCP 服务器在开发人员环境中运行以供开发使用。 由于它可以与Azure标识一起使用，因此在将代理连接到Azure资源之前，请查看登录帐户可以访问哪些内容：
查看Azure权限。 检查分配给开发人员帐户的 Azure RBAC 角色，并删除任务不需要的广泛订阅或管理组权限。
限制本地访问。 从受信任的工作站或容器运行本地Azure MCP 服务器，并且不会向计算机上的不受信任的网络或其他用户公开本地终结点。
使本地服务器保持最新状态。 使用当前Azure MCP 服务器包和修补的依赖项，尤其是在针对非生产Azure资源进行测试之前。
沙盒本地执行。 在具有受限文件系统和网络访问的容器或沙盒中运行本地Azure MCP 服务器，并保持工具链修补，以在工具生成子进程时限制命令注入和路径遍历影响。
请勿使用本地 Azure MCP 服务器来处理生产数据或生产凭据。
工具中毒和提示注入
MCP 工具说明和工具响应是代理上下文的输入。 如果工具元数据或工具输出是恶意的，则可能会影响有权访问 Azure MCP 服务器工具和其背后的Azure权限的代理。
若要降低AZURE MCP 服务器部署的风险，
首选官方Microsoft维护Azure MCP 服务器。 将第一方Azure MCP 服务器用于Azure服务，而不是公开类似Azure工具的未经验证的服务器。 将工具架构更改视为需要评审的依赖项更改。
信任但验证工具上下文。 将工具说明和响应视为代理的不受信任的输入。 在生产使用之前查看工具定义，并验证或清理工具响应传回代理上下文的数据。
更改控制工具定义。 查看并固定已知良好的工具架构和说明，并要求在更新的工具元数据生效之前重新批准，因此服务器在审批后无法无提示地更改行为（供应链“rug 拉取”）。
使用Azure安全控制，使其适合你的体系结构。 评估Microsoft安全控制中的控制措施，以检查代理上下文、检测敏感数据流并监视Azure AI 工作负载。 在生产环境中依赖集成路径之前，请验证每个集成路径。
第三方 MCP 服务器信任
许多开发人员环境同时运行多个 MCP 服务器。 对于Azure工作，首选官方Microsoft维护Azure MCP 服务器，而不是Azure服务的社区替代项。
如果在Azure MCP 服务器旁边添加第三方 MCP 服务器：
验证发布者并更新路径。 使用来自受信任发布服务器的服务器与公共安全联系人。 在允许第三方服务器进入也可以访问 Azure MCP 服务器工具的代理环境中之前，请查看更改日志和包更新。
使凭据上下文保持独立。 不要让未经验证的服务器共享Azure MCP 服务器使用的凭据、文件系统或网络访问。 在隔离环境中运行具有最低特权的不受信任的服务器。
查看整个代理上下文中的工具。 恶意服务器可以使用其工具说明来影响同一上下文中其他受信任服务器的代理行为，包括Azure MCP 服务器。 审核配置的每个服务器的工具说明，而不仅仅是Azure工具。
治理和监视
跟踪哪些Azure MCP 服务器实例在你的环境中运行，并监视其活动：
清单批准的服务器。 维护已注册Azure MCP 服务器终结点的已知良好基线，例如使用 Azure API 中心，以便可以检测未注册的“影子”服务器，这些服务器不属于治理范围。
监视活动并保留证据。 在Microsoft Sentinel中关联Azure MCP 服务器活动，并保留Microsoft Purview审核日志，以便调查可疑的工具调用。
Microsoft安全控制
使用以下Microsoft安全服务为 Azure MCP 服务器工作负荷添加深度防御。 每个控件对特定部署的适用性取决于体系结构。 在你自己的环境的上下文中评估每个控件：
使用 Prompt Shield 检查代理上下文。 使用Azure AI 内容安全提示防护检查输入代理上下文（包括工具说明和工具输出）的内容，并检测潜在的提示注入尝试。 使用动态加载的工具元数据时，请考虑在代理管道中集成 Prompt Shields。 有关详细信息，请参阅 提示盾牌。
使用 Purview DLP 检测敏感数据流。 如果工作负荷与Microsoft Purview显式集成，请使用 Purview 数据丢失防护策略来帮助检测和标记与代理关联的数据流中的敏感数据。 任意工具调用参数的覆盖范围不是自动的 - 这取决于部署体系结构以及工作负荷使用的 Purview 连接器。 在依赖 DLP 处理代理工作负荷之前，评估特定集成路径是否支持所需的控件。 有关详细信息，请参阅 Microsoft Purview 文档。
使用 Defender for Cloud 监视 AI 工作负载。 使用 Microsoft Defender for Cloud AI 威胁防护对 AI 工作负载进行运行时威胁检测，包括有关 Azure OpenAI 中的可疑活动的警报，以及 Azure AI 模型推理服务 API 调用的警报。 覆盖范围不会自动扩展到任意 MCP 工具输出 - 它适用于体系结构中的Azure AI 服务层。 有关详细信息，请参阅 AI 威胁防护。
注释
前面列出的控件是一般Azure安全服务。 在生产环境中启用该控件之前，请验证特定Azure MCP 服务器部署体系结构是否支持每个控件的集成路径。