夜雨聆风MCP 安全：AI Agent 接入工具后，权限边界在哪里？
当模型从“回答问题”变成“调用工具”，真正的安全边界就不该再写在提示词里
重要说明：本文只讨论 MCP 与 AI Agent 的安全架构、公开风险类型和防御方案，不提供可复现攻击步骤、payload、恶意服务代码或绕过细节。资料核验日期为 2026-05-21，MCP 规范以官方当前标注为 latest 的 2025-11-25 版本为准。所有摘录均来自公开资料，并尽量使用短引文加转述的方式，避免断章取义。
一句话核心观点：
MCP 让 AI Agent 更容易连接外部系统，也让权限边界第一次大规模进入模型上下文。Agent 的安全问题不再是“模型会不会乱说”，而是“模型被误导后到底能做什么”。因此，真正的 MCP 安全边界必须落在身份、上下文、工具权限、审批流和审计系统上，而不是只落在 system prompt 里。
先给结论
问题 | 直接答案 |
MCP 的安全边界在哪里？ | 不在模型本身，而在身份、上下文、工具权限、动作审批和审计链路。 |
Prompt Injection 能不能靠 RAG 或微调彻底解决？ | 不能。外部内容只要进入上下文，就仍然要靠隔离、过滤、策略网关和最小权限。 |
MCP Server 运行时能不能默认可信？ | 不能。连接时看起来正常，不代表运行时返回内容可信。 |
Agent 能不能默认自动执行高风险动作？ | 不能。写入、删除、外发、支付、改权限都应该默认人工确认或更强审批。 |
本地 MCP Server 能不能给到磁盘和网络全权限？ | 不能。必须按普通程序看待，做 sandbox、root 限制和最小权限。 |
MCP 自带授权就等于安全了吗？ | 不等于。协议提供的是能力，真正的授权、scope、确认和审计仍要由产品和基础设施实现。 |
阅读路线
如果你把这篇文章当成一篇技术研究稿，可以按下面的顺序读：
1.基础层：先看 MCP 到底连接了什么，Host、Client、Server、Tools 各自负责什么。
2.风险层：再看提示注入、工具投毒、过度代理为什么会在 Agent 里放大。
3.规范层：然后看 MCP 官方规范已经给了哪些安全抓手，例如 root、elicitation、sampling、authorization。
4.架构层：接着看生产级系统如何把“能调用”改成“被允许调用”。
5.治理层：最后用检查清单做评审，判断一个 Agent 能不能上线。
一、为什么 MCP 会成为 Agent 时代的新安全入口
过去我们讨论大模型安全，核心问题通常是回答是否合规、是否幻觉、是否泄露敏感信息。这个阶段的大模型更像一个“文本系统”：输入文本，输出文本，最多影响判断。
MCP 出现之后，问题变了。
MCP 的官方介绍把它定义为连接 AI 应用与外部系统的标准。原文短摘是：“open-source standard for connecting AI applications to external systems”。官方还用了一个很形象的比喻：MCP 像 AI 应用的 “USB-C port”。
这个比喻很适合传播，但对安全团队来说，它还有另一层含义：USB-C 不只传输数据，也可能接入供电、外设、存储、显示器和未知设备。MCP 也一样，它不只是在给模型补充上下文，而是在让模型有机会接触文件、数据库、搜索、代码仓库、工单、浏览器、云 API 和企业内部系统。
这就是 MCP 安全值得单独写一篇的原因。它把 AI 安全从“内容安全”推到了“动作安全”。
过去，模型输出一句错误建议，风险可能停留在文本层；现在，模型如果能够调用工具，错误建议可能变成真实动作。它可能查询数据库、读取文件、创建工单、发送邮件、提交代码、修改配置，甚至触发自动化流程。
所以，MCP 的关键问题不是“这个协议安不安全”这么简单，而是：AI Agent 连接工具之后，权限系统、策略网关、审批流和审计系统要共同决定它能看什么、能调什么、能改什么、什么时候必须停下来问人。
这也是本文的主线。
核心要点：MCP 把 AI 应用从“会说话的系统”推向“能做事的系统”。安全边界随之从内容审核，迁移到权限控制、工具治理和执行审计。
二、先把 MCP 讲清楚：它不是模型，而是连接层
MCP 容易被误解成一种新模型、新框架，或者 Agent 的同义词。都不是。
更准确地说，MCP 是一套让 AI 应用和外部系统互相沟通的协议。官方架构文档的短摘是：“MCP follows a client-server architecture”。
这套架构里有三个关键角色：
图 1：MCP 不是模型，而是连接层
角色 | 简单解释 | 安全关注点 |
MCP Host | AI 应用本体，例如桌面助手、IDE、Agent 平台 | 谁代表用户发起请求，谁管理会话和最终决策 |
MCP Client | Host 内部与某个 MCP Server 通信的连接组件 | 如何保存连接状态、认证信息和工具列表 |
MCP Server | 暴露工具、资源或提示模板的服务 | 暴露什么能力，是否可信，是否越权 |
MCP Server 可以暴露三类核心能力：
能力 | 作用 | 风险 |
Tools | 可执行函数，例如查数据库、调用 API、读文件、计算结果 | 从文本风险变成动作风险 |
Resources | 提供上下文数据，例如文件、记录、接口返回 | 不可信内容可能进入模型上下文 |
Prompts | 可复用提示模板 | 模板可能影响模型行为边界 |
官方 Tools 规范写得很直接：MCP 允许服务器暴露可以被语言模型调用的工具。这里的安全敏感点在于，Tools 被设计成 “model-controlled”，也就是模型可以基于上下文理解自动发现和调用工具。
这句话背后的含义很重：模型不只是看见工具，它还会参与选择工具。
如果 AI 应用把所有工具平铺给模型，把工具描述、工具返回、用户上传文档、网页内容、历史上下文全部混在一起，再靠一句 system prompt 约束模型“不要做危险操作”，这就不是安全设计，而是把权限系统外包给概率模型。
核心要点：MCP 是连接层，真正的风险来自连接之后的权限组合。Tools、Resources、Prompts 都是能力入口，其中 Tools 最容易把模型判断转化为真实动作。
三、权限边界到底在哪里：不是一条线，而是五道门
讨论 MCP 安全，最常见的误区是只问：“这个 MCP Server 能不能信？”这个问题重要，但不够。
真正的权限边界至少有五道门。
边界 | 要回答的问题 | 典型控制 |
身份边界 | 这个 Agent 代表谁？个人、团队、服务账号还是组织？ | 用户身份、OAuth scope、服务账号隔离 |
上下文边界 | 哪些内容可信，哪些只是外部数据？ | 来源标记、上下文分区、RAG 权限过滤 |
工具边界 | 模型能看到哪些工具，能不能自动调用？ | 工具白名单、工具分级、动态授权 |
动作边界 | 调用工具后能产生什么影响？ | 只读/写入/删除/外发分级，高风险确认 |
审计边界 | 事后能不能还原是谁让它做了什么？ | 工具调用日志、输入输出留痕、审批记录 |
这五道门里，最容易被忽视的是上下文边界。
传统应用里，数据和指令通常有相对清晰的边界。数据库参数不会天然变成 SQL 指令，HTTP 响应也不会自动变成后端命令。但 LLM 不一样。NCSC 在 2025 年的 Prompt Injection 文章里指出，当前大模型内部没有天然的 “data” 和 “instructions” 区分。原文短摘是：“no distinction made between ‘data’ or ‘instructions’”。
这句话是理解 MCP 安全的关键。
MCP Server 返回的工具结果，在传统系统里可能只是一个 JSON、一段文本或一组记录。但进入 LLM 上下文后，它就会被模型作为语言材料处理。模型未必能稳定区分“这是工具返回的数据”和“这是要求我改变行为的新指令”。
因此，MCP 的权限边界不能只靠模型理解。应该由确定性系统来做：
什么工具可见；
什么参数合法；
什么路径可访问；
什么操作必须人工确认；
什么输出不能进入下一轮工具调用；
什么外部内容只能作为数据，不能作为指令。
核心要点：MCP 安全的真正问题不是“模型是否聪明”，而是“模型是否被放在了不该由它做最终决定的位置”。
四、第一类风险：提示注入进入工具链
OWASP LLM Top 10 2025 把 Prompt Injection 放在第一类风险。OWASP 对它的定义短摘是：输入会 “alter the LLM’s behavior or output”。
这类风险在普通聊天机器人里已经麻烦，在 MCP Agent 里更麻烦。原因很简单：模型一旦接入工具，提示注入不再只是影响回答，而是可能影响工具选择、参数生成和执行顺序。
直接提示注入比较容易理解：用户在对话里要求模型忽略规则、改变身份、绕开限制。
间接提示注入更值得警惕：模型读取了网页、邮件、PDF、代码注释、issue 描述、工单内容、知识库文档或某个工具返回结果，里面夹带了影响模型行为的指令。攻击者不需要直接和 Agent 对话，只要把恶意指令放进 Agent 会读取的材料里。
这就是 MCP 场景的难点。
MCP 的价值在于让 Agent 读更多外部上下文；MCP 的风险也在于让 Agent 读更多外部上下文。上下文越开放，间接提示注入的入口越多。
一个企业知识库 Agent 可能会读内部文档；
一个代码 Agent 可能会读 README、issue、PR 评论和源码注释；
一个安全运营 Agent 可能会读日志、告警、威胁情报和网页；
一个办公 Agent 可能会读邮件、日历、附件和聊天记录。
这些内容并不都可信。更准确地说，它们在业务上可能是“需要处理的数据”，但在安全上不应该被当成“可以指挥模型的指令”。
OWASP 在 Prompt Injection 的缓解建议里强调了输出格式校验、输入输出过滤、最小权限和人工审批。值得注意的是，OWASP 明确提到 RAG 和微调并不能完全解决提示注入。短摘是：“do not fully mitigate prompt injection vulnerabilities”。
这对很多团队是个提醒：不要以为用了 RAG、向量库、微调模型，提示注入就自然消失了。只要外部内容能进入上下文，边界争夺就还在。
核心要点：Prompt Injection 在 MCP 场景里不是“让模型说错话”，而是“让模型在错误上下文里调用正确工具”。这比普通回答错误更危险。
五、第二类风险：工具投毒和运行时信任缺口
MCP 还有一种更贴近协议生态的风险：工具投毒。
OWASP 社区对 MCP Tool Poisoning 的描述很直接，称它是针对连接外部工具服务器的 Agent 的 “indirect prompt injection attack”。它指出根因是连接时和运行时之间的 “trust gap between connect-time and runtime”。
这句话非常重要。
很多 AI 应用在接入 MCP Server 时，会在配置阶段看工具名、工具描述、权限说明，觉得这个 server 看起来正常，于是允许接入。问题是，工具描述只是连接时看到的东西，真正进入模型上下文的往往是运行时返回内容。
连接时看起来正常，不代表运行时永远可信。
工具投毒的核心不是工具名字有多危险，而是工具返回内容可能混入对模型有影响的语言。假设一个 Agent 同时连接了低信任外部 MCP Server 和高权限内部工具，如果外部工具返回内容被模型当成可信指令，就可能诱导模型去调用内部工具。
图 2：工具投毒的关键不是单个工具，而是跨工具信任传导
这里不需要展示攻击代码，理解结构就够了：
第一步，Agent 接入一个看起来正常的 MCP Server；
第二步，模型在任务中调用这个 server 的工具；
第三步，工具返回的数据进入模型上下文；
第四步，模型把不可信返回误当成高优先级指令；
第五步，模型尝试调用其他更高权限工具。
这类风险的关键在于跨工具信任传导。一个低权限工具本来只能返回文本，但如果它的返回能影响模型调用高权限工具，它就间接获得了更大的影响面。
因此，MCP 安全不能只看单个工具权限，还要看工具之间是否能通过上下文互相影响。
核心要点：工具投毒不是“某个工具很坏”这么简单，而是“低信任工具的输出影响了高权限工具的调用决策”。这是 Agent 系统里最需要建模的新型信任链。
六、第三类风险：Excessive Agency，工具给多了、权限给大了、自主性给过头了
OWASP LLM06:2025 把这类问题叫 Excessive Agency。它把根因概括为三类，短摘是：“excessive functionality; excessive permissions; excessive autonomy”。
翻译成人话就是：
功能给多了；
权限给大了；
让模型自己决定的事太多了。
这三个问题在 MCP 里非常常见。
比如，一个邮件 Agent 原本只需要读取邮件摘要，却同时拿到了发送邮件、删除邮件、搜索全部历史邮件的工具。
一个数据分析 Agent 原本只需要查询报表，却使用了拥有写入、删除、导出权限的数据库账号。
一个代码 Agent 原本只需要读取仓库和生成 patch，却被允许直接 push、改 CI 配置、读取本地敏感文件。
一个云运维 Agent 原本只需要查看资源状态，却拿到了重启服务、修改安全组、创建访问密钥的权限。
这些问题不是模型独有的。传统系统里也有最小权限问题。但 Agent 让它更危险，因为模型的判断并不完全可预测，而且它会受到上下文影响。
NCSC 在 2026 年关于 Agentic AI 的文章里提醒组织 “make sure you can walk before you run”。这句话很克制，但很准确：不要一上来就把 Agent 接到关键系统、敏感数据和高影响动作上。
联合指南《Careful adoption of agentic AI services》也明确建议不要给 Agent “broad or unrestricted access”。同一份指南还有一句值得安全团队记住：“Identity is every bit as important as privilege”。
权限不是抽象配置。权限必须绑定身份。
一个 Agent 代表的是某个用户、某个服务账号、某个团队、某个审批流，还是一个没有清晰责任人的自动化系统？如果这个问题说不清，后面的审计、追责、风控和合规都会变得含糊。
核心要点：Excessive Agency 的本质是把本该由权限系统、审批系统和业务规则决定的事，交给了模型在上下文里临时判断。
七、MCP 官方规范其实已经给了很多安全抓手
MCP 不是没有安全设计。相反，官方规范和安全最佳实践已经给了很多明确抓手。问题在于，很多团队只看到了“能接工具”，没有把这些安全抓手落到产品和工程实现里。
先看 Tools 规范。
官方 Tools 页面强调，为了 trust & safety，应该保留 “human in the loop”。同一页的安全建议还包括：服务器要 “Validate all tool inputs”、实现访问控制、限制调用频率、清理工具输出；客户端要在敏感操作前确认、展示工具输入、校验工具结果、设置超时、记录审计日志。
这几条其实已经构成 MCP 工具安全的基本骨架。
官方抓手 | 工程化解释 | 落地方式 |
工具输入校验 | 不让模型生成的参数直接进后端 | JSON Schema、路径规范化、枚举约束、长度限制 |
proper access controls | 工具执行层必须有独立权限判断 | OAuth scope、RBAC/ABAC、用户上下文传递 |
rate limit | 防止失控循环和批量调用 | 每用户、每工具、每任务限速 |
sanitize outputs | 工具返回不能无条件进入模型上下文 | 结构化输出、敏感字段脱敏、提示注入检测 |
user confirmation | 高风险动作必须人确认 | 删除、外发、支付、写入、权限变更二次确认 |
audit logging | 出事后能复盘 | 记录工具名、参数、调用者、审批人、结果摘要 |
再看 Roots。
MCP Roots 允许客户端暴露文件系统边界。官方说 Roots 定义服务器可以操作的 “boundaries of where servers can operate”。准确理解是：客户端必须谨慎暴露 roots、只暴露用户有权访问的目录并防止路径穿越；服务器也应尊重 root 边界并做路径校验。Root 边界是重要控制面，但不能被理解成自动沙箱，还需要文件系统权限、进程隔离和执行策略共同兜底。
这对代码 Agent 和本地文件 Agent 很关键。文件访问不能只靠提示词写“不要读其他目录”，而要靠 root 边界、路径校验和文件系统权限共同限制。
再看 Elicitation。
Elicitation 允许 MCP Server 请求用户补充信息。官方规范明确要求，服务器 “MUST NOT use form mode elicitation to request sensitive information”。也就是说，密码、API key、访问令牌、支付凭据这类敏感信息，不应该通过普通表单模式流经 MCP client。
这说明 MCP 本身已经意识到：让 server 向用户要信息，是一个强交互能力，也可能变成钓鱼和凭据暴露入口。
再看 Sampling。
Sampling 允许 server 通过 client 请求模型生成。官方要求客户端具备 “user approval controls”，在工具循环场景里还建议设置 “iteration limits for tool loops”。这对应两个生产问题：一是 server 不能随意消耗用户模型能力，二是工具循环不能无限跑下去。
最后看 Authorization。
MCP Authorization 规范说得很清楚：授权能力在传输层，HTTP 传输应该遵循对应规范；但 “Authorization is OPTIONAL”。这句话很容易被忽略。它意味着，不能因为一个系统支持 MCP，就默认它已经做好认证、授权、scope、token 绑定和用户同意。
核心要点：MCP 官方规范给的是安全能力和最佳实践，不是自动安全保证。真正的安全取决于 Host、Client、Server 和企业权限系统怎么实现。
八、生产级 MCP 安全架构：从“能调用”改成“被允许调用”
如果要把 MCP 安全落到企业系统里，我建议用一句话做架构原则：
模型可以建议调用工具，但是否允许调用，必须由模型外的确定性系统决定。
这句话听起来简单，但会改变整个 Agent 架构。
一个生产级 MCP Agent 至少应该有这几层：
图 3：生产级 MCP 权限网关
层级 | 职责 | 不应该做的事 |
Agent 编排层 | 理解任务、规划步骤、提出工具调用意图 | 直接决定高风险动作是否放行 |
工具注册层 | 管理 MCP Server、工具元数据、版本和风险等级 | 任意接入未审查 server |
策略网关 | 校验身份、scope、参数、上下文来源和动作风险 | 把 system prompt 当访问控制 |
执行沙箱 | 限制文件、网络、进程、环境变量、凭据访问 | 让本地 server 继承过大宿主权限 |
审批系统 | 对写入、删除、外发、支付、权限变更加人工确认 | 把“用户说了可以”当作唯一证据 |
审计与监控 | 记录调用链、异常调用、失败重试和越权尝试 | 只记录最终回答，不记录工具调用 |
这套架构的重点不是复杂，而是分权。
模型负责理解，策略负责允许，工具负责执行，审计负责复盘。
不要让模型同时做理解者、裁判员和执行者。
1. 工具要分级，不要平铺
所有工具都应该按影响面分级：
等级 | 示例 | 默认策略 |
L0 只读低敏 | 查询天气、计算、读取公开文档 | 可自动调用，记录日志 |
L1 只读业务 | 查询本人日历、读取低敏知识库 | 需用户授权，可按会话放行 |
L2 敏感读取 | 读取客户数据、代码仓库、内部告警 | 细粒度 scope，必要时审批 |
L3 写入动作 | 发邮件、建工单、改文档、提交代码 | 展示参数，人工确认 |
L4 高影响动作 | 删除、支付、改权限、改云资源 | 默认禁止自动执行，走审批流 |
工具分级后，Agent 不是“有没有工具”两个状态，而是“在什么身份、什么任务、什么上下文里，能自动使用哪一级工具”。
2. 工具返回要分信任等级
很多团队只给工具本身分权限，不给工具返回分信任等级。这是不够的。
一个低权限外部工具返回的内容，不应该直接影响高权限内部工具调用。更合理的做法是：
外部网页、邮件、用户上传文档、第三方 MCP Server 返回，一律标记为不可信数据；
不可信数据可以被总结、引用、比对，但不能升级为系统指令；
如果模型基于不可信数据提出高风险工具调用，必须触发二次审查；
工具返回的自然语言尽量转成结构化字段，并由代码校验 schema；
跨工具调用时保留来源标签，让策略网关知道“这个动作建议来自哪里”。
这就是上下文工程和权限工程的交叉点。
3. 本地 MCP Server 要按本地程序看待
很多人会低估本地 MCP Server 的风险，因为它看起来只是一个给 AI 用的小工具。但从系统安全角度看，本地 MCP Server 就是运行在用户机器上的程序。
官方 MCP 安全最佳实践也专门讨论了 Local MCP Server Compromise。核心风险包括本地 server 可能访问用户系统、被恶意配置、被其他进程访问，甚至因为缺少沙箱造成任意代码执行或数据外泄。
因此，本地 MCP Server 不应该默认继承用户全部权限。至少要考虑：
启动命令白名单；
安装来源校验；
工作目录限制；
只读文件系统或最小 root；
网络出口限制；
环境变量和凭据隔离；
进程生命周期管理；
异常行为监控。
如果一个本地 MCP Server 既能读整个磁盘，又能访问网络，还能拿到环境变量里的 token，那它就不是一个“小插件”，而是一个高风险本地执行组件。
4. 授权要绑定用户上下文
MCP Authorization 的价值在于把 HTTP 场景下的授权流程标准化。但企业落地时更重要的是：工具执行必须在具体用户或具体服务身份下发生。
不要让所有 Agent 共用一个高权限服务账号。
一个工具如果是替用户读邮箱，就应该使用这个用户的 OAuth 授权，并且只给读邮件所需 scope；
一个工具如果是查数据库，就应该使用最小权限数据库角色，而不是管理员账号；
一个工具如果是提交代码，就应该能追溯到具体用户、分支、PR 和审批记录；
一个工具如果是操作云资源，就应该有短期凭据、任务级 scope 和过期机制。
权限不是为了让 Agent 更麻烦，而是为了让 Agent 出错时损害半径可控。
核心要点：生产级 MCP 安全的目标不是阻止模型使用工具，而是让每一次工具调用都能回答五个问题：谁发起、为什么调用、调用什么、影响哪里、谁批准。
九、MCP 安全评审清单：30 个问题与合格答案
下面这份清单适合做上线评审，也适合安全团队做 Agent 红队测试前的基线检查。这里不再只列问题，而是把每一项对应的合格答案写清楚，避免评审时只停留在“问过了”。
A. 接入治理
编号 | 评审问题 | 合格答案/落地标准 |
A1 | 是否有 MCP Server 白名单或审批流程？ | 有。只允许接入已登记来源、维护者、版本、权限范围的 server；新增和变更必须审批。 |
A2 | 是否禁止用户随意添加任意远程 MCP Server？ | 禁止默认自由添加。远程 server 需要通过白名单、风险分级和用户授权后才可启用。 |
A3 | 是否记录 server 来源、版本、维护者、权限说明和变更历史？ | 记录。至少保留来源、版本、发布地址或校验值、维护者、工具清单、权限范围和变更记录。 |
A4 | 工具列表变化时，是否重新评估风险，而不是自动信任？ | 必须重评。新增工具、工具描述变化、scope 变化或执行能力变化，都触发重新审批。 |
A5 | 是否区分内部 server、合作方 server、公开社区 server 和本地 server？ | 区分。不同来源对应不同信任等级、默认权限、沙箱策略和审计策略。 |
B. 身份与授权
编号 | 评审问题 | 合格答案/落地标准 |
B1 | Agent 调用工具时代表哪个用户或服务身份？ | 每次调用必须绑定具体用户、服务账号或任务身份，日志中能追溯到责任主体。 |
B2 | 是否避免所有工具共用高权限服务账号？ | 避免。高权限账号应拆分为任务级角色，不能让所有工具共享一个万能账号。 |
B3 | OAuth scope 是否按任务最小化？ | 是。只授予当前任务所需的最小读、写、外发或管理 scope。 |
B4 | 高权限 token 是否短期有效、可撤销、可轮换？ | 是。高权限 token 必须短期有效、可吊销、可轮换，且不能进入模型上下文。 |
B5 | 是否对每次工具调用做服务端权限校验，而不是只在连接时校验？ | 是。连接授权只表示通道建立成功，每次执行仍要校验身份、scope、对象和动作。 |
C. 工具权限
编号 | 评审问题 | 合格答案/落地标准 |
C1 | 工具是否按只读、写入、外发、删除、权限变更分级？ | 是。至少区分只读、敏感读取、写入、外发、删除和权限变更，并绑定默认放行策略。 |
C2 | 高风险工具是否默认不允许模型自动调用？ | 是。写入、删除、支付、外发、权限变更和生产操作默认不能自动执行。 |
C3 | 是否避免开放式工具，例如任意 shell、任意 HTTP 请求、任意 SQL？ | 应避免。确需开放时必须有命令、域名、SQL 模板、参数和执行环境白名单。 |
C4 | 工具参数是否使用 schema 校验？ | 必须使用。参数需要 schema、枚举、长度、路径规范化和对象权限校验。 |
C5 | 工具是否有超时、限流、并发和重试上限？ | 有。按用户、会话、工具和任务设置超时、限流、并发、重试和工具循环上限。 |
D. 上下文安全
编号 | 评审问题 | 合格答案/落地标准 |
D1 | 是否标记外部网页、邮件、附件、第三方工具返回为不可信内容？ | 是。所有外部输入都要保留来源和信任等级，不能默认当成系统指令。 |
D2 | 不可信内容是否被隔离展示，而不是直接混入高优先级指令？ | 是。不可信内容只能作为数据被引用、总结或比对，不能覆盖系统规则。 |
D3 | 工具返回是否做结构化解析、敏感字段脱敏和输出校验？ | 是。工具返回先按 schema 解析，敏感字段脱敏，再决定能否进入下一轮上下文。 |
D4 | 是否禁止低信任工具结果触发高权限工具自动调用？ | 禁止。跨信任等级触发高风险动作时，必须经过策略网关或人工审批。 |
D5 | RAG 检索结果是否经过权限过滤和来源标记？ | 必须经过。RAG 只能返回当前身份有权访问的内容，并保留来源、时间和权限标签。 |
E. 人工确认
编号 | 评审问题 | 合格答案/落地标准 |
E1 | 发邮件、提交代码、删除文件、修改配置、导出数据是否要求确认？ | 要求确认。凡是写入、删除、外发、导出或生产变更，都必须在执行前确认。 |
E2 | 确认界面是否展示工具名、参数、目标对象和影响范围？ | 必须展示。用户应看到工具名、关键参数、目标对象、风险等级和预期影响。 |
E3 | 用户确认是否发生在模型外部，而不是让模型自己解释“用户已经同意”？ | 必须在模型外部发生。确认应由确定性 UI、API 或审批系统记录，不能只靠模型判断。 |
E4 | 是否支持拒绝、修改参数、仅执行部分动作？ | 支持。确认环节应允许拒绝、改参数、拆分执行和只批准部分动作。 |
E5 | 审批记录是否进入审计日志？ | 必须进入。记录审批人、时间、工具、参数摘要、目标对象、决策和执行结果。 |
F. 运行时监控
编号 | 评审问题 | 合格答案/落地标准 |
F1 | 是否记录完整工具调用链，而不只是最终回答？ | 是。至少记录用户、会话、server、工具、参数摘要、调用结果、失败原因和审批记录。 |
F2 | 是否监控异常调用频率、失败重试、越权尝试和跨工具异常路径？ | 是。异常频率、失败重试、拒绝调用、越权尝试和低信任到高权限路径都应告警。 |
F3 | 是否能按用户、会话、server、工具、数据对象回放一次 Agent 操作？ | 能。审计系统应能还原一次任务中每个工具调用的顺序、输入、输出和影响对象。 |
F4 | 是否有一键停用某个 MCP Server 或某类工具的能力？ | 有。应支持按 server、工具、用户、租户或风险等级快速停用并撤销凭据。 |
F5 | 是否把 MCP Agent 纳入现有 SIEM、告警、DLP 和事件响应流程？ | 已纳入。告警、DLP、SIEM 和事件响应流程应能识别 Agent 工具调用事件。 |
这 30 项里，如果涉及写入、外发、删除、权限变更、敏感读取的关键项回答不上来，就不建议接入高风险系统；如果普通项超过三分之一回答不上来，也不建议上线。
核心要点：MCP 安全评审不要只问“有没有接入成功”，而要问“接入之后是否可控、可见、可停、可追责”。
十、最容易踩的五个坑
坑一：把 system prompt 当安全边界
system prompt 可以描述规则，但不能替代权限控制。
如果一个工具能删除文件，system prompt 写一百遍“不要删除重要文件”，也不等于文件系统权限真的禁止删除。真正的边界应该在工具执行层、文件系统层和审批层。
坑二：只审工具描述，不审工具返回
工具描述是连接时看到的静态信息，工具返回是运行时进入上下文的动态内容。MCP Tool Poisoning 讨论的正是这个缺口。
一个 server 的工具名可以很正常，返回内容却可能影响模型后续行为。工具返回必须按不可信输入处理。
坑三：只做连接授权，不做每次调用授权
很多系统在接入时授权一次，后续工具调用默认放行。这对传统 API 已经有风险，对 Agent 更危险。
Agent 任务是动态展开的，调用路径可能随上下文变化。权限判断也应该按每次调用、每个参数、每个目标对象重新计算。
坑四：让低风险任务复用高权限工具
为了省事，很多团队会把一个“大而全”的工具给 Agent：既能读、也能写、还能删。短期开发快，长期风险大。
正确做法是拆小工具、拆权限、拆场景。读邮箱和发邮件应该是两个工具；查询订单和退款应该是两个工具；读取仓库和提交代码应该是两个工具。
坑五：没有停止按钮
Agent 最大的问题之一是连续执行。它可以根据前一步结果继续规划下一步，如果没有迭代上限、成本上限、动作上限和人工接管机制，小错误可能被放大成流程事故。
MCP Sampling 规范里提到工具循环要有迭代限制，这一点在生产环境非常重要。
核心要点：Agent 安全不是一句“请谨慎操作”，而是把能力拆小、权限收窄、动作留痕、异常可停。
十一、一个推荐落地模型：三层持续信任
如果要把本文压缩成一个企业可落地框架，我会用“三层持续信任”：
第一层：身份持续信任
不要只在登录或连接 MCP Server 时判断身份。要在每次敏感工具调用时重新确认：
用户是谁；
Agent 代表谁；
当前任务是否属于这个用户授权范围；
工具目标对象是否属于这个用户；
是否出现异常设备、异常地理位置、异常调用频率或异常数据范围。
第二层：上下文持续信任
不要把所有上下文放进同一个篮子。每段上下文都应该有来源、信任级别和使用限制：
系统指令是系统指令；
用户输入是用户输入；
内部知识库是内部数据；
外部网页是不可信数据；
第三方工具返回是不可信数据；
高权限工具结果是敏感数据。
模型可以阅读这些内容，但策略系统必须知道它们来自哪里。
第三层：动作持续信任
不要因为前一步任务看起来合理，就默认后续动作都合理。每个动作都要重新评估：
是否必要；
是否越权；
是否外发；
是否写入；
是否可逆；
是否需要人工确认；
是否超过任务原始意图。
这就是 Agent 时代的最小权限：不是一次性给模型一串工具，而是在每一步判断它是否仍然需要这项能力。
核心要点：持续信任不是不信任用户，也不是不信任模型，而是不再把一次授权解释为无限期、无限范围、无限动作的通行证。
十二、结语：AI Agent 的安全边界，必须从语言回到系统
MCP 的价值非常明确：它让 AI 应用更容易连接真实世界。没有 MCP 这样的连接层，很多 Agent 只能停留在聊天窗口里，很难进入生产流程。
但也正因为它把 AI 接进了真实系统，安全团队必须改变思路。
过去我们关心的是模型会不会回答危险内容、提示词够不够严、Agent 会不会犯错。现在真正要评估的是，模型被误导后是否还能调用危险工具，提示词失效时权限系统是否还能兜住，Agent 出错后损害半径是否可见、可停、可追责。
NCSC 把 LLM 形容为 “inherently confusable”，这并不是否定大模型价值，而是在提醒我们：不要把安全性建立在模型永远不被混淆的假设上。
真正稳健的 MCP 安全架构，应该假设模型可能误解、可能被注入、可能被工具返回影响、可能做出错误规划。然后用确定性系统把损害半径限制住。
一句话总结：
MCP 让 Agent 获得工具，权限系统必须让 Agent 学会边界。AI Agent 的未来不是“让模型自由调用一切”，而是让模型在可验证、可撤销、可审计的权限轨道里做事。
如果是平台安全负责人，优先顺序应当是工具权限分级和高风险动作审批，其次是上下文隔离和工具返回过滤，最后才是提示词优化。原因很简单：提示词只能约束模型，权限系统才能约束结果。
企业 AI Agent 的最小落点，应该先把 MCP Server 接入治理、工具权限分级、提示注入防护和审计追责四层问题想清楚，再谈扩工具和提自治。
十三、常见问题（FAQ）
如果你想把这篇文章直接拿去做团队评审，下面这几个问题最值得先问清楚。
1. Prompt Injection 能不能靠 RAG、微调或更好的提示词彻底解决？
不能。RAG、微调和更好的提示词都能改善模型看到的内容，但只要外部数据还能进入上下文，就仍然可能被当成指令处理。
真正有效的做法是把外部内容和系统指令隔离开，再配合来源标记、输出校验、策略网关和最小权限。
2. 本地 MCP Server 一定比远程 Server 更危险吗？
不一定，但风险模型不同。Local MCP Server 更像运行在用户机器上的本地程序，所以要重点管安装来源、工作目录、网络出口、文件系统和凭据访问。
远程 MCP Server 则更需要关注认证、授权、返回内容污染和服务端的运行时信任边界。
3. MCP 自带授权是否足够？
不够。MCP 的授权能力解决的是连接层问题，不是完整的业务安全问题。真正的防线还要有用户身份、scope、策略网关、审计日志和高风险动作审批。
4. Agent 能否自动执行高风险动作？
默认不应该。删除、支付、外发、改权限、提交到生产等动作，都应该经过二次确认，最好支持参数展示、拒绝和部分执行。
5. 如果只能先落地一件事，应该先做什么？
先做工具分级和高风险动作审批。因为这两件事最直接决定 Agent 出错时的损害半径，也最容易和现有权限系统、审计系统对接。
参考资料
·Model Context Protocol：What is MCP?
https://modelcontextprotocol.io/docs/getting-started/intro
·Model Context Protocol：Architecture overview
https://modelcontextprotocol.io/docs/learn/architecture
·Model Context Protocol Specification 2025-11-25：Tools
https://modelcontextprotocol.io/specification/2025-11-25/server/tools
·Model Context Protocol Specification 2025-11-25：Authorization
https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization
·Model Context Protocol：Security Best Practices
https://modelcontextprotocol.io/specification/2025-11-25/basic/security_best_practices
·Model Context Protocol Specification 2025-11-25：Roots
https://modelcontextprotocol.io/specification/2025-11-25/client/roots
·Model Context Protocol Specification 2025-11-25：Elicitation
https://modelcontextprotocol.io/specification/2025-11-25/client/elicitation
·Model Context Protocol Specification 2025-11-25：Sampling
https://modelcontextprotocol.io/specification/2025-11-25/client/sampling
·OWASP GenAI Security Project：LLM01:2025 Prompt Injection
https://genai.owasp.org/llmrisk/llm01-prompt-injection/
·OWASP GenAI Security Project：LLM06:2025 Excessive Agency
https://genai.owasp.org/llmrisk/llm062025-excessive-agency/
·OWASP Foundation：MCP Tool Poisoning
https://owasp.org/www-community/attacks/MCP_Tool_Poisoning
·UK NCSC：Prompt injection is not SQL injection
https://www.ncsc.gov.uk/blog-post/prompt-injection-is-not-sql-injection
·UK NCSC：Thinking carefully before adopting agentic AI
https://www.ncsc.gov.uk/blogs/thinking-carefully-before-adopting-agentic-ai
·ASD's ACSC / CISA / NSA / Cyber Centre / NCSC-NZ / NCSC-UK：Careful adoption of agentic AI services
https://www.cyber.gov.au/business-government/secure-design/artificial-intelligence/careful-adoption-of-agentic-ai-services
·NIST AI 600-1：Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile
https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence
