TL;DR：代理工具工程及其隐藏的攻击面
代理框架工程是指围绕 AI 模型（指令、工具、权限、内存和反馈回路）构建一切，使其成为一个可工作的代理。 现在真正的安全风险主要存在于安全带本身，而不是模型上。
- 转变： 团队不再调整提示符，而是开始构建框架。代理 = 模型 + 框架。
- 问题是： 该安全机制以纯文本文件（规则、技能、MCP 配置）的形式存在，这些文件像文档一样被审查（如果有的话）。
- 证据： 规则文件后门和真实的 MCP CVE 表明攻击者已经将其作为攻击目标。
- 修复： 将线束视为代码。发货前，请清点、检查并扫描线束。
所有关于人工智能安全的讨论最终都会落到模型本身。它能被破解吗？它会不会产生幻觉？服务提供商是否在使用我们的数据进行训练？
这些问题问得好，但越来越不切实际。当人工智能代理删除生产表、植入后门或将客户名单通过电子邮件发送给陌生人时，很少是模型本身出了问题。模型只是按照其所处的框架执行了它被允许执行的操作。
代理 = 模型 + 线束
过去一年，业界悄然改变了人工智能构建的意义。即时工程让位于情境工程，而情境工程又催生了更宏大的理念： 代理线束工程.
这个想法很简单。模型本身就像一个没有“手”的推理引擎。而“外设”则赋予它“手”和执行任务的能力：它遵循的指令、它可以调用的工具、它拥有的权限、它保存的内存，以及用于检测错误的检查机制。 马丁·福勒的网站 将代理工程描述为编码代理用户现在为使代理可靠而进行的工作，以及 今年发布的学术框架 将该组件分解为 11 个职责，从工具访问和项目内存到权限和验证。
结果真实可靠。实践代理框架工程的团队报告称，即使底层模型不变，仅仅改变框架本身也能显著改变代理的运行结果。这给所有安全人员带来了一个棘手的问题：如果框架决定了代理的行为方式，那么框架也决定了代理可以被如何滥用。
以安装依赖项这样看似平常的操作为例。开发人员会停下来检查软件包名称。而配备了相应工具的代理程序只需运行命令，如果该软件包是恶意的，模型中没有任何机制能够阻止它。这正是我们在本期 SafeDev Talks 节目中要深入探讨的内容： AI代理安装依赖项时会发生什么变化？ 就其本身而言，以及为什么代理工具工程悄然成为一个供应链问题。
存储库中的代理框架工程是什么样的
打开一个开发者使用 AI 代理的仓库，你会发现相关的工具就在那里，可能就藏在你从未浏览过的文件中：
- 规则和说明文件 (
AGENTS.md,.cursorrules（副驾驶指令）告诉代理人如何行事。 - 技能文件 该软件包包含代理按需加载的可重用功能。
- MCP 服务器配置 将代理连接到工具、数据库和 API。
- 系统提示和提示模板 嵌入到应用程序代码中。
- 代理布线：代理可以使用哪些工具，可以检索哪些数据，以及两者之间是否存在防护措施。
全部都是纯文本。全部都是 commit这些文件与代码并列。所有这些文件的审核方式都与文档审核相同：快速浏览、批准、合并。然而，这些文件中的每一个都可以在不知不觉中改写代理的指令以及它被允许修改的内容。
这就是代理框架工程的真正后果：软件中最强大的配置现在反而是审查最少的配置。
攻击者已经注意到
这并非理论上的担忧。该安全带虽然事故记录短暂，但却颇具启发意义。
- 规则文件后门。 2025年3月，研究人员披露了一种攻击方式：在规则文件中隐藏Unicode字符，指示AI编码助手插入后门代码，而这些代码在其可见的响应中却不作任何提示。审阅该文件的人员并未发现任何异常。该攻击现已被编入数据库。 MITRE ATLAS 案例研究 AML.CS0041.
- 中毒的MCP工具。 研究人员在2025年之前反复证明，智能体会隐式信任工具描述，因此恶意MCP服务器只需正确地描述自身即可引导智能体。同年， CVE-2025-6514 一款被广泛下载的 MCP 客户端允许在连接到不受信任的服务器时执行远程命令，CVSS 评分为 9.6。
- 权力过大。 此 OWASP 十大法学硕士申请问题 报告将过度授权列为首要风险：代理人被赋予的工具、权限或自主权超过了任务所需。这并非模型缺陷，而是模型设计缺陷。cis离子。
注意其中的规律。这些攻击都不会破坏模型本身，它们只是破坏了模型的底层机制，而模型仍然忠实地完成了剩下的工作。
为什么你的安全堆栈检测不到它
尴尬之处在于，大多数组织已经运行了完善的应用安全工具，但几乎没有工具是为这一层而设计的。
静态分析能够理解代码，但它并不了解模型是什么，也不明白流入系统提示符的不受信任的文本为何重要。成分分析可以清点软件包，但它无法枚举 MCP 服务器或技能文件。秘密扫描器可能会遗漏代理配置文件中的 API 密钥。这些工具本身并没有缺陷，它们只是在配置不发出指令的时代背景下设计的。
因此，代理框架的工程设计进展迅速，安全审查只关注其可见的部分：模型和代码。框架则介于两者之间。
五个确保安全带牢固的习惯
确保代理框架工程的安全并不需要组建新的团队。它只需要一些习惯，将框架视为其本质：可执行意图。
| 习惯 | 为何重要 | 该怎么办 |
|---|---|---|
| 1. 清点所有安全带 | 你无法确保没有申报的代理人的安全。 | 从代码和配置文件本身（而不是通过调查）查找存储库中的每个模型、代理、MCP 服务器、技能和提示。 |
| 2. 检查框架文件，例如代码 | 规则、技能和 MCP 配置可以改变代理的操作方式，但它们却像文档一样接受审查。 | 给他们同样的 pull request 审查作为应用程序逻辑，包括检查隐藏字符。 |
| 3. 固定代理加载的内容 | 无需更改代码即可重新指向由可变标签引用的提示或模型。 | 将提示和模型固定为不可变版本。 |
| 4. 在每个水槽上安装护栏 | 检索到的文档、工具输出和用户内容都可以将注入的指令传递给模型。 | 在内容可能到达模型的路径上设置防护措施。 |
| 5. 请勿将凭证信息泄露到安全带中 | 攻击者很容易就能获取提示文件和代理配置中的 AI 提供商密钥。 | 移除它们，然后继续扫描线束文件以查找秘密信息。这很容易解决。 |
确保安全带牢固，而不仅仅是模型。
Xygeni AI 安全 智能体工程从其留下的痕迹开始：在您的代码库中。它会发现您代码库中的 AI 资产（模型、智能体、MCP 服务器、技能、提示等）。 guardrails（以及正在使用的 AI 编码工具）从代码、依赖项和这些工具留下的配置文件中提取。
然后，它会将技能文件、规则文件和 MCP 配置作为安全工件（而非文档）进行分析，并检测代理配置中的提示注入类风险，例如不受信任的内容到达系统提示符或没有防护措施的检索接收器。Xygeni 的密钥扫描功能会标记提示符和代理配置文件中的 AI 提供商凭据，并且在出现签名之前，您的 AI 堆栈的依赖项也会像其他所有内容一样受到恶意软件检测。
常见问题解答
什么是代理框架工程？
智能体框架工程是一门围绕人工智能模型（指令、工具、权限、内存、上下文和验证循环）设计环境的学科，旨在使其能够像可靠的智能体一样运行。模型提供推理能力；框架决定智能体可以看到什么以及可以做什么。
代理工具工程与提示工程有何不同？
提示设计塑造单个指令。代理框架设计塑造代理运行的整个系统，涉及多个步骤、工具和会话。提示只是框架中的一个文件。
为什么安全带存在安全隐患？
因为它控制着代理的权限，而且这些权限信息存储在很少作为安全组件进行审查的纯文本文件中。一旦规则文件或 MCP 配置被攻破，你就能在不触及模型本身的情况下控制代理。
谁应该拥有代理安全保障？
应用安全方面，需要与构建和配置代理的工程师合作。安全框架是您交付的软件的一部分，因此它应该与您的其他代码一样，纳入相同的审查、扫描和清点流程。
