AI Agent 安全检查清单：交给代理执行前要审查什么
面向开发者和小团队的 AI Agent 安全检查清单，覆盖工具、提示词、数据边界、权限、日志和人工审批。
最后更新于
AI Agent 正在从聊天工具变成执行工具。它可以读取文件、浏览网页、调用 API、修改工单、打开 PR、执行命令，甚至在多步骤任务里自己决定下一步。安全问题因此发生了变化：风险不再只是“模型有没有答错”，还包括“如果 Agent 相信了错误输入，它能做出什么动作”。
AI Agent 安全检查清单，就是在把真实任务交给代理前，先审查提示词、工具、数据源、权限、记忆、日志和人工审批点。目的不是阻止使用 Agent，而是判断哪些任务可以自动化，哪些任务必须人工确认，哪些任务暂时不该交给 Agent。
变化在哪里
早期 AI 产品的风险主要围绕生成文本：模型可能幻觉、泄露上下文，或者跟随恶意指令。Agent 增加了更大的攻击面，因为它把模型判断和外部系统连接在了一起。
常见 Agent 工作流可能包含：
- 本地文件、代码仓库、工单、日历和数据库
- 通过 API 或 MCP 暴露的工具
- 浏览器读取和点击操作
- 跨会话记忆
- 用户凭证或委托权限
- 多步骤计划，其中一个工具结果会影响下一步动作
所以，只靠“把提示词写好”已经不够了。可靠的 Agent 需要明确什么是可信数据、哪些工具可以调用、哪些动作必须确认，以及人如何复盘它到底做了什么。
三层风险
把 Agent 安全拆成三层，会更容易检查。
| 层次 | 可能出错的地方 | 审查问题 |
|---|---|---|
| 指令 | 网页、邮件、工单或文档里的恶意内容试图覆盖任务规则 | Agent 能区分用户指令和不可信内容吗？ |
| 工具 | 工具权限过宽、工具描述被投毒、工具组合产生危险动作 | Agent 只能调用当前任务需要的工具吗？ |
| 数据 | 不可信数据被当成元数据、文件来源、工具输出或执行上下文 | 系统能隔离可信数据和攻击者可控数据吗？ |
很多团队已经理解提示词注入。新的问题是，Agent 不只是读取恶意文本；它还可能根据这些文本选择工具、点击按钮、写代码或修改业务记录。
提示词注入、工具投毒和数据注入
这些概念相关，但指向的失败模式不同。
| 风险 | 简单解释 | 例子 |
|---|---|---|
| Prompt injection | 不可信内容试图覆盖 Agent 指令 | 网页要求 Agent 泄露隐藏指令或把数据发到别处 |
| Tool poisoning | 恶意工具描述或元数据影响模型如何选择工具 | 假搜索工具声称所有财务数据都应该交给它处理 |
| Agent data injection | 恶意数据伪装成可信上下文，诱导错误动作 | 仓库、页面或工具响应操纵文件路径、来源或执行上下文 |
关键变化是：危险内容不一定像“指令”。它可能像链接、标签、工具名、文件来源、补丁或结构化响应。如果 Agent 把这些数据当成可信控制流，边界就已经失效。
执行前检查清单
在把 Agent 连接到生产数据、客户记录、支付工具、部署系统或仓库写权限前，先过一遍这张表。
| 检查项 | 好的默认值 | 危险信号 |
|---|---|---|
| 任务范围 | 一个清晰任务和一个成功标准 | 让 Agent “自己处理所有情况” |
| 数据边界 | 可信输入和不可信内容分开标记 | 网页、邮件、工单、工具输出都混在一起 |
| 工具清单 | 每个工具都有负责人、用途和权限级别 | Agent 看到一大堆用途重叠的工具 |
| 权限模式 | 默认只读，写操作需要确认 | Agent 可以直接编辑、删除、部署、付款或发邮件 |
| 凭证处理 | token 有范围、可轮换、只用于指定服务 | token 被广泛透传或跨服务复用 |
| 人工审批 | 外部动作和破坏性动作必须暂停确认 | Agent 一次运行就能完成不可逆操作 |
| 日志 | 保存提示词、工具调用、输出、审批和最终动作 | 只能看到最后答案 |
| 测试集 | 同时测试正常、混乱和恶意输入 | 只用 happy path demo 判断效果 |
一个简单原则：如果某个动作很难回滚，Agent 就不应该在没有人工审批的情况下执行。
MCP 专项审查
MCP 的价值在于标准化 AI 应用如何连接工具和数据源。对开发者来说这很方便，但也意味着连接层本身需要安全审查。
使用 MCP server 前，至少问这些问题：
- 这个 server 由谁维护，代码或实现是否可信？
- 它暴露了哪些数据源和动作？
- 工具名和描述是否足够清楚，模型能否安全选择？
- 权限能否按任务或用户缩小？
- 授权流程是否使用 per-client consent 和严格 redirect URI 校验？
- token 是为 MCP server 签发，还是被盲目透传？
- 客户端能否阻止访问内部地址或 metadata endpoint？
- 工具调用是否有足够日志用于追踪误用？
最安全的 MCP 配置不是工具最多，而是 Agent 只看到当前任务需要的工具，并且每个工具都有清晰用途和受限权限。
Coding Agent 检查
编程类 Agent 要额外审查，因为它会接触仓库、终端、依赖文件、构建脚本和 CI 环境。
| 允许之前 | 检查什么 |
|---|---|
| 文件修改 | 限制工作目录，生成 patch 后人工 review |
| 命令执行 | 区分只读命令和安装、删除、部署、修改状态的命令 |
| 依赖变更 | 检查包名、registry、lockfile 和 postinstall 脚本 |
| Secrets | 不要让 token 进入提示词、日志、生成文件或 shell history |
| PR | 要求测试、diff review 和清晰的生成来源 |
| 外部输入 | 把 issue 文本、README 指令、评论和网页片段当作不可信数据 |
Coding Agent 可以显著提升效率，但前提是 review 路径可见。危险的不是 Agent 写代码，而是它同时拥有 shell、网络、凭证和缺失日志。
小团队本周可以做什么
你不需要一套企业级安全体系才能更安全地使用 Agent。先从降低 blast radius 的默认设置开始：
- 选一个可重复工作流，比如总结支持工单或草拟 PR。
- 先用只读权限运行。
- 写下 Agent 能调用的所有工具。
- 删除当前任务不需要的工具。
- 写操作、外发消息、购买、部署和删除都加人工审批。
- 保存原始提示词、工具调用、工具输出和最终动作。
- 加一个对抗样例，例如工单里要求 Agent 忽略前面规则。
如果 Agent 不能说明它相信了哪些数据、调用了哪些工具、采取了哪些动作，这个工作流就还不适合自治。
什么时候不要用 Agent
这些任务在控制层成熟前，不适合无监督 Agent：
- 涉及付款、退款、薪资或法律承诺
- Agent 可以删除客户数据或生产资源
- 数据源混合了可信记录和用户可控文本
- 工具链里包含未知第三方 server
- 团队无法在运行后检查日志
- Agent 必须从模糊指令里推断政策
更现实的路径是渐进授权：先读取、总结、草拟、提出建议，再经过审批执行。完全自治应该由反复证据换来，而不是因为 demo 看起来顺滑就直接放开。
内容和产品机会
这个主题适合形成一个新内容集群：
- what is agent data injection
- AI agent security checklist
- MCP security checklist
- coding agent security risks
- AI agent tool permissions
- AI workflow audit template
对内容站来说，转化钩子也清楚：先发布 checklist，再做可下载审计模板、MCP server review worksheet，或者一个检查工具权限过宽和危险组合的轻量 scanner。
更新记录
2026-07-09：发布中文版本，补充 Agent 安全检查清单、MCP 审查、Coding Agent 风险、FAQ 和参考资料。