安全负责人评估AI Agent必问的三个问题

当企业安全团队评估你的AI产品时，他们并不关心模型的准确率有多高。他们真正在意的是围绕模型构建的整套系统——而以下三个问题几乎每次都会出现。

一、Agent能做什么，而用户做不到？

如果你的Agent拥有工具访问权限——比如Shell、文件系统或API调用——答案往往是"比你以为的多得多"。

核心问题在于：Agent以其进程的权限运行，而非以发起提示词的用户的权限运行。大多数AI产品并未在工具层强制执行最小权限原则（Least Privilege）。

安全负责人会迅速追问一系列后续问题：一个只有只读权限的用户要求Agent删除某些内容时会发生什么？Agent能否访问该用户本不应看到的数据？它能否横向移动到产品原本不该触及的系统？

这些追问直指一个常被忽视的事实——Agent的权限边界往往在无形中被大幅扩展，而产品团队对此缺乏清晰认知。

最小权限原则（Least Privilege） 是信息安全领域的一条基础设计准则：任何主体（用户、进程、服务）只应被授予完成其当前任务所必需的最小权限，且仅在必要的时间内持有。这一原则由 Saltzer 和 Schroeder 于 1975 年在《The Protection of Information in Computer Systems》中系统提出，至今仍是 SOC 2、ISO 27001 等合规框架的核心要求。

在传统软件中，最小权限通过操作系统账户、数据库角色、API Scope 等机制落地。但在 AI Agent 场景下，这一原则常被破坏：Agent 通常以某个服务进程或干脆以高权限凭证运行，而它调用的工具（Shell、文件系统、外部 API）往往共享同一套凭证。结果是，即使发起提示词的用户只有只读权限，Agent 仍可能以更高权限执行写操作。这正是安全负责人追问"Agent 能否删除用户无权删除的数据"的根源。

二、日志在哪里？

安全负责人要的不是模型推理日志，而是操作日志：调用了哪个工具、传入了什么参数、产生了什么结果、由哪条Prompt触发。

如果一个客户的数据被Agent触碰过，安全负责人需要从输入到操作的完整链路。麻烦的是，多数Agent架构只记录了模型调用，却没有记录工具执行，导致链路在最关键的节点断裂。

这不仅仅是一个技术问题。在合规审计和事故溯源中，缺失的操作日志意味着你无法回答"到底发生了什么"——这在企业采购的尽职调查阶段足以成为致命短板。

三、有没有人尝试攻破过它？

注意，这里问的不是"你有没有跑过扫描器"。经历过供应商风险评估的安全负责人非常清楚自动化扫描与对抗性测试之间的区别。

他们想知道的是：有没有人坐下来，认真尝试让系统做出非预期的行为——Prompt注入、工具滥用、通过上下文进行数据窃取？

对于多租户产品，这个问题更加尖锐：Agent的记忆是否跨租户持久化？每个会话是否隔离？一个用户上下文中的Prompt注入，能否影响另一个用户的会话？这些问题的答案直接决定了产品能否通过企业级安全审查。

Prompt 注入（Prompt Injection） 是 AI 应用特有的攻击方式，被 OWASP 列为 LLM 应用的头号风险。其原理是：攻击者将恶意指令伪装成数据（如网页内容、文档、邮件正文、工具返回结果），诱使模型把这些数据当作指令执行，从而绕过开发者设定的行为边界。

注入分为两类：直接注入由用户输入触发；间接注入则通过 Agent 读取的外部内容触发——例如 Agent 抓取了一个恶意网页，网页中隐藏的指令让它把用户数据发送到攻击者服务器。在多租户或共享记忆的架构下，注入的危害会被放大：一次成功的注入可能污染持久化记忆，进而影响其他会话或其他租户。因此安全团队会特别关注记忆是否跨租户持久化、会话是否隔离，以及工具返回内容是否被视为不可信输入。

这些其实不是AI问题

上述三个问题，实际上是安全团队对每一个触碰生产数据的软件都会提出的标准问题。区别仅仅在于：许多AI团队尚未准备好答案，往往在交易谈判中途才第一次听到这些问题。

那是一个糟糕的学习时机。如果你能在安全审查开始之前就回答这三个问题，交易会推进得更快。如果回答不了，审查本身就会成为交易停滞的原因。

对AI产品团队而言，这意味着需要把安全思维前置到产品设计阶段，而不是等到客户的安全负责人坐在对面时才临时应对。工具层的权限控制、完整的操作日志链路、以及主动的对抗性测试，应当成为Agent产品的基础设施，而非事后补救。