怎么防止 Agent 调工具时越权？权限怎么控？

先这样答

先立一个原则：Agent 的权限问题本质不是模型问题，是系统设计问题。模型是不可靠的输入源：提示注入、幻觉、被诱导都可能让它「请求」一个不该做的操作，所以防线必须建在代码和基础设施层，提示词里写「你不得删除数据」只是意愿声明，不是安全边界。

具体三道闸。

第一道：工具层最小授权。每个 Agent 实例只注册当前任务需要的工具和操作范围，只读任务的工具集里根本不该有写接口；参数里能约束的继续收紧，比如「客服 Agent 只能查自己租户的订单」，就把租户过滤做进工具的强制参数，不给模型自由发挥的空间。

第二道：操作分级确认。按风险把操作分级：读操作自动放行；低风险写操作可自动执行但全量记录；高危操作（删除、转账、对外发送、改配置）必须人工确认后执行，Agent 负责把「想干什么、影响范围是什么」讲清楚给人看。确认交互本身要防自动化伪造：确认入口不能是模型能触达的通道。

第三道：执行层独立鉴权。Agent 调后端时用的是服务凭据，凭据的权限范围按上述分级配置，后端接口自己做资源级鉴权，就算前两道全失效，越权请求在执行层被拒。这三道闸的思路和传统安全的纵深防御一致，只是「不可靠的输入源」从用户变成了模型。

再加一条全局要求：全量审计日志。每次调用记录「哪个 Agent、什么任务、调了什么工具、什么参数、结果如何」，日志不可篡改。出了问题能回放轨迹，合规检查也有据可查。

面试官会怎么追问

• 提示注入能靠提示词防住吗？ 不能根治。检索内容、网页内容、工具返回都可能夹带恶意指令，防线是上面三道闸加内容隔离（外部内容明确标注为数据而非指令），提示词只是降低概率的第一层。
• 人工确认会不会把自动化拖死？ 所以要分级，让确认集中在真正高危的少数操作上；也可以按用户设置放宽，管理员常驻场景可以放宽低风险写操作。
• 怎么发现已经发生的越权？ 审计日志加异常检测：工具调用的分布突变（突然开始调从没用过的工具）、高频失败的重试、非工作时间的危险操作，都是报警信号。

回答的坑

• 把「提示词里写了禁止事项」当安全方案。这是这道题的陷阱所在，面试官在等你主动戳破。
• 只讲工具层。执行层独立鉴权和审计日志不提，方案就不完整。