Mend 的五层安全指南瞄准超越提示词护栏的生产级 AI 风险

Mend.io 发布了一套登上 Google News 的五层安全方法，其核心信息却挑战了许多团队保护生产级 AI 的方式。仅靠提示词护栏，无法保障那些持有凭证、调用工具、保留记忆并改变外部系统的 agents。

MarkTechPost 于 8 月 3 日报道的这份指南，将攻击面划分为交互、agent、集成、模型和代码五个层面。它的实用价值在于，将 AI 应用视为一个可执行系统，而不只是面临异常输入风险的聊天机器人。

这一差异正是冲突的根源。开发者希望 agents 能以更少的中断完成更多工作；而安全团队则需要在这些 agents 遇到恶意文档、被投毒的工具、过度权限或意外执行路径时，施加确定性的限制。

MCP 是 Model Context Protocol 的简称，它为 AI 应用发现和调用外部工具提供了标准接口。它可以将模型连接到数据库、文件系统、API、业务应用和开发者环境。

该协议提升了互操作性，但这种便利也扩大了每个工作流中的信任边界数量。一个 agent 现在可以在数秒内将不受信任的文本转化为具有实际后果的操作。

问题不再是模型是否会生成不当回答，而是被操纵的模型是否会将已获授权的工具用于未经授权的目的。

Google News 将生产级 AI 安全置于焦点

重要事件是，讨论重点已从模型行为转向保护输入与执行之间的完整路径。

通过 Google News 突出报道的这份生产安全指南，将 agent 安全视为一个五层工程问题。交互层涵盖提示词、检索文档、用户文件及其他进入应用的信息。

agent 层包括规划、记忆、工具选择和委派任务。集成层涵盖 MCP servers、API、数据库、插件及其他将 agent 决策传入外部系统的连接。

模型层包括语言模型、其配置及其行为局限。代码层包括应用逻辑、依赖项、基础设施、凭证和部署流水线。

这种框架之所以重要，是因为故障往往跨越多个层面。恶意指令可能通过文档进入，影响模型推理，触发获准使用的 MCP 工具，并通过一次普通 API 请求泄露数据。

每个组件看起来都可能在按设计运行。安全故障源于它们的组合方式。

传统应用安全在这一技术栈中仍然重要。团队必须修补依赖项、保护密钥、验证输入、隔离工作负载并审查代码。然而，这些控制措施无法完全解释，为何一个 agent 会在错误的时机选择有效工具。

模型通过同一种基本媒介处理指令和数据。一个检索到的页面可能包含回答用户问题的信息、改变 agent 方向的指令，或两者兼有。

这会导致间接提示词注入：恶意指令通过外部内容而非用户可见的提示词进入。读取电子邮件、网页、支持工单或内部文档的 agent，可能在正常工作中遇到此类内容。

攻击可能对发起任务的人保持不可见。agent 可能按预期总结文档，同时悄悄调用另一项工具，或将被投毒的信息写入记忆。

因此，Mend.io 的五层框架可作为一种盘点方法。它要求团队识别指令、权限、代码、数据和状态可能进入或离开系统的每一个位置。

这份盘点不应只涵盖已部署的模型，还应记录 agent 配置、系统提示词、MCP servers、可用工具、权限范围、记忆存储、模型供应商、依赖项和责任人。

没有这张图，团队无法判断一个被攻陷的组件能否触及另一个组件。当某项集成改变行为时，他们也无法有把握地撤销访问权限。

这一事件并非一次新的协议发布，也不是单个已披露漏洞，而是一条更清晰的生产边界：agent 安全必须覆盖完整的执行链。

这条边界同时给开发者、平台团队、安全工程师和 AI 供应商带来压力。每个群体只控制系统的一部分，而最严重的故障会跨越这些组织边界。

AI Agents 将语言转化为特权操作

当 LLM 的输出控制了拥有真实权限的软件时，它就成为一个本质上不同的安全问题。

传统聊天机器人会生成供人审阅的文本。agent 则可以理解目标、选择工具、构造参数、检查结果，并在无需再次由人做决定的情况下继续行动。

这一循环改变了错误模型回答的后果。虚构的一句话或许只是麻烦，但传入数据库或部署工具的虚构指令可能演变为运营事件。

以一个被要求比较供应商提案的内部研究 agent 为例。它会读取上传文档、搜索共享存储、查询采购记录，并起草建议。

一份恶意提案可以隐藏指令，要求 agent 从另一个文件夹获取机密定价信息。如果存储工具拥有宽泛权限，模型的错误决定就会成为真正的数据泄露路径。

编程 agent 也会带来类似问题。它可能读取代码库、安装依赖、执行测试、修改文件并创建 pull requests。不受信任的 issue 文本或软件包文档，可能影响持有这些能力的同一模型。

MCP 使这些连接更容易以一致方式构建。这有利于开发者，但也意味着工具描述、工具响应或远程服务器都可能影响 agent 后续的选择。

OWASP 的agent 安全指南将提示词注入、工具滥用、数据外泄、记忆投毒、过度自主性和级联故障列为主要风险。这些类别彼此关联，并非相互孤立。

记忆尤为重要。持久化 agent 记忆会为未来会话存储信息，使应用能够记住偏好、先前工作或积累的知识。

如果不受信任的内容未经验证便进入该存储，一次攻击可能在原始对话结束后仍然存在。后续用户可能收到被投毒的事实，或触发受先前文档影响的行为。

多 agent 系统会扩大潜在影响范围。一个 agent 可以向另一个拥有不同权限的 agent 传递指令、摘要、凭证或工具结果。

被攻陷的研究 agent 可能没有数据库写入权限，但它可以向拥有该权限的运营 agent 提供被操纵的发现。

团队无法仅靠要求每个模型忽略恶意指令来解决这个问题。模型必须处理自然语言才能完成工作，而攻击者可以改变措辞、上下文、编码和投递渠道。

因此，安全目标必须是操作边界。在工具执行前，确定性软件应决定 agent、用户、资源、操作和参数是否构成允许的组合。

读取操作不应悄然变成写入操作。访问一个代码库不应等同于获得所有代码库的访问权限。获准起草电子邮件不应自动允许发送。

高影响操作需要更严格的处理。资金转账、生产变更、账户管理、数据删除、对外发布和凭证访问，应要求明确授权或人工批准。

批准必须绑定到实际操作。像“继续”这样模糊的确认，不如展示目标地址、操作、受影响资源和关键参数的批准来得可靠。

短期凭证同样能降低暴露风险。agent 应只获得当前任务所需的最低权限，并在任务结束时失去该权限。

这种做法可能增加摩擦，尤其是在开发者以任务完成率和速度衡量成功时。然而，另一种选择是允许概率性推理充当访问控制系统。

语言模型可以提出操作建议，但不应单方面界定自身权限。

MCP 标准化连接，而非完整治理

MCP 解决的是兼容性问题，而生产团队仍必须围绕它构建政策与问责层。

MCP client 可以获取 server 可用的工具定义，并将其呈现给模型。模型使用这些描述和参数模式来选择并调用工具。

这种结构减少了自定义集成工作。兼容的 client 可以通过共享协议连接许多 servers，而无需为每项服务学习独立接口。

然而，标准化发现并不能使每个被发现的工具都值得信任。server 可能被攻陷、被冒充、配置错误，或在初始安全审查后发生更新。

工具投毒会利用这种信任。置于工具描述中的恶意指令可能影响模型，同时对用户的日常交互保持隐藏。

工具响应也可能携带类似指令。agent 或许会将响应视为数据，但语言模型可能将其中嵌入的文本解释为影响后续操作的指令。

最新的 MCP 授权规则包含针对令牌验证、受众绑定、令牌窃取、通信安全、重定向风险和混淆代理攻击的要求。

这些要求强化了身份验证和授权基础设施。它们并不决定某项具体业务操作是否适合用户当前的目标。

有效访问令牌证明其在作用域内拥有被识别的权限。它并不能证明模型在读取不受信任内容后作出了正确决定。

生产系统需要在模型意图与工具执行之间设置控制点。该层可以评估身份、请求的操作、资源、参数、会话风险、数据分类和先前操作。

Microsoft 在介绍一种开源运行时治理方法时描述了这一缺口。其内部治理基准测试测试了 60 个提示词，包括 45 个对抗性案例和 15 个有效案例。

Microsoft 报告称，当系统依赖仅提示词的安全指令时，策略违规率为 26.67%。该公司提供了方法论和复现材料，但该结果仍属于其自身评估。

这一发现仍说明了一项重要设计原则：不应将遵循指令的表现视为确定性的安全边界。

运行时控制平面可以允许、拒绝或升级处理每项工具请求。它还可以在向模型暴露工具定义前对其进行检查，并在将响应返回给 agent 前进行分析。

这样的策略层应强制执行架构规范、参数约束、资源允许列表、速率限制、成本上限和最大调用链深度。它应阻止反复失败，而不是让智能体陷入失控的重试循环。

例如，客户支持智能体可能需要读取账户记录并准备退款建议。它并不需要不受限制地访问数据库，也不需要获得立即执行其提出的每一笔退款的权限。

策略层可以将读取范围限制在当前客户，隐藏敏感字段，限定退款金额上限，并要求在付款前获得人工批准。模型无需获得广泛的运营权限，依然可以发挥作用。

隔离同样重要。高权限工具不应与任意外部 MCP 服务器共享同一智能体上下文。

一个读取公开网页内容的智能体，不应自动获得通往内部管理工具的路径。将这些能力分离，可降低恶意外部内容抵达敏感执行接口的可能性。

安全团队还应维护经批准的服务器注册表。每个条目都应标明服务器所有者、代码来源、部署位置、认证方式、可用工具、数据访问范围、版本和审查状态。

当更新改变工具描述、架构、依赖项、权限或网络目标时，必须触发审查。数月前通过审查的服务器不应因此获得永久信任。

MCP 服务器也需要常规的服务防护。团队需要安全传输、身份验证、补丁管理、依赖项管理、输入验证、密钥隔离、日志记录和事件响应。

该协议并不能取代这些控制措施。它只是新增了一个必须一致实施这些措施的位置。

真正的权衡在于自主性与约束

每增加一项能力，都会提升智能体的实用性，同时也会扩大成功操纵所能造成的损害。

这种权衡解释了为何智能体安全不能等到部署前才作为一份检查清单附加上去。早在安全扫描器开始检查之前，产品设计就已决定系统的最大权限。

没有工具的智能体可能生成有害或不准确的文本。具备文件访问权限的智能体可能泄露文档。拥有 shell 访问权限的智能体可以执行命令，而连接到生产系统的智能体则可能修改正在运行的基础设施。

出于便利，原型中往往会引入广泛权限。开发人员希望先测试智能体能否完成端到端工作流，再投入精力设计细粒度的授权机制。

这些原型走向生产的速度可能快于预期。临时凭据留在配置中，实验性的 MCP 服务器变成共享基础设施，宽松的工具架构则演变为未被记录的依赖关系。

五层模型有助于暴露这些捷径。然而，仅有清单并不足以约束它们。

每个智能体都需要明确的信任边界。该边界应说明谁可以调用它、它可以接收哪些数据、可以使用哪些工具、能够访问哪些资源，以及哪些结果需要批准。

团队应区分读取、起草、建议和执行模式。这些标签必须映射到可强制执行的权限，而不能只是提示词中的措辞。

研究智能体可以读取经批准的来源并起草研究结果。运营智能体可以准备部署计划。另一个受控流程则可以验证并执行该计划。

这种分离会降低自主性，但也会形成可审查的转换过程。调查人员能够看到信息何时变成建议，以及该建议何时变成行动。

可观测性服务于同一目标。日志应记录发起用户、智能体身份、模型版本、提示词或策略版本、MCP 服务器、工具名称、参数、响应分类、批准记录和最终结果。

敏感数据不应被随意复制到这些日志中。安全遥测需要保留足够的调查上下文，同时不能因此创建另一个暴露密钥的存储库。

智能体身份尤其值得关注。多个智能体共用一个服务账户，会使责任归属或撤销某个已受损工作流变得困难。

独立身份支持按智能体分配权限，并形成更清晰的审计轨迹。它们还能帮助安全团队识别异常行为，例如研究智能体突然请求写入权限。

政府指南如今将 MCP 视为需要经过审慎安全设计的基础设施。美国国家安全局在 2026 年 5 月发布的 MCP 安全指南讨论了身份验证、授权、隔离、服务器验证、生命周期管理，以及覆盖协议各组成部分的风险。

这种关注表明成熟度正在发生变化。MCP 不再只是通过本地演示讨论的开发者便利工具。各组织正在评估它在以下环境中的应用：一旦工具遭到入侵，就可能影响敏感数据和运营活动。

Google Cloud 的智能体安全控制也提出了类似观点。该指南建议使用独立的智能体身份、最小权限角色，并限制对生产资源的读写工具访问。

这些都是熟悉的安全原则。但由于智能体会动态选择行动，并将单个有效工具组合成开发人员未曾枚举的工作流，其应用变得更加困难。

不安全的工具链式调用发生在：一次被允许操作的结果，促成了有害的后续序列。搜索工具、文件读取器和外发消息工具在分别审查时，可能都显得风险较低。

但组合起来，它们可能形成数据外泄路径。智能体搜索敏感信息、读取它，再将其传输到组织外部。

因此，策略必须审查操作序列，而不仅是单次调用。一个请求单独看可能有效，但在同一会话中发生于另一事件之后时，则可能显得可疑。

具备上下文感知能力的控制措施可以阻止涉及不可信输入和高权限输出的组合。当智能体从信息收集跨越到外部行动时，它们也可以要求重新授权。

这一设计比在用户提示词周围增加过滤器要求更高。它需要产品、平台、身份、应用安全和运营团队之间的协作。

这种组织成本正是权衡的一部分。企业不能一边宣称具备广泛的自主能力，一边只把安全责任交给模型提供商。

生产安全仍无法保证什么

分层控制可以降低暴露风险，但现有框架没有任何一种能够证明智能体将在所有模型、工具和上下文组合下始终安全。

第一个不确定性在于评估质量。安全测试可以衡量已知攻击，但生产输入持续变化，对手也会适应已经公开的防御措施。

红队测试套件应涵盖直接和间接提示词注入、未授权工具使用、权限提升、记忆投毒、数据外泄、绕过批准、递归执行和多智能体传播。

团队应在部署前以及发生重大变更后运行这些测试。新的模型、系统提示词、记忆设计、MCP 服务器、工具架构、检索来源或策略，都可能改变攻击面。

通过测试并不意味着获得永久安全。它仅表明，在特定条件下，已定义的控制措施抵御了已定义的攻击。

误报会带来另一个问题。如果控制措施中断了过多的合法任务，用户就会寻找规避方法，或要求获得更广泛的权限。

漏报更危险，却也更难观察。智能体可能完成了被请求的任务，同时却泄露数据、保存遭投毒的记忆，或执行不必要的操作。

人工批准并非完整解决方案。用户可能会习惯于确认操作，尤其是在应用频繁展示提示或提示不够清晰时。

攻击者还可能操纵向审批者展示的信息。批准界面必须从受信任的执行数据中获取操作详情，而不能只依赖模型的解释。

供应链风险同样尚未解决。MCP 部署可能包含由不同主体维护的服务器、SDK、注册表、软件包、模型、容器和托管服务。

签名软件包可以证明来源和完整性，但无法保证签名后的行为是安全的，也无法保证远程服务会保持不变。

组织应优先采用可复现部署、固定版本、经审查的源代码、受控注册表和文档化的更新流程。远程服务器需要持续验证，而不是一次性批准。

紧急撤销必须切实可行。团队应能够禁用某个智能体、服务器、工具、凭据或权限，而无需等待应用发布。

记忆系统也需要同等的控制措施。运营人员需要能够检查、隔离、过期处理和移除可疑条目，同时保留用于调查的证据。

这种审慎态度同样适用于供应商的宣称。安全产品越来越多地承诺提供提示词防护、自动化红队测试、智能体发现、态势管理或运行时强制执行。

这些能力能够促进防御，但买方应询问每项控制措施位于何处，以及它失效时会发生什么。仅标记可疑文本的检测器，无法替代对后续行动的授权控制。

团队应要求可衡量的证据。有用的问题包括：测试了哪些攻击类别、评估数据是否可用、如何处理绕过，以及强制执行是否会以闭合失败的方式运行。

他们还应审查延迟和可用性。位于每次工具调用之前的策略服务会成为关键基础设施。

如果该服务以开放失败的方式运行，智能体就可能在缺乏控制的情况下行动。如果它以闭合失败的方式运行，依赖它的工作流就会停止。生产设计必须明确处理这两种结果。

因此，五层方法是一项基础，而非保证。它有助于团队发现仅审查模型时会遗漏的风险。

其成功取决于将这些层次转化为明确责任、可强制执行的策略、可重复的测试和运营响应。若缺少这些步骤，该框架就会沦为另一张只记录暴露风险、却未减少风险的图表。

三个信号将表明智能体安全是否正在成熟

下一阶段将通过可强制执行的默认设置、独立测试和真实部署中的证据来衡量。

第一个信号是 MCP 客户端和服务器是否默认采用更窄的授权范围。支持现代授权标准固然重要，但安全部署还需要针对特定资源的范围，并明确区分读取和写入操作。

更强大的生态系统会使广泛权限显得格外例外。客户端会向用户展示每个服务器可访问的内容，服务器则会拒绝原本用于其他资源的令牌。

默认限制将强化这样一种观点：标准化连接可以与约束并存。若继续依赖环境凭据和过大的权限范围，这一观点将被削弱。

第二个信号是对运行时治理的独立评估。供应商基准测试提供了有用的起点，但买方需要针对多种模型、工具和攻击方式的可重复测试。

评估者应同时报告攻击防护效果和合法任务完成情况。从狭义上看，阻止每一次工具调用的系统或许安全，但它无法实现其运营目的。

结果还应将提示词检测与行动强制执行区分开来。检测可疑语言，与阻止被禁止的文件读取、数据库更新或外发请求，是不同的事情。

第三个信号是企业能否生成完整的智能体清单和事件记录。组织应了解部署了哪些智能体、由谁负责、使用哪些模型，以及它们能够访问哪些 MCP 服务器。

他们还应能够根据经过身份验证的日志重建具有重大影响的操作。身份缺失、工具记录不完整，或权限变更无法解释，都表明采用速度已超过治理能力。

这正是知识管理与安全运营的交汇点。团队需要可搜索的记录，将需求、代理配置、测试结果、审批、事件和补救决策关联起来。

受控的技术知识库可以帮助工程师检索这些记录，但它必须遵守同样的访问与数据处理边界。

在 Google News 上的展示，让这套五层安全模型获得了更广泛的关注。它的长期意义取决于团队能否将这种关注转化为更小的权限范围和更强的执行控制。

开发者应从一项生产工作流入手，梳理每一项输入、模型决策、记忆写入、集成、凭据、工具调用和输出。随后，他们应识别确定性策略会在哪些环节中断这些节点之间的不安全流动。

你的组织能否说明每个生产代理能够执行什么操作、由哪个身份授权，以及一份遭入侵的文档将如何被遏制？如果答案并不完整，下一步就不该是再增加一条提示规则，而是收紧执行边界、建立经过测试的审批路径，并保留一条能够超越代理推理过程的审计轨迹。