一项政策，数千个智能体：为何企业级 AI 治理在规模化时会失效

关于采用自主式 AI 智能体的讨论，大多聚焦于治理这一关键挑战，而且这确实有其道理。Gartner 最近预测，40% 的企业将在 2027 年前降级或停用其自主式 AI 智能体——并非因为技术失败，而是因为治理失灵。Gartner 高级总监分析师 Shiva Varma 指出，问题根源在于“二元治理”：把智能体视为要么完全封锁，要么完全信任，二者之间没有任何中间地带。

目前，许多组织要么倾向于全面禁止使用 AI 工具，要么部署缺乏充分防护措施的智能体。这两种做法都难以有效扩展。即使 IT 部门禁止使用外部 AI 工具，影子 AI 仍然会出现。开发者自然而然地希望构建产品、解决问题；如果治理流程显得过于官僚，他们就会绕过管控措施，使用未经测试的工具来推动工作。相反，防护措施不足会使组织面临安全、合规和运营风险，而这些风险会随着时间推移不断累积。

挑战在于，AI 智能体无法采用统一方式进行治理，也不能依靠静态、适用于所有情况的方法。千篇一律的治理时代正在结束，因为这些系统的风险状况并不相同：它们在底层软件、功能、访问权限和自主程度方面各有差异。将工业时代的静态管控措施应用于以机器速度运行的软件，行不通。有效的治理取决于组织能否了解每个智能体背后的软件供应链，并根据其引入的风险采取相应的管控措施。

治理智能体软件开发环境

真正的管控意味着有效管理构成智能体的所有软件要素。许多团队错误地将这些智能体视为“可靠且值得信赖”，忽略了影响其功能和安全性的标准组成要素。

每个自主式 AI 智能体都由一套常见的技术栈构建而成：基础模型、用于将其连接到公司数据和外部系统的 MCP 服务器（模型上下文协议）、用于扩展其功能的插件，以及用于指示其行为方式的技能文件。IT 负责人需要牢记以下几点：

• AI 智能体是软件生态系统：它们依赖一套标准配置，其中包括模型、MCP、工具、插件、技能和开源软件。
• MCP 服务器可能存在风险：它们将智能体连接到公司数据，也可以像其他软件一样下载。如果未经审查，黑客就可能借此侵入你的系统。例如，JFrog 最近的安全研究揭示了这些确切的软件供应链风险存在于mcp-run-python之中，其中包括 服务器端请求伪造（SSRF）漏洞（CVE-2026-25904）以及 隔离不足漏洞（CVE-2026-25905），这些漏洞可能导致整个 MCP 遭到全面接管。
• 插件会带来更多风险：不同的智能体需要不同的插件（例如，OpenAI 插件无法用于 Microsoft Copilot），这意味着公司往往要同时管理多个版本，而其中一个有问题的插件就可能窃取敏感信息。
• 技能决定智能体的行为：这些指令文件会告诉智能体如何工作。由于开发者会从社区渠道获取这些文件，遭到篡改的技能可能会悄然改变智能体的运行方式。
• 开源软件风险：使用智能体式编程构建的解决方案，其全部功能都建立在借助开源二进制文件实现功能的基础之上。编程智能体完全可能利用恶意软件包而非安全软件包，而且不会意识到其中的风险。
• 可见性至关重要：许多团队不知道这些问题的存在，导致其智能体极易受到攻击。组织仍在依赖信任而非全面检查来管理软件依赖项。

权威记录系统在有效 AI 治理中的作用

以昨日的思维方式，无法赢得部署企业级 AI 智能体的竞赛。在每个工作流程中都设置笨重、严苛的人工审批链，会扼杀创新；而放任智能体不受监控，则会带来不必要的风险。

为了安全地扩大 AI 应用规模，组织必须采取分层方法，对软件组件进行治理和保护，包括软件包、二进制文件、MCP、技能和依赖项。通过建立权威记录系统，企业可以整理所使用的所有组件、在使用前扫描所有内容，并在开发生命周期的恰当时机执行策略，同时保留立即回滚的能力。因此，当下一个漏洞披露时，对于“我们是否受到影响？”这一问题，答案几分钟内就能给出，而无需等上几天。

然而，AI 智能体带来了更广泛、变化速度也显著更快的攻击面。高度自主的智能体每分钟可以做出数百次决策，串联调用工具、访问数据和执行代码，其速度快到传统的准入管控难以跟上。尽管前期审查和审批流程仍然发挥着重要作用，但仅凭这些措施，无法保护以机器速度运行的系统。

这些智能体需要在运行时实施动态管控，能够在异常行为发生的瞬间将其检测出来，并在损害扩散之前采取干预。可以把它想象成断路器：一旦出现问题，立即撤销对已遭入侵技能的访问权限、断开不可信的数据上下文，或阻止特定的工具调用。

摆脱“一刀切”

僵化、统一的治理方式注定会失败。抢占先机的窗口正在关闭，而随着智能体部署加速，治理欠账也在不断累积。因此，安全和工程领域的负责人现在可以采取以下四个步骤，帮助加固企业系统：

1. 盘点当前已在运行的内容。大多数企业都无法全面掌握组织内有哪些 AI 智能体，更不用说为其提供支持的 MCP 服务器、插件和技能文件了。在评估风险或实施治理之前，必须先弄清楚现有的内容。
2. 将 AI 组件视为软件制品。MCP 服务器、技能文件和插件不是配置项，而是代码，面临着与任何开源依赖项相同的供应链风险。应像审查任何第三方库那样，对它们进行审查、扫描并追踪其来源。
3. 根据智能体的自主程度对其分类，并相应调整管控措施。明确“高度自主”对组织而言意味着什么，并据此建立分级政策框架。高度自主的智能体需要运行时管控，而不能只依赖准入检查。从最敏感的系统着手，再逐步扩展到其他系统。
4. 让治理足够快捷，避免开发者（无论是人类还是智能体）绕开它。影子 AI 的问题在于流程摩擦。如果审批一台新的 MCP 服务器需要两周，开发者就会另寻他法。只有通过自动扫描并明确执行政策，才能跟上 AI 开发的实际速度，实现规模化扩展。

如果治理能够反映每个智能体带来的实际风险，而不是一概而论，其成效就会大幅提升。能够脱颖而出的企业，将是那些根据每个智能体的实际情况实施相应治理的企业，并以一套权威记录系统为支撑，在每个边界执行政策、全面掌握每个组件，并让团队能够在问题发生时立即响应。