如何在不泄露凭证的情况下将 AI 代理连接到内部系统

¿如何在不泄露凭证的情况下将人工智能代理连接到内部工具？ 当你决定投入工作时 公司内部的人工智能代理真正的挑战不仅在于让客服人员智能化，还在于确保他们能够连接到你的内部工具，同时避免你的凭证泄露。不能在代码中嵌入 cookie，也不能通过提示以明文形式传递用户名和密码。如果客服人员需要访问 CRM、ERP、电子邮件、日历或数据库，你需要考虑…… 身份、权限和身份验证 从第一天起。

典型的应用场景很明确：您希望人工智能代理能够自动提供支持、管理工单、查阅内部文档、生成报告或在您的基础设施上执行任务。为此，它需要获取…… 内部数据源和业务服务棘手之处在于，一旦赋予它广泛且永久的访问权限，它就会变成一个自动化的“超级用户”，拥有巨大的攻击面。关键在于设计一种架构，使代理能够利用…… 临时令牌、非常有限的范围和受控渠道它依赖于 OAuth2/OIDC、MCP 服务器和密钥管理器等标准协议，而无需暴露真实凭证。

在不进行凭证过滤的情况下将人工智能代理连接到内部系统意味着什么？

将人工智能代理连接到您的内部工具意味着它可以 读取并执行操作 可以通过 CRM、ERP、工单平台、私有云或文档管理系统等系统进行操作，但始终通过定义完善的安全层进行保护。代理无需提供用户名和密码，而是使用以下方式进行操作： 访问令牌、托管会话和特定任务权限.

在此背景下，人工智能代理不仅仅是一个友好的聊天机器人：它还是一个 能够感知环境的自主软件 （日志、文档、工单、电子邮件） 原因 使用语言模型或专门模型 对工具的作用 （API、数据库、工作流）遵循安全策略。目标是通过以下方式建立与内部系统的这种关系： API、中间件、标准协议和中间服务器 防止用户或服务凭证直接泄露。

凭资质临时解决方案的风险

最常见的诱惑之一就是向代理人提供信息。 静态凭据 （用户名/密码）甚至 嵌入代码中的会话 cookie “为了让它快速运行。”短期来看，这似乎很实用；但中期来看，它就像一颗定时炸弹：没有干净利落的方法来轮换凭证、按代理撤销细粒度访问权限，或者审计谁做了什么。

当会话与代码关联时， 代币过期、无法撤销以及缺乏可追溯性 它们会将每一次集成都变成业务连续性问题。此外，任何源代码泄露、日志保护不力或代码库中的不良实践都可能导致生产环境凭据泄露。这就是为什么正确的架构需要创建…… 代理的身份验证服务与代理人本身分开，负责管理注册、续期、撤销和访问记录。

每个代理的唯一身份：起点

严肃设计的基础是将每个人工智能代理视为一个 差异化数字身份就像你不会为所有人共享同一个管理员帐户一样（或者说你不应该这样做），每个代理都应该有自己的个人资料、权限和可追溯性。

该代理身份可以用以下方式表示： 企业身份提供商 (IdP) 中的技术帐户 （例如 Okta、Azure AD、Google Workspace 等），或者通过非对称密钥和唯一标识代理的内部记录。重要的是，您可以 分配角色、范围和策略 向每位代理人记录每次呼叫的内部系统，无论他们代表的是最终用户，都要记录是谁拨打的电话。

与代理分开的身份验证：凭据“代理”。

与其将凭据嵌入代理程序中，不如在代理程序和内部系统之间放置一个[缺失的单词/短语]。 核心身份验证组件类似于专门处理人工智能代理的“会话代理”。这项服务负责：

• 问题 临时访问令牌 适用范围非常有限。
• 续会 根据各个系统的政策（例如，时间限制或不活跃限制）。
• 轮换主凭证存储在密钥管理器中。
• 注册和审计 代表代理人执行的所有操作。

采用这种方法，代理人永远不会看到实际的密码或主密钥。他们只与……合作。 按需发行的临时代币 由经纪人执行，如果检测到异常行为或代理被停用，则可以立即撤销。

安全授权的标准协议：OAuth2、OIDC 和 SSO

对于支持它的服务而言，最稳健的方法是让代理使用 OAuth2 和 OpenID Connect (OIDC) 就像其他任何现代集成一样。代理不再请求目标系统的用户名和密码，而是…… 委托流程 其中，人类用户或管理员授权代理以特定权限执行操作。

在实践中，这体现在以下方面：

• 人工操作员点击 “连接”按钮 在代理配置界面中。
• 您已被重定向至 官方提供商登录 （例如 Airbnb、Google、Slack），在代理环境之外。
• 用户登录并授予特定权限（例如，“读取日历”、“创建工单”）。
• 代理人收到 访问令牌和/或刷新令牌 虽然拥有已批准的权限范围，但从未见过实际的凭证。

这种模式也符合 单点登录 (SSO) 和联合身份用户只需通过身份提供商进行一次身份验证，代理即可使用该身份验证执行操作。 中央发行和控制的代币通过结合 SAML、OIDC 和基于角色的访问控制 (RBAC) 或基于属性的访问控制 (ABAC) 策略，您可以精细地限制每个代理可以执行的操作、从哪个网络上下文执行的操作以及可以执行的操作时长。

个人访问令牌和 API 密钥：正确使用方法和限制

在某些情况下，内部系统或第三方工具仍然依赖于 个人访问令牌（PAT） 或者使用传统的 API 密钥。虽然不如 OAuth2 灵活，但如果使用得当，它们可以成为共享密码的更好替代方案。

重要的是这些代币：

• 有 最小范围 （仅限必要许可证）。
• 包括 明确有效期防止无限期访问。
• 肖恩 轮换并存储在密钥管理器中 （例如，AWS Secrets Manager、Azure Key Vault）管理良好。
• 他们被分配到 特定代理人身份不适用于通用账户或个人账户。

再次强调，代理不应该将令牌“嵌入”到代码中，而应该在需要时从服务器请求令牌。 内部凭证服务 它会记录使用情况，并在检测到异常行为时阻止该行为。

机密管理和自动轮换

为避免在将代理连接到内部系统时泄露凭据，必须依赖于 秘密经理 功能强大。这些服务允许您存储加密的密钥、证书、密码和令牌，并提供安全的 API 以便在运行时读取它们。

在众多常见机制中，以下几种尤为突出：

• 托管云存储库例如 AWS Secrets Manager 或 Azure Key Vault，它们可以实现自动轮换、版本控制和基于身份的访问控制。
• 细粒度访问控制 通过 RBAC/ABAC 对密钥进行控制，以便每个代理只能请求他们需要的密钥。
• 主动轮换 由 CI/CD 管道和计划任务协调的代理使用的主凭证。

代理本身将凭证视为一种资源。 非持久性：根据具体情况请求这些令牌，使用它们来交换临时令牌，并且不会将它们存储在长期内存或日志中。

模型上下文协议 (MCP)：一种用于将代理连接到工具的“USB-C”接口

一种新兴且强大的方法，可以在不泄露凭证的情况下将人工智能代理连接到内部系统，就是使用…… 模型上下文协议（MCP）该协议最初由 Anthropic 公司发起，已被微软和其他公司采用，它定义了一个开放标准。 语言模型连接到数据源和工具 通过MCP服务器。

这种建筑结构由三部分组成：

• 主机 MCP：代理或模型所在的应用程序（例如，助手桌面、IDE 或企业代理）。
• MCP客户端：主机内部与 MCP 服务器通信的组件，通常通过 HTTP/S 或类似通道上的 JSON-RPC 进行通信。
• MCP 服务器：一项公开的小型服务 资源、工具和提示 以标准化的方式对外部或内部系统进行操作。

其理念是，您的内部系统（数据库、内部 Slack、企业电子邮件、SharePoint 等）通过 MCP 服务器“接入”人工智能系统，由 MCP 服务器处理 所有低级别访问权限，包括身份验证代理程序永远不会看到内部系统凭据；它只是使用特定参数调用 MCP 工具并接收过滤后的结果。

MCP 基本要素：资源、工具和提示

为了理解 MCP 如何帮助避免泄露凭据，有必要将其三个关键基本原理拆解开来：

• 资源这些资源代表只读数据，例如文件内容、数据库记录、Slack 消息、Google 云端硬盘文档或企业 API 的响应。每个资源都由一个 URI 标识，并且可以以文本或二进制形式提供。在许多情况下，用户或应用程序可以选择将哪些资源注入到模型的上下文中，从而防止代理不加区分地遍历所有内容。
• 工具这些是可执行操作（例如，“在此频道中搜索消息”、“运行 SQL 查询”、“创建工单”）。MCP 服务器使用以下方式向后端系统实现身份验证和授权逻辑： 内部令牌和密钥永远不会暴露给模型该模型只能看到工具的描述和输入/输出参数。
• 提示这些是预定义的交互模板，用于规范如何向模型请求特定任务（例如，“分析代码错误”、“总结对话”）。它们可以自动包含相关资源，但始终遵循服务器定义的规则。

采用这种方法，如果您通过 MCP 连接 ERP 或 CRM，MCP 服务器会使用 OAuth2、内部令牌或存储在您的密钥库中的密钥来协商凭据。而代理则只使用…… 描述性接口 无需直接处理任何敏感的身份验证数据即可进行操作。

MCP 的实际集成：Copilot Studio 和 Azure AI Foundry

MCP 周围的生态系统发展迅速。 Microsoft Copilot Studio例如，它已经允许您将自定义代理连接到 MCP 服务器，就像它们是预定义操作一样。代理创建者可以从控制台选择一个公开业务工具的 MCP 连接器，这些工具将自动显示在代理中，并包含其名称、描述和参数架构。

它的优点在于 Copilot Studio 可以应用 他们自己的公司政策数据控制、数据防泄漏 (DLP)、企业身份验证等。MCP 服务器则使用密钥管理器和标准协议处理针对内部服务的身份验证。同样，代理程序永远不会接触用户名或密码；它在一个经过授权的工具逻辑层中运行。

En Azure AI Foundry （以前称为 Azure AI Studio）在 Azure AI Agents 中创建的代理可以公开为 面向外侧的MCP服务器这样，兼容的客户端应用程序（包括 Claude Desktop 等助手）就可以通过 MCP 使用 Azure 代理的功能——该代理已经安全地连接到 Bing、认知搜索、SharePoint 或内部数据库。

从安全角度来看，Azure 负责 管理身份、网络、密钥和扩展您的 AI 代理只能看到授权的工具和资源，而对内部系统的实际访问凭证则保留在 Azure 和您的基础架构的受控范围内。

针对敏感操作的附加身份验证和自适应多因素身份验证

即使有了所有这些基础设施，在某些情况下，代理仅拥有有效令牌是不够的。例如： 转移资金、修改权限、删除关键记录或窃取大量数据 他们需要额外一层确认。

在这种情况下，最佳策略是结合 多因素身份验证 (MFA) y 自适应认证也就是说，该智能体可以自主执行例行任务，但是：

• 在进行高影响操作之前，请向用户询问…… 额外验证 （移动推送、一次性密码、生物识别）。
• 使用 风险触发因素 （IP 地址变更、异常数据量、异常日程安排）决定何时请求 MFA。

这样既避免了用不断的确认信息轰炸用户，又保持了…… 人体紧急制动 当代理人将要执行的操作，如果出错，将会造成严重后果时。

权限管理：最小权限原则、基于角色的访问控制 (RBAC) 和基于属性的访问控制 (ABAC)

为了方便起见而赋予人工智能代理所有权限的根访问权限，是消除重大漏洞的最快方法。权限管理应遵循以下原则： 最小特权每个代理应该只能做 正是您活动所需的。仅此而已。

通常的做法是将以下要素结合起来：

• 基于角色的访问控制（RBAC）：为代理分配一个或多个角色（例如，“支持工单阅读者”、“知识库编辑者”、“维护脚本执行者”），并明确定义权限。
• 基于属性的访问控制（ABAC）：添加上下文规则（日程安排、网络位置、资源类型、数据分类），动态调整代理可以执行的操作。

此外，保持……至关重要 详细记录 每次工具调用和每次资源访问都会被追踪，并由代理甚至代表其行事的最终用户进行标记。这种可追溯性使得这一切成为可能。 审计和属性操作 以应对可能发生的事故，并证明符合监管规定。

MCP 服务器和代理特定身份验证产品

一些平台正在涌现，旨在简化代理的身份验证层，充当…… “面向人工智能的CIAM”有些解决方案以 MCP 服务器集合的形式呈现，支持数十种流行的 SaaS 和服务，提供标准化的 OAuth 流程、PAT 和 API 密钥，供代理连接而无需直接管理凭据。

另一方面，身份识别产品，例如 标识 它们提供集成的身份验证和授权功能，支持 OAuth2、SAML、JWT 和 API 密钥，旨在服务于两者。 传统SaaS应用以及基于AI代理的产品通常的模式是：

• 将代理人注册为 顾客 在身份系统内。
• 管理 用户和会话 与代理交互。
• 问题 签名令牌 包含角色和属性信息，后端可以在不暴露敏感数据的情况下进行验证。

这样一来，即使您的代理连接到多个 MCP 服务器或 API，整个层级的人员构成和权限控制也可以从单一点进行控制。 共同身份的核心当您开始部署数十个具有不同功能的代理时，这非常有用。

安全连接内部数据：网络、分段和加固

并非所有安全都依赖于令牌和协议的逻辑层。当部署人工智能代理时…… 在您的企业网络内网络架构和加固也需要加以考虑， 提高网络稳定性尤其是当涉及到没有互联网连接的本地人工智能模型和服务器时。

一些实用指南：

• 使用VLAN进行网络分段将用户网络与 AI 服务器网络、管理网络以及（如果适用）访客网络隔离，并在它们之间设置非常严格的防火墙规则。例如，聊天机器人的 VLAN 可以接收内部请求，与其数据库和 Active Directory 通信，但 没有互联网接入.
• 默认阻止的防火墙仅允许明确必要的流量（机器人 API 端口、数据库、LDAP、管理员 SSH）。所有其他流量均被拒绝，尤其是 AI 服务器与外部的任何连接。
• 企业认证将用户对聊天机器人的访问权限与 Active Directory 或 LDAP 集成，根据用户的组和角色控制谁可以使用聊天机器人以及他们可以看到什么。

通过将这种方法与应用层身份验证和授权机制相结合，即可实现这一点。 即使攻击者攻破了代理的模型或代码但是，它们跳转到其他系统或将数据泄露到互联网上的能力受到了极大的限制。

AI代理的监控、数据防泄漏和事件响应

由于智能体做出的是非确定性决策，并且可能会遇到恶意提示或数据，因此拥有以下能力至关重要： 深度可观测性 了解他们的行为。仅仅知道他们调用了 API 是不够的：我们需要了解 他们当时所处的背景是什么？他们为什么会采取特定的行动？.

相关措施包括：

• 完整记录 交互信息：提示、调用的工具、参数、响应、错误和用户上下文。
• 与 SIEM 集成 (Splunk（例如 ELK、Wazuh、Graylog 等）将代理活动与一般安全事件关联起来。
• DLP规则 AI 特有功能：过滤响应中的敏感数据（卡片、身份证、密码、令牌、机密信息），阻止不当内容或编辑关键部分。
• 自动响应机制 如果出现大规模数据提取尝试、可疑查询或偏离模式的行为，包括暂时阻止代理或要求额外的 MFA。

可观测性和主动控制的结合降低了人工智能成为……的可能性。 内部威胁加剧这样，如果由于模型漂移、提示注入攻击或设计错误而出现问题，您可以快速做出反应。

通过正确集成所有这些要素——独立的代理身份、会话代理、OAuth2/OIDC、MCP、密钥管理器、分段网络、监控和数据防泄漏——就可以构建真正与您的内部系统集成的 AI 代理。 具备足够的能力来自动化关键流程，同时始终保护凭证、调整权限并实现完全可追溯性。这样一来，代理就不再是一种冒险的实验，而是成为企业安全和业务架构中可靠的组成部分。