高频面试题

如何设计 AI Agent 的工具权限控制？不同场景下的工具应该有什么样的权限差异？

面试官问工具权限，不是想听“危险操作人工确认”，而是看你能不能把模型建议、权限判断、工具执行和审计追踪拆成清晰边界。

适合阶段：Agent 安全 / 工具调用 / 生产架构面核心能力：最小权限 · 策略网关 · 沙箱 · 人工确认 · 审计

面试官角度分析，想考什么

• 为什么工具权限不能交给模型自己判断？
  考原则：模型只提出动作，系统策略层决定能不能执行。

• 不同场景的权限怎么划分？
  考差异：读/写、可回滚/不可回滚、当前用户范围、任务风险等级要动态计算。

• 如何防越权和审计回滚？
  考落地：最小权限、注入隔离、高危审批、trace 和回滚。

可直接抄走的 30 秒参考答案

我会把 Agent 工具权限设计成动态最小权限，而不是给一个固定大工具箱。先按工具风险分层：公开只读、私有只读、草稿写入、内部写操作、对外副作用和高危操作；再根据用户身份、租户、任务意图、当前阶段和 OAuth scope 计算工具白名单。模型只能提出 tool call，执行前要经过 schema、ACL、参数范围、风险策略和必要的人工确认。不同场景里，只读查询可以自动，写草稿可以自动或弱确认，对外发送、删除、退款、代码执行和权限变更必须强控制、沙箱和审计。

面试回答详解，知其所以然

这道题的核心不是“给 Agent 配一个工具列表”，而是设计一套把能力限制在任务边界内的执行控制面。工具越强，越不能相信模型自己会永远选对、传对参数、拒绝不该做的事。

1. 先把工具按风险分层

工具权限最常见的错误是把所有工具放进同一个 allowlist。更稳的做法是先按副作用和敏感度分层：

• 公开只读工具：天气、公开网页搜索、公开文档检索。风险主要是成本、质量和来源可信度。
• 私有只读工具：CRM 查询、订单查询、内部知识库、邮件读取。风险是越权和敏感信息泄漏。
• 写草稿工具：生成邮件草稿、创建待办草稿、生成 PR patch。风险较低，因为还没有对外生效。
• 内部写操作：更新工单状态、写入记忆、修改配置。需要 ACL、幂等和回滚。
• 对外副作用工具：发邮件、发消息、创建订单、提交表单。需要二次确认和审计。
• 高危工具：转账、退款、删除数据、修改权限、执行 shell、运行不可信代码。默认禁止或强审批、强沙箱。

面试里可以直接说：只读和写操作不是一个等级，写草稿和真正发送也不是一个等级。

2. 权限判断不能放在 prompt 里

System prompt 可以告诉模型“不要删除文件”，但这不是强制边界。真正的权限链路应该是：

用户请求 -> 意图/风险识别 -> 动态工具白名单 -> LLM 生成候选调用
       -> schema 校验 -> 用户/租户/资源 ACL -> 策略判定
       -> 低风险执行 / 高风险确认 / 拒绝或降级

这里有一个关键表达：

• 模型负责 propose：选择工具、生成参数草案、解释为什么需要调用。
• 系统负责 authorize：检查当前用户、租户、资源、工具风险、参数范围和任务状态。
• 工具负责 enforce：业务后端再次校验权限，不因为调用方是 Agent 就绕过原有 ACL。
• 平台负责 audit：记录 trace、审批、执行结果和异常。

如果面试官追问“模型能不能判断风险”，可以回答：模型可以参与风险分类，但不能作为唯一授权来源。

3. 动态工具白名单比静态全量工具更稳

给 Agent 看见越多工具，既增加 prompt 成本，也增加 tool confusion 和越权面。生产里更推荐按场景挂载工具：

普通问答       -> search_docs, cite_source
订单查询       -> lookup_order(readonly), lookup_shipping(readonly)
售后草稿       -> lookup_order, draft_refund_request
退款执行       -> lookup_order, calculate_refund, submit_refund(requires_approval)
代码修复       -> read_file, edit_file, run_tests，在仓库沙箱内

动态白名单的输入通常包括：

• 用户身份和角色。
• 当前租户、项目、频道或会话。
• 意图类型和风险等级。
• 当前任务阶段，例如“调研阶段”不能开放写工具。
• 用户授权范围，例如 OAuth scope。
• 环境边界，例如本地仓库、临时沙箱或生产系统。

这能把“Agent 会不会乱用工具”从模型问题，变成平台策略问题。

4. 参数级权限同样重要

只限制工具名不够。很多事故不是调用了错误工具，而是参数越界。

• send_email 允许发给当前用户，不允许发给全公司邮件组。
• query_orders 允许查当前租户，不允许查全库。
• read_file 允许读工作目录，不允许读 ~/.ssh 或环境变量。
• run_sql 允许 select 视图，不允许任意 SQL。
• refund_order 允许小额、可回滚、同订单状态内操作，大额或异常订单要审批。

所以工具执行层要做 schema 校验、资源 ACL、字段白名单、行级过滤、速率限制和幂等键。模型传来的 JSON 参数只是候选参数，不是可信输入。

5. 不同场景下的权限差异

• 客服 Agent：查单、查物流可以只读自动执行；改地址、退款、取消订单要确认；批量操作和越权查用户信息应拒绝。
• 数据分析 Agent：优先开放只读视图和聚合查询；限制明细 PII；禁止直接连生产库执行任意 SQL；导出数据要脱敏和审计。
• Coding Agent：读写限制在仓库工作区；shell 命令按风险分类；测试和格式化可自动，删除文件、联网安装依赖、改权限、提交推送要确认。
• 办公 Agent：读取日历和文档需要按用户授权；创建草稿可自动；发送邮件、邀请外部人、共享文档要确认。
• 财务/权限 Agent：默认最小可见性；所有资金、权限、合规相关写操作都应有人审、双人审批或走原业务系统流程。
• MCP 工具生态：本地 MCP Server 要限制文件、网络和环境变量；远程 MCP Server 要做认证、scope、版本锁定和供应链审核。

6. 人工确认要按风险设计

人工确认不是越多越好。弹窗过多会造成审批疲劳，用户最后不再认真看。确认机制要把真正需要人判断的信息展示出来：

• 工具名称和风险等级。
• 关键参数和影响对象。
• 数据来源和模型理由。
• 是否可回滚。
• 预计对外影响，例如会发送给谁、会删除什么、会扣多少钱。

低风险、可回滚、幂等的动作可以自动执行；高风险、不可逆、对外部用户或资产产生影响的动作必须确认。

7. 权限系统要可观测、可回放

生产事故排查时，不能只看到“模型回答错了”。至少要记录：

• 用户、租户、会话、任务 ID。
• 当时可见的工具白名单。
• 模型提出的 tool call 和参数。
• policy 判定结果和原因。
• 人工确认记录。
• 工具执行结果、错误码、耗时。
• 输出是否经过脱敏或安全检查。

这些 trace 不只是排障用，也会变成权限策略和 eval 回归集的输入。

面试官追问3个问题

追问一：权限是静态配置还是动态计算？

• 考察点：是否理解不同任务阶段需要不同能力。
• 回答方向：基础权限可以静态配置，但每轮可见工具应动态计算。动态输入包括用户身份、租户、意图、风险、任务状态、授权 scope 和环境边界。

追问二：所有危险操作都人工确认是不是最安全？

• 考察点：是否理解审批疲劳。
• 回答方向：不是。应该按风险分级。低风险、可回滚、幂等动作自动化；高风险、不可逆、对外副作用动作强确认，并展示真实参数和影响范围。

追问三：怎么防止间接 prompt injection 诱导工具越权？

• 考察点：是否知道外部内容不可信。
• 回答方向：外部网页、邮件、文档和工具返回只当数据；不允许它们改写系统策略；工具白名单和 ACL 在执行层判断；高风险动作二次确认；输出和工具结果做注入检测与审计。

扩展知识

权限控制和工具设计是同一个问题

一个过宽的工具很难靠权限补救。例如 run_sql(query: string) 天生比 get_order_summary(order_id: string) 难控。高质量工具应该把危险能力收窄成业务语义明确、参数有限、返回可校验的接口。

危险通用工具 -> 业务专用工具 -> 参数级策略 -> 审计和回滚

沙箱是权限系统的硬边界

代码执行、文件操作、浏览器自动化、本地 MCP Server 都应该有沙箱。沙箱限制的是动作能影响的真实环境：文件路径、网络、进程、CPU、内存、环境变量和运行时长。它解决的是“即使模型或工具被诱导，损害也被限制住”。

OAuth scope 不等于 Agent scope

用户授权了某个 SaaS scope，不代表 Agent 在任意任务里都应该使用这个 scope。Agent 还需要任务级 scope：当前任务是否真的需要读邮件、是否真的需要写日历、是否真的需要访问所有项目。