AI代理安全是一个生命周期——而非守门人
内容提要
文章指出，AI代理会自主解读目标、调用工具并继承人类凭证，可能执行用户未授权的操作，因此安全重心需从“验证身份”转向“验证具体动作”。作者提出涵盖观察、执行、构建、部署四环节的持续代理安全生命周期：先观测实际行为，再在动作执行前依据身份、委托与策略做确定性授权，并将权限控制内建为可复用基础设施，最终在规模化部署中一致执行并反馈优化。
延伸解读
从身份验证到动作授权：安全重心的转移
文章指出，传统安全假设验证身份并授予权限即可控制后续行为，但AI代理能自主解读目标、动态选择工具，甚至继承人类凭证执行用户未授权的操作。因此，仅靠身份验证和网络、终端等分层防御可能全部“按设计工作”却仍放行危险动作。安全必须转向在动作执行前，结合代理身份、委托来源、目标资源和策略进行确定性授权，把控制点放在代理执行层（harness）及工具服务、资源API等可信位置。
观察先行：用实际行为而非配置定义风险
文章强调，知道代理存在不等于理解其行为，架构图或配置文件无法可靠回答代理实际尝试了什么。安全团队需要观测执行中的动作，并将其与身份、委托和授权上下文关联。文章类比入侵防御系统和Web应用防火墙的早期实践：先监控建立行为基线，再逐步启用阻断策略，避免立即严格拦截干扰合法业务。对已部署代理的企业，优先事项可能不是拦截更多，而是先看清正在发生什么活动。
确定性执行：在概率性行为外划定明确边界
文章区分了AI行为的概率性与安全执行的确定性：代理可能每次以不同方式解读指令、选择工具或路径，安全策略不能依赖模型总是选择最安全选项。例如同一编码代理读取文件、修改受保护分支、删除仓库需要不同授权决策。有效执行是在动作前依据策略评估，高风险操作可拒绝或要求人工批准，低风险可自动放行。同时需在API、工具服务器和底层资源独立执行权限，防止代理绕开执行层检查。
将授权内建为可复用基础设施
文章认为，长期效益来自把观察和执行中的经验反哺到代理构建方式。若每个团队各自实现身份传播、委托权限、授权策略和审计日志，安全将不一致且难维护。应通过SDK、API和共享授权服务，让代理具备可识别的执行上下文、显式受限的委托权限、敏感工具调用授权和可审计决策。代理不应自动继承发起人的全部权限，例如发票核对代理只需检索和核对权限，而非审批付款或更新供应商记录的全部权力。
Q&A
AI代理安全与传统企业安全的核心区别是什么？
传统安全先验证身份再控制访问，而AI代理会自主解读目标、选择工具、创建子代理并执行动作，且常继承人类凭证。问题不在于代理缺少凭证，而在于这些凭证可能授权了人类从未意图让代理执行的操作。因此安全重心需从“验证身份”转向“验证具体动作”，即评估代理试图做什么、以谁的授权、依据什么策略。
为什么仅靠网络、终端和身份验证等现有防护层不足以保障AI代理安全？
因为代理可能使用合法凭证执行未授权操作。例如代理用开发者凭证删除生产数据库时，网络控制看到的是授权流量，运行时看到的是已批准进程，身份提供商确认凭证有效——三者都按设计工作。缺失的问题是：即使人类凭证持有者本人可以合法执行该操作，这个特定代理是否应被允许执行这个特定动作。这需要在动作执行点结合身份上下文和授权策略进行判断。
AI代理安全生命周期的四个环节是什么？它们必须按顺序执行吗？
四个环节是：观察（Observe）、执行（Enforce）、构建（Build）、部署（Deploy）。它们不是每个组织都必须依次通过的顺序关卡，而是持续循环的生命周期，组织可从反映自身基础设施和成熟度的任一环节切入。例如已有代理在生产运行的公司可从观察行为开始，新建代理的团队可直接在架构中内建授权。各阶段相互反馈，循环永不结束。
在代理安全中，“观察”环节具体需要做什么？
观察不能只停留在应用清单或架构图、配置文件层面，知道代理存在不等于理解它做什么。安全团队需要洞察代理实际尝试的动作，将观察到的动作与身份、委托和授权上下文关联起来。观察还应支持在不立即中断生产活动的情况下评估潜在策略，类似入侵防御系统和WAF早期采用的先监控、建立行为基线、再逐步执行策略的做法。
为什么代理安全中的执行必须是确定性的，而不能依赖模型自身选择安全行为？
因为AI行为是概率性的，代理可能在不同执行中不同地解读指令、选择不同工具、以不同顺序操作或发现替代路径。安全策略不能依赖模型始终选择最安全选项。例如同一已认证代理在代码仓库中，读文件可允许、修改受保护分支需人工审批、删除仓库应禁止——三个动作需要不同的授权决策。有效执行是在动作执行前于可信执行点（如代理执行层、工具服务、资源API）依据策略做确定性判断，而非仅在提示词中要求模型守规矩。
在“构建”环节，如何避免代理自动继承人类的全部权限？
代理不应自动继承发起它的人类的全部权限，而应只委托任务所需的权限。例如员工用AI助手核对发票，员工本人可能有查看发票、批准付款、更新供应商记录的权限，但代理任务只需发票检索和核对，正确架构只委托这些所需权限。此外，代理应具有可识别的执行上下文，其权限应被显式委托和约束，敏感工具调用需授权，安全决策和重要动作应可审计。这些能力应作为可复用基础设施（SDK、API、共享授权服务）提供，而非每个团队各自实现。
大规模部署AI代理时，安全架构面临哪些新挑战？
规模化运营数千个跨应用、部门、云环境和业务流程的代理时，人工审查权限或依赖各开发团队一致实施控制变得不可持续。代理可能调用新工具、与其他代理协作、参与跨多个授权域的工作流，安全控制必须跟随它们。部署架构需在支持的环境中一致应用身份上下文、委托权限、授权策略和审计要求，且底层模型或框架不应决定安全控制是否存在。此外，代理规模意味着更多独立行为者做更多决策、调用更多工具、创建更多代理，重要动作数量可能远快于应用数量增长，安全架构必须以机器生成活动的速度自动一致运行。
