文章目录
- 1 -> 引言
- 2 -> 建立 Agent 威胁模型
-
- 资产
- 输入来源
- 危险出口
- 安全不变量
- 3 -> 提示注入为什么难以彻底识别
- 4 -> 最小权限必须细到任务
- 5 -> 把数据与指令分开
- 6 -> 外送控制比“是否读到”更重要
- 7 -> 工具调用需要确定性边界
- 8 -> 多 Agent 会引入“借权”风险
- 9 -> 人工确认必须有信息价值
- 10 -> Coding Agent 的专项风险
- 11 -> 事件响应：假设 Agent 已经做错
- 12 -> 常见误区
-
- 相信“只读”绝对安全
- 用站点白名单解决提示注入
- 把确认按钮当安全设计
- 默认给 Agent 人类账号全部权限
- 认为沙箱能解决一切
- 13 -> 上线检查清单
- 14 -> 结语
1 -> 引言
传统聊天机器人的错误通常停留在屏幕上。Agent 的错误可能进入现实系统：读取文件、调用数据库、发送邮件、修改权限、创建订单或操作生产环境。能力越强，模型输出与外部副作用之间的距离越短。
因此，Agent 最大的风险并不只是“幻觉”，而是一个并不完全理解上下文的执行者拿到了真实权限。攻击者也不一定需要突破模型本身，只要在网页、邮件、文档或工具结果中放入足以误导 Agent 的内容，就可能诱导它偏离用户目标。
OpenAI 将现实提示注入类比为针对 Agent 的社会工程：外部内容是攻击来源，发送信息、调用工具等能力是危险出口。安全设计不能只依靠一个输入分类器，而要控制来源到敏感动作的完整路径。
2 -> 建立 Agent 威胁模型
首先列出四类对象。
资产
客户数据、源代码、凭据、订单、财务信息、内部文档、通信记录、模型上下文和生产权限。
输入来源
用户提示、网页、邮件、附件、检索文档、MCP Server、其他 Agent、日志和工具返回。除经过治理的系统规则外，都应该根据来源和权限被视为可能不可信。
危险出口
外部请求、发送消息、上传文件、数据库写入、命令执行、权限修改、删除、支付和生产部署。
安全不变量
例如：不同租户不能互读；邮件正文不能扩大工具权限；支付金额必须由用户确认；外部网页不能要求 Agent 上传本地文件；测试环境不能连接生产数据库。
威胁模型的核心是连接来源与出口：哪些不可信信息能够影响哪些高风险能力，中间有什么验证和人工控制。
3 -> 提示注入为什么难以彻底识别
简单注入可能直接写“忽略之前的指令”，但现实攻击更像合理的工作流程、帮助文档或任务要求。判断一段文字是不是恶意，往往需要知道用户真实目标、数据敏感度和当前权限。
因此“在输入前增加一个 AI 防火墙”只能提供一层信号，不能成为完整边界。成熟防护包括：
- 明确区分系统指令与外部数据；
- 网页、邮件和文档不能改变权限；
- 从不可信来源到敏感出口进行数据流分析；
- 对外发送前展示目标和数据；
- 减少 Agent 默认可用的工具；
- 使用结构化参数而不是让模型拼接命令；
- 高风险动作由确定性策略阻断或审批；
- 监测异常调用和数据流。
4 -> 最小权限必须细到任务
“允许访问 GitHub”范围过大。更合理的权限可能是：只读指定仓库、仅当前任务、不能访问私有组织、不能创建发布。权限设计至少考虑：
- 哪个账号和身份；
- 哪个资源与租户；
- 读取还是写入；
- 允许哪些具体动作；
- 生效多长时间；
- 是否允许继续委派；
- 如何撤销和审计。
长期有效的广泛授权会让一次提示注入获得更大影响。优先使用一次性、短时、最小范围凭证；系统管理权限和 Agent 执行权限分离。
5 -> 把数据与指令分开
Agent 读取一封邮件时，邮件内容应该进入“待分析数据”通道，而不是与系统规则合并。系统可以使用带来源的结构：
{
"source": "external_email",
"trusted": false,
"content": "…",
"allowed_use": ["summarize", "extract_dates"],
"prohibited_use": ["change_permissions", "send_files"]
}
结构化标签不能阻止模型犯错，但能够让策略层和审计系统知道数据来源，并在不可信内容触发敏感工具时要求更严格检查。
6 -> 外送控制比“是否读到”更重要
Agent 可能需要读取内部信息才能完成工作，关键是它能否把信息发送到不该去的地方。外送渠道包括：
- HTTP 请求和 URL 参数；
- 图片、预览和重定向；
- 邮件、聊天和工单；
- 上传附件；
- 日志、错误报告和分析平台；
- 其他 Agent 或第三方连接器。
OpenAI 专门讨论过 URL 可能携带对话中的敏感数据，说明即使 Agent 没有在回答中泄露信息，一次后台资源请求也可能形成安静的数据外送。
控制措施包括目标域名策略、重定向检查、敏感字段识别、数据最小化、外送预览、用户确认和网络层监控。
7 -> 工具调用需要确定性边界
模型可以提出工具调用，但执行器必须独立验证：
- 工具是否在任务允许列表；
- 参数是否符合 Schema；
- 路径和资源是否在授权范围；
- 命令是否包含未转义输入；
- 当前状态是否允许此动作；
- 是否需要人工批准；
- 是否超过调用和费用预算；
- 是否可能重复执行副作用。
不要让模型通过自然语言决定自己的权限，也不要把真实密钥放进 Prompt。凭据应由执行环境在调用时注入，模型只看到必要的能力句柄。
8 -> 多 Agent 会引入“借权”风险
在多 Agent 系统中，低权限 Agent 可能通过高权限 Agent 完成自己不能做的事。每次委派都要验证原始用户是否有权请求、上游 Agent 是否可以委派、下游是否只能使用最小数据，以及结果能否返回。
还要防止循环委派、责任丢失和状态不一致。任务链应保留发起者、授权来源、每次转交、实际工具调用和最终副作用。不能只记录“系统完成了任务”。
9 -> 人工确认必须有信息价值
频繁弹出“是否允许”会训练用户机械点击。高质量确认应该说明：
- 即将执行的具体动作；
- 目标系统和账号；
- 涉及哪些数据；
- 为什么需要；
- 是否可撤销；
- 默认建议和替代方案。
例如“是否允许访问浏览器”不如“是否允许当前任务读取 example.com 已登录页面，用于核对订单状态，不提交表单、不访问其他标签页”。
10 -> Coding Agent 的专项风险
- 把密钥写入代码或日志；
- 安装恶意或拼写相近依赖；
- 修改 CI 获取更高权限；
- 为通过测试删除安全检查；
- 执行仓库中的恶意脚本；
- 将客户样本发送给外部审查；
- 误删用户未提交修改；
- 自动合并或部署高风险变更。
GitHub 已将秘密扫描能力带入 MCP 与 AI 编程流程，说明秘密检查正在从提交后前移到 Agent 工作阶段。GitHub：Secret scanning in AI coding agents
仓库级防护应包括锁定依赖、审查安装脚本、限制网络、保护分支、扫描秘密、验证 diff、隔离执行和人工合并。
11 -> 事件响应：假设 Agent 已经做错
组织应能回答：
日志要足以调查，却不能成为新的敏感数据仓库。记录结构化事件和稳定占位符，限制原文、保留期和访问者。
12 -> 常见误区
相信“只读”绝对安全
读取敏感数据后通过 URL、日志或消息外送，同样造成影响。
用站点白名单解决提示注入
可信网站也可能包含用户生成内容、重定向或被入侵资源。
把确认按钮当安全设计
没有具体信息的高频确认只会产生橡皮图章。
默认给 Agent 人类账号全部权限
应使用任务级身份和最小范围，而不是复制操作者所有能力。
认为沙箱能解决一切
沙箱限制本地影响，但合法 API 权限仍可能造成真实外部副作用。
13 -> 上线检查清单
- 资产、来源、出口和不变量已有威胁模型；
- 外部内容始终作为不可信数据处理；
- 工具权限按账号、资源、动作和时间收窄；
- 凭据不进入普通模型上下文；
- 工具参数经过 Schema 与策略验证；
- 写入、发送、删除、授权和支付保留人工确认；
- 确认界面展示目标、数据和影响；
- 网络、URL 和重定向存在外送控制；
- 多 Agent 委派不会扩大原始授权；
- 重试具有幂等和副作用检查；
- Coding Agent 有依赖和秘密扫描；
- 日志最小化并设置保留期限；
- 具备停止 Agent、撤销凭据和调查事件的能力；
- 安全控制经过授权的对抗测试。
14 -> 结语
Agent 安全不能依赖“模型应该知道什么不能做”。真正可靠的边界位于模型之外：身份、权限、数据流、工具执行器、审批、沙箱、网络和审计。
最好的系统不是从不使用强大能力，而是让能力只在明确任务、最小范围和可验证条件下开放。这样即使模型误解、外部内容恶意或工具失败，系统仍有机会在真实损害发生前停下来。
感谢各位大佬支持！！！
互三啦！！！
