高频面试题

在生产环境中，如何保证 Agent 系统的安全性？需要防范哪些风险？

这道题不是问“怎么让模型别乱说”，而是问一个能读数据、调工具、写系统的 Agent，如何被限制在可接受的风险边界里。

适合阶段：Agent 工程化 / 生产落地 / 架构面核心能力：威胁建模 · 最小权限 · 沙箱 · 审计 · Guardrail

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

• Agent 安全和普通 LLM 应用差在哪？
  考你是否知道 Agent 有工具权限、循环执行和外部副作用，风险不只是幻觉。

• Prompt injection 和越权怎么防？
  考系统边界：system prompt 兜不住，要靠输入隔离、最小权限、沙箱、审批和输出检查。

• 生产里如何审计和隔离？
  考落地：完整 trace、敏感数据脱敏、供应链审核、多租户隔离。

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

生产环境里我不会把 Agent 安全寄托在 system prompt 上，而会把它当成有工具权限的自动化程序来设计。主要风险包括 prompt injection、敏感信息泄漏、越权工具调用、过度代理、输出注入、供应链风险、跨租户泄漏和成本失控。防护上要做纵深防御：输入隔离和限流，模型层 guardrail，工具层最小权限、schema 校验、沙箱和高危操作人工确认，输出层脱敏和 sanitize，最后用完整 trace、审计和告警做持续监控。核心原则是模型可以建议动作，但能不能执行必须由系统策略决定。

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

Agent 安全的第一原则是：假设模型会被诱导、工具会失败、外部内容不可信、用户也可能恶意。所以安全设计要落在系统边界上，而不是只落在 prompt 上。

1. Agent 的风险面比普通 ChatBot 大

普通 ChatBot 的主要风险是回答错误、泄漏信息或生成有害内容。Agent 多了几个更危险的维度：

• 工具副作用：它可能发邮件、删文件、改数据库、创建订单或调用支付接口。
• 多步循环：一次错误决策可能被后续步骤放大，最终形成不可逆操作。
• 外部输入污染：网页、邮件、文档、issue、聊天记录都可能包含间接 prompt injection。
• 权限放大：如果所有工具共用管理员凭据，模型一次误调用就能造成大范围影响。
• 不可复现：多模型、多工具、多轮状态让事故排查比普通 API 难得多。

所以面试里要把 Agent 当成“会读写系统的自动化主体”，而不是“会聊天的模型”。

2. 需要重点防范的风险

• Prompt Injection：用户或外部文档诱导模型忽略系统指令、泄漏数据或调用危险工具。
• Sensitive Information Disclosure：泄漏用户 PII、企业机密、系统 prompt、API key 或跨租户数据。
• Excessive Agency：Agent 拥有超出任务必要的工具、权限、自主执行范围或资源预算。
• Improper Output Handling：把模型输出直接当 SQL、shell、HTML、Markdown 或业务参数执行。
• Supply Chain Risk：恶意模型、插件、MCP Server、依赖包或 prompt 模板进入生产链路。
• Tool Misuse / Tool Confusion：工具描述相似、参数缺校验、模型选错工具或传错对象。
• Unbounded Consumption：循环调用、超长上下文、恶意请求导致 token、API、搜索或执行成本爆炸。
• Multi-tenant Leakage：共享向量库、缓存、trace 或上下文压缩导致租户间信息串漏。

这组风险基本能覆盖 OWASP LLM Top 10 里最常见的 Agent 场景，尤其是 prompt injection、敏感信息泄漏、供应链、输出处理、过度代理和无界消耗。

3. 防御思路：五层纵深防御

输入层 -> 模型层 -> 工具层 -> 输出层 -> 审计与响应层

• 输入层：做长度限制、文件类型限制、来源标记、敏感词和注入模式检测；把用户内容、外部资料、系统指令用结构化边界分开。
• 模型层：使用清晰的 instruction hierarchy、结构化输出、拒答策略和必要的安全分类器，但不把模型判断当唯一防线。
• 工具层：每个工具做 schema 校验、权限校验、速率限制、幂等控制、超时和高危操作审批。
• 输出层：对返回用户或进入下游系统的内容做 PII 检测、HTML/Markdown sanitize、链接和附件检查、业务规则校验。
• 审计层：记录完整 trace、异常告警、预算监控、回滚信息和人工审批记录，支持事后复盘。

关键点是每层都假设上一层可能失效。比如 prompt injection 没被输入检测挡住，工具层仍然不能允许它越权删除数据。

4. 工具权限：把“能不能做”放在执行层

模型可以提出工具调用请求，但真正执行的是应用层。安全边界必须建在执行层：

• 每个工具独立授权：查询订单、退款、发邮件、删除记录不能共用同一权限。
• 按用户和租户检查 ACL：Agent 只能代表当前用户做他本来有权做的事。
• 危险动作二次确认：转账、删除、发外部邮件、修改权限、批量更新必须 human-in-the-loop。
• 参数白名单与 schema 校验：模型传来的 JSON 只是候选参数，不是可信参数。
• 只读优先：能只读就不开放写；能草稿就不直接发送；能模拟就不直接执行。
• 沙箱隔离：代码执行、浏览器操作、文件编辑要限制文件系统、网络、CPU、内存和运行时长。

面试中可以用一句话收束：模型负责建议动作，系统负责决定动作是否允许发生。

5. 数据与多租户安全

生产 Agent 通常会接企业知识库、CRM、工单、邮件和日志，数据安全不能只靠“别泄漏”的 prompt。

• 敏感数据最小化：只把当前任务必要字段放进上下文，不把整条用户档案塞给模型。
• PII 脱敏：日志、评估集、trace 默认脱敏；需要回显给用户时使用可逆 tokenization。
• 租户隔离：向量库、缓存、文件存储、任务状态和 trace 都要带 tenant_id 并强制过滤。
• Secret 管理：API key 不进 prompt、不进工具返回、不进日志；用 vault 和短期凭证。
• 数据出境控制：企业场景要确认模型供应商、区域、保留策略和训练使用策略。

6. 上线前的安全检查清单

一个生产级 Agent 上线前至少要回答这些问题：

• 它能调用哪些工具？每个工具的读写权限和副作用是什么？
• 哪些输入来自不可信来源？是否和系统指令、开发者指令隔离？
• 哪些动作需要人工确认？确认界面是否展示真实参数和影响范围？
• 工具失败、超时、重复调用时是否幂等？能否回滚？
• 日志里是否会记录敏感数据？是否做脱敏和访问控制？
• 是否有 token、步数、成本、并发、速率和运行时长上限？
• 是否做过 prompt injection、越权访问、跨租户、供应链和输出注入测试？

面试官追问3个问题

追问一：怎么防间接 prompt injection？

• 考察点：是否理解外部内容也是攻击面。
• 回答方向：把网页、邮件、文档、RAG 片段标记为不可信数据；禁止外部内容覆盖系统指令；工具层仍按 ACL 执行；对敏感输出和危险工具调用做二次模型或规则审查；关键动作人工确认。

追问二：如果业务要求 Agent 自动执行写操作怎么办？

• 考察点：自动化和风险控制的平衡。
• 回答方向：按风险分级。低风险、可回滚、幂等的写操作可以自动执行；高风险、不可逆或对外部用户产生影响的动作要审批。所有写操作要有幂等键、审计日志和回滚路径。

追问三：MCP Server 安全怎么管？

• 考察点：供应链和工具生态意识。
• 回答方向：只允许可信来源；版本锁定；声明权限；本地或容器沙箱运行；限制文件、网络和环境变量；禁止 MCP Server 直接读取凭据；记录 tools/list 和 tools/call；企业内做白名单和安全审核。

扩展知识

OWASP LLM Top 10 对 Agent 面试很有用

OWASP LLM Top 10 不是背名单用的，而是做威胁建模的框架。Agent 面试里最常用的是：

Prompt Injection + Sensitive Disclosure + Excessive Agency
+ Improper Output Handling + Supply Chain + Unbounded Consumption
= 生产 Agent 的主要风险面

其中 Excessive Agency 特别适合 Agent 题，因为它强调能力、权限和自主性的过度开放。

Prompt 防护不是安全边界

System prompt 可以表达意图，但不能当强制访问控制。真正的边界应该在代码、权限、沙箱、网络、数据库、审批和审计里。把秘密写进 system prompt，本质上等于把秘密交给一个可能被用户反复试探的组件。

安全和可用性要一起设计

所有动作都弹窗确认看似安全，但会带来审批疲劳，用户最后会机械点击允许。更好的方式是低风险动作自动化，高风险动作强确认，并在确认界面展示对象、参数、影响范围和回滚方式。