企业AI智能体安全：身份验证只是起点
根据VentureBeat在6月的研究发现，仍有69%的企业正在运行使用共享凭证的AI智能体，这种做法与更高的安全事件和准事件发生率相关联。
但在VB Transform 2026大会上，NTT DATA AIVista的首席技术官Mukesh Karki和Snowflake的首席安全与信任官Mayank Upadhyay认为，修复身份验证只是第一步。企业还需要在每个智能体交互中构建基于操作级别的授权和防篡改审计轨迹，以便大规模安全地部署自主系统。
“这些组织需要以非常防篡改的方式向审计人员证明，那些记录他们所做行为的记录确实证明了他们的实际操作，”Karki表示，”这种可证明性本质上是在监管环境中运营的许可证。”
共享凭证为何引发AI智能体安全事件
Upadhyay表示，问题在于许多假设沿袭了早期软件时代的做法。
“在传统软件世界中，人类点击某个地方，软件执行非常确定性的操作，你知道它会调用哪个API，”他说，”但在智能体世界中，软件有自己的’大脑’，并且不断自我重组。如果给这个软件超出特定目标的必要权限，智能体本质上是探索性的，它们会尝试各种不同的方法，从而产生意外副作用。”
他补充道，嵌入单个静态API密钥会加剧这种风险暴露。
“如果你有一个API密钥，把它塞入智能体中，让它以任何人身份与特定的SaaS服务通信，这是一种非常糟糕的模式，因为你给了这个智能体所有需求的集合权限，”他说，并指出第二种失败模式是取证方面的，因为”事情可能出错，而你无法将其归因于正确的智能体。”
在监管行业中，范围凭证只是起点
Karki的客户大多来自保险、医疗和金融行业，他将范围凭证视为基本要求。
“在监管环境中，没有广泛范围和共享范围凭证的智能体根本无法运行，”Karki表示，”拥有范围凭证只是一个起点。实际上存在两层约束：一是智能体运行的司法管辖区，二是该组织的司法管辖区或规则。”
例如，他在补充说，华盛顿州的理赔调整智能体与加利福尼亚州的智能体遵循不同的监管规定，而且每项理赔都各不相同。
“这些范围凭证是不够的，因为必须在智能体执行操作时基于操作和规则，”他补充道。
将AI智能体比作员工的局限性
Karki认为，将智能体比作员工的类比只能解释部分情况。智能体仍需要学习组织的独特背景，就像新员工一样。但与人类不同，企业无法在合理时间内与数千个智能体建立信任关系。
“在一个组织中表现优秀的员工在另一个组织可能不是最佳员工，不是因为他们的能力变差了，而是因为他们没有新环境的背景，智能体也是如此，”Karki说，”如果每个员工有100个智能体，你不能说你将入职这些智能体并对它们进行背景调查。”
Upadhyay表示，将智能体比作员工应该在组织层级中低一个等级。
“将它们视为实习生，”他建议，”它们有良好的意图，但不总是知道自己在做什么，你必须密切关注它们，同时逐渐建立信任。”
在Snowflake平台上，管理员可以实施平台范围的防护措施，如只读操作，而开发人员在启动每个会话时可以进一步缩小智能体的权限范围。
AI智能体治理的三层方法
Karki表示，毫无疑问治理应该位于何处。
“治理必须发生在每个智能体操作中，并且必须位于智能体之外，”他解释道，”只有这样，你才能日后证明智能体执行了其被允许执行的操作。”
Upadhyay将治理分为三层：
- 智能体层：涵盖身份验证、工具权限和MCP治理。
- 模型层：解决间接提示注入问题，并使模型能够在客户的VPC中运行，从而提示对模型提供商保持不可见。
- 数据层：涵盖最小权限访问、零拷贝架构和基于角色的访问控制。
智能体要正常工作，需要在所有三层都实施治理。
企业应首先审计哪些内容
对于正在审计现有AI智能体治理的企业，Upadhyay建议从两个地方开始。首先是审计静态密钥的权限，这是最大的可修复攻击向量。其次是通过MCP网关解决影子AI问题，这样开发人员不再需要在办公桌下运行非法的开源MCP服务器，管理员也能看到谁在与哪个MCP服务器通信。
约束与能力之间存在权衡，这可以在任务级别上解决，使用置信度评分来抑制高风险操作的自主执行，沙盒作为中间路径。但Karki提醒已经扩展其智能体系统的企业。
“很多在你拥有智能体系统运行后无法进行改装，如果你必须向审计人员解释智能体为何以特定方式行事，改装会更加困难，”他解释道，”可证明性必须在设计系统时从底层构建。”
关注微信号：智享开源 ，及时了解更新信息。
公众号：智享开源
还没有任何评论，你来说两句吧！