AI 安全采购该看什么：权限能否约束，修复能否验证

支出预期背后，已有需要管理的连接

a16z 的调查覆盖 100 位所在企业员工人数超过 1,000 人的 CISO，询问他们对 2027 年工作的判断。87% 预期安全支出增加，45% 计划在未来十二个月内新购或升级内部 AI Agent 安全产品。更值得关注的是使用现状：83% 自报已在生产环境使用代码助手或 Agent，55% 已通过 MCP 服务器或其他方式把 Agent 接入业务应用。我的判断是，内部 Agent 安全已有具体的使用场景支撑，采购讨论面对的是正在运行的连接与权限。但这些比例只描述受访样本，支出预期和采购意向也不能当作已批准预算或成交记录。

依据：[1]

权限控制要落到每次请求

怎样判断这类产品是否解决了问题？OWASP 将过多功能、过大权限和过高自主性列为过度代理行为的成因，并建议限制工具功能与下游权限，在具体用户的授权范围内操作，高影响动作执行前经过人工审批。尤其关键的是，下游系统应对每次请求执行授权检查，不能由语言模型自行决定是否放行。据此可以提出一个采购评估标准：产品应能说明某项操作使用谁的身份、获得何种权限，以及授权在哪里被强制执行。这个标准成立的前提，是控制能够覆盖实际调用的下游系统。

依据：[2]

看见操作，还需要能够限制操作

日志和监控有助于发现异常、追查操作及支持响应，OWASP 同时明确，日志本身无法阻止过度代理行为。因此，展示完整活动记录只能证明具备部分可观察性，不能据此判断权限已经受到约束。评估时可以检查一条具体边界：获准读取和调查的 Agent，尝试修改、发送或删除时，是否仍须取得相应授权。这里提出的是应检验的控制机制，现有证据没有证明任何特定供应商已经完整实现，也没有证明这些措施能够消除全部风险。

依据：[2]

修复能力要覆盖部署之后

漏洞修复也有类似的证据边界。NIST 的企业补丁管理指南把识别、排序、获取、安装和验证纳入同一流程：部署前检查真实性、完整性与运行影响，部署后确认补丁成功安装并生效，随后继续监控补丁是否保留、系统行为是否变化。安装还可能产生副作用或需要回滚。由此推断，评估 AI 修复工具应追问它如何连接测试、部署、生效验证和后续监控。找到漏洞、生成工单或生成补丁，都不足以单独证明风险已被消除；这份指南本身也没有测量 AI Agent 的修复效果。

依据：[3]

采购入口有倾向，厂商胜负仍未确定

调查中，44% 的受访者寻找 AI 安全能力时首先考虑现有安全平台，21% 首先考虑 AI 原生厂商。这支持现有平台更常成为初始评估入口，却不能推出最终成交份额。a16z 还披露了对 Armadin 和 Neo 的投资关系，相关案例应连同这一背景阅读，不能充当独立效果验证。本文提出的权限约束和修复验证，是基于安全控制要求形成的产品评估标准；它们是否真正影响采购、续约或供应商替换，仍缺少对应记录。只有把这些能力与实际部署表现、合同及续约结果联系起来，才能进一步判断谁获得了预算。

依据：[1] [2] [3]

接下来关注什么

• 采购与续约记录能否证明，受访企业的支出预期和采购意向转化为实际投入。
• 产品实测能否显示，下游系统会拒绝超出授权的请求，高影响操作确实在执行前经过审批。
• 修复案例是否同时提供部署前测试、安装生效验证、持续监控及必要的回滚记录。
• 最终成交和供应商替换记录，是否支持现有平台在初始评估中的优势延续到合同阶段。