企业 AI 智能体治理正从政策转向运行时控制
企业 AI 智能体治理已跨越首个运营边界：仅靠政策文件，无法约束能够独立执行现实世界操作的软件。新兴模式将控制机制前移至智能体发送数据、修改记录、调用工具或支出资金之前的关键时刻。
这一转变构成了近期行动点治理观点背后的核心论点。治理不再只关乎批准模型、记录其风险，或在部署后审查其输出；它正在成为一个运行时安全问题。
压力落在安全团队、身份服务提供商、应用所有者，以及每一家构建智能体平台的供应商身上。矛盾十分明确：企业希望智能体以更少监督完成更长的工作流，而安全团队则需要确保每项重要操作都可追溯、可撤销。
这并非又一场关于人工智能是否需要规则的争论。更紧迫的问题是，这些规则应在何处运行。对于自主系统而言，答案正越来越接近具体行动本身。
企业 AI 智能体治理发生了什么变化
被治理的对象不再只是模型或应用，而是一个拥有工具、记忆、权限和不断变化上下文的行动身份。
传统 AI 监督聚焦于相对稳定的流程：用户提交输入，模型生成输出，再由他人审阅或使用该输出。治理可以审查模型、训练数据、预期用途、评估结果和生成内容。
AI 智能体改变了这一流程。它可以将目标拆分为多个步骤，选择工具、检索信息、调用外部服务并修改系统。它还可以不断重复这一过程，直到认为目标已经完成。
每一步都可能改变下一步的风险。汇总客户反馈这一看似无害的请求，在智能体打开客户数据库后会变得更敏感。如果它进一步导出记录、起草消息，或未经审核直接发送消息，风险还会继续变化。
这在设计阶段的批准与运行时行为之间造成了缺口。治理委员会可以批准一个用于销售支持的智能体，但这一标签对某个具体数据库查询的说明很有限。它也无法判断，是否应在凌晨 2 点通过高管账户发送某一封特定邮件。
NIST AI 框架为组织治理、映射、衡量和管理 AI 风险提供了广泛的结构。这一结构依然有用，但智能体迫使团队以更精细的粒度落实其原则。
附加于整个应用的风险分类，无法回答每一个运行时问题。系统必须知道谁发起了任务、哪个智能体正在行动、它访问了什么数据，以及选择了哪种工具。系统还必须了解，请求的操作是否超出用户权限。
这就是行动点治理的实际含义：控制机制依据当前的身份、权限、数据和环境信号，评估一次尝试执行的操作，随后允许、阻止、限制或升级处理该操作。
该控制机制可能要求资金流转前先获得人工批准；可能在信息送达模型前，对敏感字段进行脱敏；也可能阻止智能体向外部地址发送邮件，即使同一智能体可以创建内部草稿。
这些决策必须在执行期间做出。季度政策审查无法中断一次危险的 API 调用。部署后的审计可以解释事故，却无法阻止最初的操作。
这一转变也改变了证据的定义。组织需要的不只是表明某个智能体已获批准的记录，还需要将原始请求与模型决策、工具调用、检索数据、审批过程及最终结果关联起来的日志。
当智能体跨多个服务运行时，这条链条尤为重要。一个工作流可能从聊天界面开始，检索合同、更新客户记录，并创建付款请求。每一次转换都会产生新的权限扩张或上下文丢失风险点。
行动点治理将这些转换视为安全边界。这种方法并不假设已获批准的智能体在整个工作流中始终安全，而是验证每项重要操作是否仍符合最初目的和被授予的权限。
为什么静态 AI 政策会在运行时失去控制
书面政策描述可接受的行为，但自主工作流需要在每个重要步骤之前作出可执行的决策。
静态治理在系统行为可预测时最为有效。团队可以定义获准用途、禁止敏感输入、测试固定工作流，并培训员工。但当智能体自行选择穿过互联工具的路径时，这些措施的可靠性就会下降。
智能体可能以获准目标开始，却仍产生不被允许的操作。它可能误解指令、遵循从文档中检索到的恶意内容，或组合多项单独看来无害的权限。由此产生的能力可能超出任何单项权限所暗示的范围。
提示词注入说明了这一问题。敌对指令可能出现在智能体检索的网页、电子邮件、文档或支持工单中。内容会要求智能体忽略原始目标、泄露信息，或激活另一项工具。
传统过滤器可能检查用户最初的提示词，却发现没有危险内容。有害指令是在工作流已经开始后才进入。因此，治理必须跟随智能体在其上下文变化中的全过程。
OWASP 智能体指南描述了与过度自主权、工具滥用、记忆操控、级联故障和受损智能体交互相关的风险。这些是执行风险，而不只是令人不满意的文本输出。
当智能体获得超出任务所需的权限时，就会出现过度自主权。日程助理可能需要读取日历并建议会议时间，但通常不需要不受限制地删除事件、邀请外部参与者，或读取所有私人附件。
在工作流变得动态后，这一区别听起来简单，实践中却并非如此。智能体可能确实需要为某项任务临时扩大访问权限，但不应将其用于其他任务。永久的广泛权限解决了运营问题，却形成了持续存在的安全暴露面。
运行时控制提供了另一种方法。系统可以在评估任务及其上下文后，发放范围狭窄、时效有限的授权。该授权可在一次操作后失效，或在请求范围变化时要求批准。
同样的原则也适用于数据。准备季度摘要的智能体可能需要汇总后的收入信息，却不需要每位客户的个人记录。靠近数据源的控制机制可以在模型看到数据之前，限制智能体能够检索的内容。
这很重要，因为模型层面的防护措施只是其中一层。可以要求模型不泄露敏感信息，但指令可能冲突或失效。数据最小化和工具授权能够在模型行为变得不可靠时降低后果。
运行时方法还将低风险推理与高风险执行分离。智能体可以分析选项、起草建议并模拟操作，而无需获得执行操作的权限。只有当工作流到达受控边界时，权限才会被授予。
人工审批依然重要，但不能成为万能答案。要求每次工具调用都经过审批，会削弱智能体承诺带来的大部分效率，也可能导致审批疲劳，使人们在未审查上下文的情况下接受请求。
良好的治理会将干预保留给具有实质影响的阈值。读取公开产品页面可以自动进行；导出客户记录、修改生产代码或发送资金，则应触发更严格的检查。
具体边界取决于组织和任务。不过，机制始终一致：评估操作、其目标、发起者以及潜在影响，然后施加足以让合法工作继续进行的最小权限。
NIST 发布的生成式 AI 概要强调，应在整个 AI 生命周期内管理风险。智能体系统则将这一生命周期延伸为一连串能够立即产生现实影响的决策。
因此，治理变得不那么像发布一本规则手册，而更像运行一个授权系统。政策仍然定义应当发生什么；运行时控制则将这些政策转化为在后果成为现实之前作出的技术决策。
身份成为 AI 智能体的控制平面
智能体需要独立、可追溯的身份，因为借用员工凭据会抹除责任归属，并削弱所有下游控制。
许多早期智能体通过人类用户现有账户运行。智能体继承会话、API 令牌或服务凭据。这种设计让原型更易构建，却会在调查和访问审查中制造模糊性。
系统日志可能显示某位员工下载了文件，却无法表明是该员工点击下载、获批准的智能体进行了检索，还是受损工作流通过其账户执行了操作。授权记录中缺少真正的行动者。
独立的智能体身份可以解决部分问题。它让管理员能够向智能体分配权限、监控其行为，并在不禁用人类发起人的情况下撤销其访问权限。它还允许政策区分人类操作与机器操作。
该身份仍必须关联到负责的个人或业务流程。否则，组织会创建不断增加、却没有明确所有者的机器账户群体。休眠智能体可能在原始项目结束很久后仍保留访问权限。
Microsoft 将 Agent ID controls定位为用于发现、治理和保护智能体的身份层。这一方向反映了更广泛的行业结论：智能体需要与其他非人类身份相当的生命周期管理。
发现是第一步，因为安全团队无法治理他们看不见的智能体。业务部门可以在软件平台、低代码系统、开发框架和云服务中创建智能体。每一种途径都可能产生新的身份、令牌或集成。
注册过程应记录智能体的所有者、用途、环境、获准工具和预期数据访问范围，还应记录智能体是否可以自动行动，或是否需要确认。这些属性为运行时系统提供了授权依据。
身份验证回答调用方是否为已注册的智能体。授权则回答该智能体能否在当前条件下执行这一操作。当团队只解决第一个问题，却为第二个问题授予广泛且持久的访问权限时，治理便会失效。
上下文能让授权更精准。策略可以审查请求用户、设备状态、数据分类、目标位置、交易金额以及近期代理行为，并据此施加不同控制，而无需重新定义整个代理。
在正常工作期间，助手可以读取员工自己的会议记录。但当同一请求指向其他部门的受限文件时，就应受到更严格的审查。突发的大批量下载，也应与获取单份文档区别对待。
记忆带来了另一类身份问题。代理可以存储任务历史、偏好、检索到的事实和中间决策。这些记忆可能在原始用户会话结束后仍然持续存在，并影响后续针对其他请求的操作。
团队需要明确哪一身份拥有这些记忆，以及谁能够修改它们。他们还需要溯源信息，即记录存储信息来自何处以及如何发生变化。没有溯源信息，被污染的记忆可能会在不被察觉的情况下改变后续工作流的方向。
知识系统若能保留来源边界和访问控制，就能支持更安全的检索。当代理仅获得其当前请求者有权访问的文档时，工程知识库最具价值。
多代理工作流使身份问题更加重要。一个代理可能将研究任务委托给另一个代理，再让第三个代理更新系统。接收服务必须知道，委托授权是否在这条链路中始终有效。
委托不应意外产生新的权限。如果第一个代理无权批准付款，被委托的代理也不应获得这项能力。每一次权限传递都应保留原有的限制、用途和有效期。
这一要求与身份安全领域的既有理念相似，但代理带来了不同寻常的速度和规模。一名员工可能在一次会话中执行若干敏感操作；而自动化代理可在审核人员察觉之前，跨多个系统发起大量操作。
因此，控制平面必须将身份与速率限制、行为监控和交易策略相结合。身份告诉组织是谁采取了行动；运行时治理则决定该主体是否应被允许继续操作。
行动时控制也会带来自身的权衡
运行时强制执行可减少不受约束的权限，但也会引入延迟、策略复杂性、集成风险，以及攻击者可能瞄准的新控制点。
治理论证最强的版本听起来可能具有欺骗性的完备性：为每个代理赋予身份，评估每项操作，记录每个决策，并对危险操作要求审批。但在实践中，每一个组成部分都可能失效。
策略质量是首要限制。运行时引擎无法执行团队尚未转化为精确规则的意图。“敏感”“适当”“重大”或“可信”等术语，往往需要因部门而异的业务判断。
规则过于宽泛，会让危险操作仍然可行；规则过于严格，则会打断正当工作，并促使员工绕过系统。组织必须根据真实工作流调整策略，而不能只依赖抽象的风险类别。
上下文也可能不完整。安全服务或许能看到 API 请求，却不了解产生该请求的对话。模型网关或许理解提示词，却缺乏关于目标系统数据分类的信息。
攻击者可以利用这些缺口。他们可能将被禁止的目标拆分成数个被允许的操作。单独检查时，每一步看似无害；但完整序列却会产生未经授权的结果。
能够感知序列的控制措施可以检测部分模式，但它们需要更丰富的状态和更长的保留时间。这会带来隐私和运营方面的顾虑。详细追踪记录可能包含员工请求、客户数据、模型输出以及机密业务决策。
组织必须像保护其监控的系统一样谨慎保护治理遥测数据。被攻破的日志可能掩盖攻击，或错误地牵连用户；被暴露的追踪记录则可能泄露这些控制措施原本旨在保护的信息。
性能是另一项权衡。代理在完成一项任务时，可能发起许多小型工具调用。将每一次调用都发送至多个策略引擎，可能增加延迟、成本和额外故障点。
基于风险的强制执行可以减轻这一负担。低影响、可逆的操作接受轻量级检查；高影响或不可逆的操作则接受更严格的授权、更详尽的日志记录或人工审查。
这种区分需要审慎分类。将草稿发送到内部审核队列是可逆的；将同一文本发布给客户则不是。读取一条客户记录与导出整个数据库也截然不同。
模型更新后，代理的行为也可能发生变化。新模型可能以不同顺序选择工具、生成不同参数，或尝试更多步骤。现有策略可能阻止新行为，或遗漏新引入的路径。
这使持续测试成为治理的一部分。团队应针对更新后的模型、工具和策略，重放具有代表性的工作流。测试应包括对抗性文档、模糊指令、已撤销的权限和不可用的服务。
互操作性带来了另一种不确定性。行业正在开发协议，帮助代理发现能力并跨系统通信。Google 推出了其 Agent2Agent protocol，以支持采用不同框架构建的代理之间协作。
互操作性可以减少集成工作，但也会扩大信任关系。本地代理可能依赖远程代理对其能力、身份或已完成工作的描述。这类声明需要技术验证。
共享协议并不会自动建立共享治理。组织仍需要制定规则，用于接受委托任务、传输敏感上下文以及验证返回结果。他们还必须决定哪些远程代理属于各自的信任边界之内。
供应商集中化带来相关风险。如果一个身份或策略平台调解每一次代理操作，服务中断可能会阻止关键工作流。配置错误则可能让整个组织无法工作，或在大规模范围内授予过多访问权限。
团队需要在部署前制定回退行为。部分操作应在控制措施不可用时默认拒绝，即系统阻止这些操作；其他低风险操作则可以在更严格限制和增强日志记录下继续进行。
因此，行动时治理应被视为分层防御，而不是一种保证。它与受限工具、最小数据访问、隔离执行、输出验证、监控和事件响应结合时效果最佳。
审慎的结论很直接：将控制措施移近执行环节，能提升组织防止伤害的能力。但这并不能让自主行为变得可预测，也无法消除设计阶段审查的必要性。
压力不止落在安全团队身上
AI 代理治理迫使应用供应商和业务负责人暴露安全团队无法从工作流外部添加的控制措施。
安全团队可以管理身份和网络访问，但未必总能理解应用的业务含义。一次修改字段的 API 调用，可能是在批准退款、发布文档，或关闭客户账户。
应用供应商必须标记具有重要后果的操作，并在这些操作周围暴露授权控制点。他们还需要返回足够的上下文，使策略系统能够区分预览与正式提交。没有这些细节，强制执行仍然会很粗糙。
代理平台提供商面临类似责任。他们需要保留规划步骤、工具选择、参数、响应和审批的持久记录。安全团队必须能够搜索这些记录，同时不暴露不受限制的思维链数据。
模型提供商仍需负责安全措施、评估和可预测的工具使用行为。然而，他们无法决定每位客户的授权策略。同一模型操作在一个环境中可能无害，在另一个环境中则可能被禁止。
业务负责人必须界定这些差异。财务负责人知道哪些交易需要职责分离；人力资源团队知道哪些员工记录需要更严格的访问控制；法务团队知道生成的草稿何时会成为正式沟通。
随后，开发者将这些要求转化为技术边界。他们决定代理可调用哪些工具、可提供哪些参数，以及可接收哪些响应。他们还决定当控制措施拒绝某一步时系统将如何处理。
这种责任划分带来了压力，因为没有任何参与者能够独自解决问题。身份平台缺乏完整的任务含义；应用供应商缺乏完整的组织上下文；模型提供商则无权决定客户策略。
最薄弱的集成环节可能破坏整条链路。代理可能拥有强身份，却通过共享服务账户调用工具；工具可能会执行权限检查，却接受来自外部文档、未经验证的指令。
采购团队应期待代理供应商提供更具体的答案。泛泛而谈的“负责任 AI”声明并不足够。买方需要知道产品如何处理身份、委托、审批、日志、记忆和撤销。
他们还应询问控制措施能否在连接器之间保持有效。代理可能在其主要平台内遵守限制，但在调用第三方服务时丢失这些限制。权限继承必须经受住这一转移。
采购后的运营归属同样重要。必须有人审查访问权限、调查异常、移除未使用的代理，并在工作流发生变化时更新策略。没有运营流程的代理清单，只会成为另一份陈旧的资产列表。
开发者和知识工作者也应关注，因为更严格的治理将塑造产品体验。一些代理会在执行敏感操作前暂停；另一些则会提供预览、受限模式或明确的权限请求。
这些中断并不总是缺陷。可见的审批步骤可以明确代理打算做什么以及将使用哪些数据。它让用户有机会在执行前发现被误解的目标。
设计不佳的控制措施会产生相反结果。反复出现的模糊提示会训练用户自动批准请求。界面必须以清晰易懂的语言说明具体操作、目标、范围和后果。
因此，市场压力有利于那些将有用的自主性与可理解边界结合起来的产品。原始任务完成能力仍然重要；随着代理获得对高价值系统的访问，可信的委托将变得同样重要。
三个信号将揭示运行时治理是否奏效
下一项考验不是再发布一则政策声明，而是身份、授权和证据能否在真实的多步骤工作流中保持完整。
第一个信号，是主要企业平台采用独立的代理身份。关键证据将包括生命周期控制、具名负责人、狭窄权限、到期机制和撤销能力。
仅有产品标签并不足够。安全团队需要将代理与其赞助员工以及其工具背后的服务账户区分开来。更广泛的支持将强化运行时治理的论点。
第二个信号，是在应用边界实施强制控制。企业软件提供商应为具有重要后果的操作暴露策略，包括外部消息、记录变更、代码部署和财务操作。
观察这些控制措施究竟能否理解业务上下文，还是仅仅过滤文本。具备上下文感知能力的授权机制将表明，治理已进入执行环节。通用警告和可选日志则意味着这一转变尚未完成。
第三个信号来自故障案例和独立测试的证据。研究人员应测试提示注入、委托权限、受污染的记忆、过度权限，以及远程代理之间的交互。
透明的事故报告将与成功演示同样重要。它们能够揭示控制措施是阻止了有害操作、限制了其影响范围，还是仅在事后记录损失。反复被绕过将削弱“行动点强制执行已趋于成熟”的说法。
未来几个月，采购方应要求供应商演示一条完整链路：从具名用户开始，委托一项边界明确的任务，获取受保护的数据，调用工具，要求审批，并撤销访问权限。
随后审查相关证据。供应商能否说明是谁发起了任务、哪个代理执行了操作、它访问了什么、适用了哪项政策，以及委托是否改变了权限？
企业 AI 代理治理唯有在真实部署中经得起这些问题的检验，才能取得成功。如果你的组织正在试点代理，请识别每个工作流中的首个不可逆操作。在那里部署最强控制措施，测试拒绝路径，并确认每项决策都可追溯至责任主体。
