文章目录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 工作阶段。GitHubSecret scanning in AI coding agents仓库级防护应包括锁定依赖、审查安装脚本、限制网络、保护分支、扫描秘密、验证 diff、隔离执行和人工合并。11 - 事件响应假设 Agent 已经做错组织应能回答哪个 Agent、用户和任务发起了动作使用了什么身份和权限读取和发送了哪些数据类别调用了哪些工具与目标哪个策略允许或阻断外部状态发生了什么变化如何撤销凭据和停止任务怎样清理或通知哪个测试和控制需要补充。日志要足以调查却不能成为新的敏感数据仓库。记录结构化事件和稳定占位符限制原文、保留期和访问者。12 - 常见误区相信“只读”绝对安全读取敏感数据后通过 URL、日志或消息外送同样造成影响。用站点白名单解决提示注入可信网站也可能包含用户生成内容、重定向或被入侵资源。把确认按钮当安全设计没有具体信息的高频确认只会产生橡皮图章。默认给 Agent 人类账号全部权限应使用任务级身份和最小范围而不是复制操作者所有能力。认为沙箱能解决一切沙箱限制本地影响但合法 API 权限仍可能造成真实外部副作用。13 - 上线检查清单资产、来源、出口和不变量已有威胁模型外部内容始终作为不可信数据处理工具权限按账号、资源、动作和时间收窄凭据不进入普通模型上下文工具参数经过 Schema 与策略验证写入、发送、删除、授权和支付保留人工确认确认界面展示目标、数据和影响网络、URL 和重定向存在外送控制多 Agent 委派不会扩大原始授权重试具有幂等和副作用检查Coding Agent 有依赖和秘密扫描日志最小化并设置保留期限具备停止 Agent、撤销凭据和调查事件的能力安全控制经过授权的对抗测试。14 - 结语Agent 安全不能依赖“模型应该知道什么不能做”。真正可靠的边界位于模型之外身份、权限、数据流、工具执行器、审批、沙箱、网络和审计。最好的系统不是从不使用强大能力而是让能力只在明确任务、最小范围和可验证条件下开放。这样即使模型误解、外部内容恶意或工具失败系统仍有机会在真实损害发生前停下来。感谢各位大佬支持互三啦