本文探讨了企业AI智能体安全的新范式。作者认为安全不应只是一个静态的门禁关卡，而应贯穿于观察、执行、构建和部署的持续全生命周期中。企业需要在行动级别实施授权，将安全性内置于智能体架构，在确保安全的同时释放AI的生产力。
译自：AI agent security is a lifecycle — not a gatekeeper
作者：Greg Vesper
企业安全传统上建立在一个相对简单的基础之上：建立身份、对请求者进行身份验证、确定该身份可以访问的内容，并强制执行这些权限。
AI智能体引入了一个根本性的复杂问题。它们不仅仅是访问系统。它们解释目标、选择工具、创建子智能体、做出决策并执行操作，通常使用从人类继承的凭据和权限。
问题不一定在于智能体缺乏适当的凭据。而在于这些凭据可能会授权执行人类从未打算让智能体执行的操作。而且与传统软件不同，智能体为了追求目标可以动态改变其执行路径。
“问题不一定在于智能体缺乏适当的凭据。而在于这些凭据可能会授权执行人类从未打算让智能体执行的操作。”
这产生了一个新的运营要求：安全不仅必须评估谁或什么在行动，还必须评估智能体试图做什么、受谁的授权以及在什么策略下。满足这一需求需要的不仅仅是一个安全检查点。它需要一个持续的智能体安全生命周期。
纵深防御需要行动级别的授权
每一天过去都进一步表明，智能体安全是一个纵深防御问题。网络安全控制智能体的通信方式。端点和运行时保护限制代码的执行位置和方式。基础设施和基于硅片的保护为可信执行奠定了基础。模型护栏有助于塑造行为。这些层相辅相成，企业需要它们协同工作。
但考虑这样一个智能体：它试图使用开发人员的合法凭据删除生产数据库。网络控制可能会看到授权流量。运行时可能会看到一个批准的进程。身份提供商可能会确认凭据有效。这三者都可以按设计正常工作。
缺失的问题是：是否应该允许这个特定的智能体执行这个特定的操作，即使它继承了其凭据的人类可以合法地这样做。
这需要在行动点进行身份上下文和授权。
在实际操作中，授权决策应考虑智能体的身份、委派其权限的人类或服务、请求的操作、目标资源以及适用的策略。在操作执行之前强制执行该决策。
智能体 harness（将AI模型连接到工具、应用程序接口 (API)、文件和外部系统的执行层）是应用该控制的重要场所。其他受信任的执行点，包括工具服务和资源API，提供了额外的保护。
目标不是取代现有的防御。而是使授权成为智能体执行不可或缺的一部分。但即便如此也只是部分答案，因为所需要的是一个新的框架——智能体安全生命周期。
四大纪律，一个持续的安全生命周期
一个实用的智能体安全架构需要四个相互关联的纪律：
观察。执行。构建。部署。
这些不是每个组织都必须通过的顺序关卡。它们形成了一个持续的生命周期，组织可以从反映其现有基础设施和成熟度的任何一点切入。
已经在生产环境中运行智能体的公司可以从观察其行为开始。创建新智能体的开发团队可以从直接将授权构建到其架构中开始。扩展现有部署的企业可能会发现需要重新审视其策略的新活动。
每个阶段都为其他阶段提供信息。这个循环从未真正结束。
观察：了解智能体实际做了什么
大多数企业某种形式的应用资产清单。他们越来越多地将该资产清单扩展到AI智能体。
这是一个有用的起点，但知道智能体存在并不等于理解它的功能。
安全团队需要对智能体实际尝试的操作保持可见性：
- 正在调用哪些工具和API？
- 正在执行哪些命令？
- 正在访问哪些系统和敏感资源？
- 正在使用哪些凭据和委派权限？
- 正在创建哪些子智能体，它们继承了什么权限？
- 哪些操作会违反拟议的安全策略？
仅凭架构图或智能体配置文件无法可靠地回答这些问题。重要的证据存在于执行中，这就是为什么智能体可观测性必须延伸到传统日志和应用程序监控之外。安全团队需要将观察到的操作与身份、委派和授权上下文连接起来。
“知道智能体存在并不等于理解它的功能。你无法智能地治理你未曾观察到的行为。”
同样重要的是，观察应该支持评估潜在策略，而不会立即中断生产活动。这里有有用的先例。当入侵防御系统和Web应用程序防火墙被广泛采用时，组织了解到立即启用积极的阻止规则可能会中断合法应用程序。先监控、建立行为基线并逐步强制执行策略被证明更切实可行。
AI智能体需要类似的纪律，尽管它们的行为可能要动态得多。
对于已经部署智能体的组织来说，首要任务可能不是阻止更多活动。而是了解实际发生了什么活动。
你无法智能地治理你未曾观察到的行为。
执行：围绕概率行为设置确定性边界
一旦组织了解了智能体的行为，他们就可以开始定义和强制执行边界。
概率性AI行为与确定性安全执行之间的区别至关重要。智能体在不同的执行过程中可能会对指令有不同的解释。它可能会选择不同的工具、对操作进行不同的排序，或者发现实现目标的替代方法。
安全策略不能依赖于模型始终如一地选择最安全的选项。考虑一个被允许在源仓库中工作的编码智能体。读取文件可能是允许的。修改受保护的分支可能需要人工批准。删除仓库可能是被禁止的。所有这三个操作都可以源自运行在相同环境中的同一个经过身份验证的智能体。但它们需要不同的授权决策。
“概率性AI行为与确定性安全执行之间的区别至关重要。目标不是让智能体失去行动能力。而是让其权限边界明确、可执行且保持一致。”
有效的执行意味着在执行前根据策略评估尝试的操作。一个简化的授权请求可能包含：
- 主体： 编码智能体 42
- 委派权限： 开发者账号 17
- 请求操作： 删除仓库
- 目标： 生产源码仓库
- 策略决策： 拒绝
重要的架构区别在于，权限检查发生在受信任的执行点，而不仅仅是在指示模型行为的提示词中。对于高风险操作，系统可能会拒绝执行或需要明确的人工批准。较低风险的操作可能会自动进行。
执行还需要考虑尝试替代执行路径的智能体。harness级别的检查仅保护通过该harness路由的操作。因此，强大的设计将行动级授权与API、工具服务和底层资源上独立执行的权限结合起来。
目标不是让智能体失去行动能力。
而是让其权限边界明确、可执行且保持一致。
构建：将身份和授权纳入智能体架构
观察和执行帮助组织保护现有智能体。但当这些经验影响智能体的构建方式时，将带来最大的长期利益。
今天，开发人员可能会使用不同的模型、框架、工具协议和执行环境来实施AI智能体。如果每个团队必须独立设计身份传播、委派权限、授权策略和审计日志，安全就会变得不一致且难以维护。
相反，这些功能应该作为可重用的基础设施提供。软件开发工具包 (SDK)、API和共享授权服务可以更轻松地将控制直接纳入智能体应用程序中。这意味着从一开始就建立几个架构期望。
智能体应该具有可识别的执行上下文。其权限应明确委派和约束。敏感工具调用应要求授权。安全决策和重大操作应该是可审计的。
重要的是，智能体不应该自动继承发起它的人类可用的所有权限。考虑一个使用AI助手核对发票的员工。该员工可能拥有查看发票、批准付款和更新供应商记录的权限。智能体分配的任务仅需要检索和核对发票。正确的架构委派该任务所需的权限，而不是员工的全部权限。
当智能体创建子智能体或在不同服务身份下调用工具时，这种区别更加重要。开发人员需要机制在这些交互过程中保留和约束委派的权限。
安全还应该在不同的实现之间保持可移植性。每当开发团队采用新框架或模型时，组织都不必重建其授权架构。这就是为什么身份和授权应该是基础设施，而不是特定于应用程序的功能。
如果做得对，安全就会成为开发人员构建时的工具，而不是安全团队在应用程序完成后试图生搬硬套的东西。
部署：在机器规模下实现一致的安全
构建安全智能体是一个挑战。在应用程序、部门、云环境和业务流程中运营数千个智能体则是另一个挑战。在这种规模下，手动审查权限或信任各个开发团队来一致地实施控制是不可持续的。
智能体可能会调用新工具、与其他智能体协同，并参与跨越多个授权域的工作流。安全控制需要跟随它们。这需要一个部署架构，在支持的环境中持续应用身份上下文、委派权限、授权策略和审计要求。
底层模型或框架不应决定安全控制是否存在。采用新工具也不应要求重建整个安全架构。这就是与框架无关的接口和集中管理的策略变得特别有价值的地方。组织可以保持一致的安全期望，同时允许开发团队使用最适合其应用程序的技术。
部署也改变了规模的含义。对于传统应用程序，规模通常意味着处理更多的用户、事务或工作负载。对于智能体，规模还可以意味着更多的独立行动者做出更多的决策、调用更多的工具并创建更多的智能体。重大操作的数量可以比部署的应用程序数量增长得快得多。因此，安全架构必须以机器生成活动的速度自动且一致地运行。
部署创造了另一件事：新证据。生产活动揭示了意外的工作流、新的依赖项、授权差距以及完善策略的机会。这些信息直接反馈到观察和执行中，并为下一代智能体的构建提供参考。
生命周期仍在继续。
从作为检查点的安全到作为基础设施的安全
底层安全原则并不新鲜。最小权限、零信任、职责分离、身份联合和纵深防御依然是基础。
正在改变的是，这些原则必须在智能体的整个生命周期中以多大的一致性应用，以及执行必须离智能体采取的行动有多近。传统的安全架构通常假设控制系统访问足以管辖之后发生的事情。
AI智能体挑战了这一假设，因为它们可以在已授予的访问权限内独立做出重大决策。因此，安全模型需要从三个重要方面进行演变。
首先，可见性必须基于实际的智能体行为，而不仅仅是配置。
其次，授权必须在身份、委派和策略的上下文中评估单个行动。
第三，这些功能必须成为可重用的基础设施，伴随智能体从开发到生产再回到持续改进的全过程。
这就是为什么将智能体安全视为一个生命周期，而不是一组孤立的控制至关重要。观察提供证据。执行建立边界。开发将这些边界并入应用程序中。部署在环境中持续扩展它们，并将新证据反馈到循环中。
每个阶段都使其他阶段更加有效。
在不放慢速度的情况下保护智能体时代
组织面临两个诱人的极端。一个是过分信任智能体，假设合法的凭据和编写良好的指令提供了足够的保护。另一个是将智能体约束得如此激进，以至于推动其采用的生产力收益消失了。两者都不是可持续的长期策略。
“成功的衡量标准不是组织可以阻止多少智能体操作。而是它可以自信地（且安全地）启用多少有价值的操作。”
更好的方法是建立使更大自主权成为可能的可见性、问责制和控制。这意味着了解智能体实际做了什么、强制执行允许它们做什么、将这些控制构建到开发流程中，并在规模上一致地部署它们。这也意味着认识到这项工作永远不会完成。新模型、框架、工具和工作流将不断引入新的行为和风险。
智能体安全不能是部署开始时的一次性批准。它必须是与智能体本身共同演进的持续纪律。成功的衡量标准不是组织可以阻止多少智能体操作。而是它可以自信地（且安全地）启用多少有价值的操作。
它需要一个持续的生命周期，而不是一个守门人。
