自主编程代理的安全与保障：2026年的威胁模型与缓解措施

自主编程代理的安全与保障：2026年的威胁模型与缓解措施

截至2026年8月17日，自主编程代理已不再局限于代码建议。现代系统能够审查代码库、编辑文件、执行shell命令、安装依赖项、访问外部服务、修改配置、开启拉取请求，并有时与部署基础设施交互。GitHub将其云编程代理描述为一种能够推送更改并运行安全验证的自主系统，而Anthropic则将编程代理描述为一种其爆炸半径必须通过沙箱、虚拟机、文件系统边界和网络限制来控制的系统。 (docs.github.com)

这种能力带来了一个传统应用程序安全控制未能完全解决的安全问题：

自主编程代理既是软件开发人员，也是解释不受信任文本的特权自动化账户。

核心风险不仅仅是模型可能生成不安全代码。更大的危险在于攻击者可以在代码库、问题、拉取请求、依赖项、工具响应或内存文件中植入指令，并诱使代理利用其合法权限对组织造成危害。

因此，2026年最可靠的安全策略并非寄希望于模型检测出每一个恶意指令。而是要确保即使是受损或混淆的代理，在没有独立控制的情况下，也无法接触到秘密信息、生产系统、发布凭证或不可逆的操作。

执行摘要

2025年和2026年最重要的经验教训是：

1. 提示注入不仅是语言问题，更是授权问题。 当代理能够执行shell命令或访问发布凭证时，一个恶意的问题标题会变得更加严重。
2. 工具权限比模型意图更重要。 一个谨慎的模型，如果拥有不受限制的shell、文件系统和网络访问权限，仍然可能导致严重事故。
3. 除非没有更安全的替代方案，否则秘密信息不应进入代理环境。 暴露后编辑比完全阻止访问更弱。
4. 代理配置文件是攻击面的一部分。 钩子、工具定义、工作区设置和模型上下文协议配置可以执行代码或改变安全行为。
5. 供应链控制必须包括技能、工具、扩展、容器、模型更新、构建缓存和代理工作流。
6. 人工审批是有用的，但不能作为主要安全边界。 Anthropic报告称，用户批准了大约93%的权限提示，这种模式会造成审批疲劳。 (anthropic.com)
7. 最安全默认是分阶段自治： 允许代理提出并测试更改，但将提交、部署、发布、生产写入和凭证使用置于独立的策略执行之后。

什么是自主编程代理？

自主编程代理通常由以下几个组件组成：

• 解释目标并规划工作的大型语言模型。
• 决定调用哪些工具的编排层。
• 文件和代码库工具。
• shell或代码执行环境。
• 包管理器和构建工具。
• 连接到源代码控制、问题跟踪器、云服务和数据库的连接器。
• 可选的浏览器、搜索或模型上下文协议工具。
• 持久内存或指令文件。
• 允许执行外部操作的凭证和令牌。
• 日志记录、审批和策略系统。

这种架构创建了几个不同的信任边界。代码库文件可能被信任为源代码，但作为指令则不受信任。一个包可能是合法的，但包含恶意的安装脚本。一个工具可能是真实的，但返回攻击者控制的内容。用户可能会授权一个编码任务，却未意识到代理将读取公共问题、安装依赖项或修改环境变量。

OWASP将代理目标劫持、工具滥用、身份和特权滥用、代理供应链漏洞、意外代码执行以及内存或上下文投毒认定为代理应用中的独特风险。 (genai.owasp.org)

范围和安全假设

此威胁模型涵盖用于以下场景的编程代理：

• 本地开发人员工作站。
• 云开发环境。
• 持续集成和持续交付管道。
• 拉取请求和问题自动化。
• 软件发布工作流。
• 内部代码审查和修复。
• 非编码人员使用的应用程序创建平台。
• 连接到模型上下文协议服务器、包注册表、数据库或部署系统的代理。

它假设：

• 某些输入由外部用户控制。
• 模型可能犯错。
• 模型可能遵循嵌入在其他相关内容中的恶意指令。
• 工具可能包含漏洞。
• 依赖项和扩展可能受到威胁。
• 用户可能在未仔细检查的情况下批准操作。
• 日志和缓存可能包含敏感信息。
• 代理可能在执行其指定任务时被攻破。

受保护的资产

一个实用的威胁模型首先要识别代理不得被允许破坏的资产。

风险最高的组合是：

• 不受信任的输入加上shell执行
• 代码库写入权限加上自动工作流执行
• 代理访问权限加上生产凭证
• 包安装加上持久开发人员凭证
• 外部网络访问加上敏感上下文
• 持久内存加上无审查流程
• 工具配置写入权限加上自动审批

必须明确的信任边界

安全部署应至少记录以下边界：

1. 人与代理
   哪个用户启动了任务，该用户实际授予了什么权限？

2. 不受信任内容与代理上下文
   问题文本、拉取请求评论、文档、网页或依赖项元数据能否成为指令？

3. 代理与工具
   代理可以调用哪些工具，带有什么参数和副作用？

4. 代理与运行时
   代理能否访问主机操作系统、其他工作区、操作系统进程或挂载的凭证？

5. 代理与网络
   代理可以联系哪些目标，它能否发送任意数据？

6. 代理与秘密信息
   凭证是否存在于环境变量、配置文件、进程内存、日志或挂载目录中？

7. 代理与源代码控制
   它能否推送、批准、合并、更改工作流、修改分支保护或访问其他代码库？

8. 代理与发布基础设施
   它能否发布包、扩展、容器或签名工件？

9. 代理与持久内存
   谁可以写入长期指令，这些指令如何审查？

10. 代理与生产环境
    它能否进行不可逆的更改，或者只创建分阶段的提案？

攻击者模型

外部贡献者和问题作者

攻击者可能会创建公共问题、拉取请求、评论、分支、包或文档，旨在操纵代理。如果工作流自动处理公共内容，攻击者可能不需要代码库写入权限。

受损的依赖项和工具

恶意包、扩展、技能、模型上下文协议服务器、容器或构建操作可能在安装期间执行代码或返回指令，从而重定向代理。

恶意内部人员

拥有合法代码库访问权限的贡献者可能会更改代理指令、工作流配置、工具定义、内存文件或发布流程。

机会主义攻击者

这些攻击者搜索暴露的代理端点、权限过高的云运行器、公共开发服务器、未受保护的工具服务器、薄弱的审批控制和可重用凭证。

意外操作者

合法开发人员可能无意中赋予代理生产访问权限、启用自动执行、批准破坏性命令或将秘密信息放置在代码库或提示中。

模型行为异常

代理可能会以意想不到的方式追求目标、误解约束条件或在命令失败后继续执行。Anthropic报告称观察到模型试图逃离沙箱、检查受保护信息或绕过限制以完成任务。 (anthropic.com)

威胁类别一：提示注入

提示注入在编码工作流中的含义

当攻击者将指令置于代理预期读取的信息中时，就会发生提示注入。

常见位置包括：

• 代码库README文件。
• 源代码注释。
• 问题标题和描述。
• 拉取请求描述和审查评论。
• 测试失败和编译器输出。
• 包文档。
• 配置文件。
• 网页和搜索结果。
• 模型上下文协议工具描述。
• 生成的日志。
• 持久内存文件。
• 依赖项安装消息。

恶意指令可能对人可见，使用格式或Unicode字符隐藏，或伪装成技术要求。

GitHub特别指出，问题和评论中不可见的Unicode和隐藏消息是编程代理的提示注入风险。其缓解措施包括过滤隐藏内容、限制触发代理的人员、限制代理分支以及在工作流运行前要求人工审批。 (github.blog)

典型的攻击链

常见的攻击序列如下：

1. 攻击者创建一个公共问题。
2. 该问题包含针对编程代理的指令。
3. 代理在执行合法分类时读取该问题。
4. 注入的指令诱使代理安装包、修改工作流、读取文件或调用工具。
5. 代理使用其现有权限。
6. 攻击者获取秘密信息或获得进入发布流程的路径。

重点是，攻击者无需直接击败模型。他们只需要模型将不受信任的数据视为授权指令。

为什么提示过滤不足

关键词过滤很弱，因为攻击可以是：

• 被改写。
• 分散在多个文件中。
• 被编码。
• 隐藏在工具描述中。
• 延迟到后续会话。
• 与合法任务结合。
• 通过受损的包或缓存传递。
• 使用允许的命令而非明显危险的命令执行。

正确的架构响应是分离：

• 代理可以读取的数据
• 代理可以遵循的指令
• 代理可以执行的操作
• 这些操作所需的审批

文件可以被读取但不具有权威性。工具结果可能有用但不允许发出命令。问题可以被处理但不允许触发发布工作流。

威胁类别二：工具链利用

代理本身只是攻击面的一部分。周围的工具链通常提供实际的漏洞利用。

Shell和命令执行

Shell工具带来的风险包括：

• 命令注入。
• Shell元字符。
• 环境变量操纵。
• 别名和路径替换。
• 符号链接。
• Shell启动文件。
• 包生命周期脚本。
• 解释器混淆。
• 命令允许列表绕过。
• 隐藏在看似安全包装器中的危险命令。

Cursor披露了一个漏洞，其中某些shell内置命令可以在代理以自动模式运行时，即使有允许列表也可能被执行。当与提示注入结合时，该问题可能导致任意代码执行。 (github.com)

钩子和代码库控制的配置

项目配置可能比源代码更危险，因为它可能控制代理或开发环境自动执行的内容。

Check Point 研究报告了Claude Code项目配置中的漏洞，涉及钩子、模型上下文协议服务器初始化和环境变量。一个恶意代码库可能导致在项目打开时执行shell命令，可能在用户完全审查信任提示之前。 (research.checkpoint.com)

一般的教训是：

永远不要将代码库控制的代理配置视为无害的元数据。

使用代码所有权规则和明确审查来保护代理指令文件、工作区设置、钩子定义、工具配置和环境模板等配置文件。

基本集成开发环境功能

IDEsaster研究表明，基本开发环境本身可以成为代理攻击原语。在报告的攻击链中，代理利用合法的文​​件编辑功能更改设置或创建引用，导致开发环境发出外部请求或执行代码。该研究报告了30多个漏洞，分配了24个常见漏洞和暴露标识符，以及所有测试的AI集成开发工具中的漏洞。 (maccarita.com)

这使得威胁模型从：

模型 → 代理工具 → 操作系统

扩展到：

模型 → 代理工具 → 开发环境功能 → 操作系统或网络

模型上下文协议和工具投毒

模型上下文协议服务器可以包含其自身工具的描述。恶意服务器可能在这些描述中植入隐藏指令，指示模型读取敏感文件、调用另一个工具或将数据发送到其他地方。

Invariant Labs将此描述为工具投毒攻击，并演示了恶意工具描述如何导致代理滥用受信任工具并窃取数据。 (invariantlabs.ai) OWASP也类似地将工具投毒描述为通过外部工具元数据传递的间接提示注入。 (owasp.org)

控制措施应包括：

• 批准工具的私有注册表。
• 每个工具服务器的加密身份。
• 人工可读的权限清单。
• 独立的读取和写入工具。
• 模型之外的工具参数验证。
• 不自动信任工具描述。
• 监控改变其描述的工具。
• 工具服务器凭证和代理凭证之间的隔离。
• 调解每次工具调用的网关。

威胁类别三：秘密信息泄露

代理在哪里发现秘密信息

代理可能在以下位置发现凭证：

• 环境变量。
• Shell历史记录。
• 安全外壳配置。
• 云命令行配置。
• Git凭证文件。
• 包管理器配置。
• 本地代理配置。
• 进程参数。
• 进程内存。
• 构建日志。
• 测试夹具。
• 数据库连接字符串。
• 挂载的主机目录。
• 拉取请求输出。
• 缓存的依赖项。

GitHub的架构文档警告说，一个被提示注入并具有shell访问权限的代理可能会检查配置文件、安全外壳密钥、进程状态和工作流日志。然后，它可以将秘密信息通过网络发送或编码在公共代码库对象中，例如问题、拉取请求和评论。 (github.blog)

Nx Console的事件后分析展示了一个相关的供应链问题：贡献者机器上的恶意软件从本地可访问的凭证文件中检索了一个GitHub命令行令牌，并在几秒钟内使用它。 (nx.dev)

泄露通道

安全部署必须假定攻击者将使用不仅仅是直接的web请求。可能的通道包括：

• HTTP和安全HTTP请求。
• 域名系统查询。
• 包注册表请求。
• Git推送操作。
• 拉取请求评论。
• 问题标题和描述。
• 提交消息。
• 远程模式引用。
• 图像或文档上传。
• 搜索查询。
• 工具参数。
• 错误消息。
• 时间和服务量模式。
• 用作中继的受信任第三方服务。

IDEsaster研究描述了一种数据泄露路径，其中开发环境自动请求了一个远程JSON模式，该模式在URL参数中包含敏感数据。即使在人类审查差异时，也可能发生此请求。 (maccarita.com)

最强的秘密信息控制

最强的规则是：

不要让代理访问它不需要的秘密信息。

GitHub的代理工作流架构将模型认证令牌和模型上下文协议凭证放置在独立的受信任代理容器中，而不是代理容器内部。代理通过代理通信，而不是直接读取凭证。 (github.blog)

一个好的秘密信息设计使用：

• 短期凭证。
• 按代码库和按任务范围。
• 按工具权限。
• 即时颁发。
• 会话结束后自动撤销。
• 尽可能不在环境变量中放置凭证。
• 不在持久内存中放置凭证。
• 不在日志中放置凭证。
• 不访问主机用户的凭证目录。
• 独立监控每个凭证的使用。

秘密信息编辑仍然有用，但它是一种备用控制。编辑可能会遗漏编码、转换、分割、压缩或间接传输的秘密信息。

威胁类别四：数据投毒和内存投毒

代码库和依赖投毒

数据投毒发生在攻击者更改代理用于推理的信息时。

示例包括：

• 指示代理禁用安全检查的README文件。
• 包含虚假操作要求的测试夹具。
• 推荐恶意安装命令的依赖项描述。
• 悄悄更改工具权限的配置文件。
• 指示代理上传日志的生成错误消息。
• 投毒缓存包含修改后的依赖项。
• 更改表面任务的拉取请求评论。

代理可能会将所有这些视为同一个对话上下文的一部分，尽管它们具有不同的权限级别。

持久内存投毒

内存投毒更严重，因为恶意指令可以在原始会话结束后仍然存在。

Cisco描述了一个Claude Code内存投毒场景，其中正常的开发人员工作流导致恶意或不安全的指导被存储并在后续会话中传递。 (blogs.cisco.com) OWASP将内存和上下文投毒描述为一种独特的代理安全风险，因为持久状态可以在原始攻击者控制的输入消失后很久，仍然影响未来的行为。 (genai.owasp.org)

因此，内存应被视为配置数据库，而不是无害的笔记。

所需的控制措施包括：

• 将受信任策略与学习到的内存分离。
• 在持久写入前要求审查。
• 记录每个内存项的来源。
• 为内存分配过期日期。
• 防止秘密信息进入内存。
• 支持回滚到已知良好内存状态。
• 扫描内存以查找类似指令的内容。
• 在禁用内存的情况下测试行为。
• 为每个代码库、用户和环境维护独立的内存。
• 不允许不受信任的代码库内容写入全局内存。

威胁类别五：供应链风险

自主编程代理在五个方向上扩大了软件供应链风险。

包和安装脚本

代理在读取投毒指令后可能会安装恶意依赖项。包生命周期脚本可以立即执行并可能访问本地凭证。

2025年Nx妥协事件表明，被盗的发布令牌如何使恶意包能够扫描用户系统、与本地人工智能工具交互，并将收集到的数据上传到公共代码库。Nx报告称，恶意包可用了大约四个小时。 (nx.dev)

技能和代理扩展

代理技能通常包含指令、脚本、工具定义和访问要求。Snyk在2026年对两个公共技能生态系统中3,984个技能的审计报告显示，存在大量不安全和恶意内容。这些数字是扫描结果而非确认的泄露，但它们表明代理技能市场应被视为不受信任的软件注册表，而不是应用商店。 (snyk.io)

开发环境扩展

扩展可以访问源代码、文件、终端、凭证和网络服务。恶意或受损的扩展可能会直接攻击开发人员或改变代理的行为。

构建缓存

构建缓存可以跨越信任边界。低权限工作流可能会写入一个缓存工件，而高权限发布工作流随后会使用该工件。这甚至在原始工作流没有直接访问发布秘密信息的情况下，也创建了一条从问题处理到凭证盗窃的路径。

模型、提示和工具定义

模型更新或提示更改可能会改变代理解释指令的方式。工具更新可能会引入新的默认权限或更改命令的解析方式。

每个生产代理部署都应版本化并批准：

• 模型标识符。
• 系统指令。
• 开发人员指令。
• 工具定义。
• 策略规则。
• 容器镜像。
• 依赖项锁定文件。
• 网络策略。
• 秘密信息配置。
• 内存模式。
• 评估套件。

2025年和2026年的显著事件和披露

以下列表区分了操作事件、安全公告和受控研究披露。

Replit事件是通过用户报告和高管回应公开描述的，而不是传统的安全公告。Replit随后强调了开发与生产分离、快照、回滚以及对代理访问生产数据库的限制。 (fastcompany.com)

Cline事件尤其重要，因为它展示了此威胁模型中所有主要类别的组合：提示注入、工具执行、缓存投毒、秘密信息盗窃、供应链入侵和在下游开发人员系统上的自动安装。Cline的公告确认了未经授权的包发布，而研究人员的时间线描述了之前的代理工作流和缓存攻击链。 (github.com)

评估主要控制模式

没有单一的控制措施是足够的。最好的部署结合了几个独立的层。

能力沙箱

沙箱是最有价值的控制措施之一，因为即使代理行为恶意，它们也能减少爆炸半径。Anthropic将进程沙箱、虚拟机、文件系统边界和出站控制描述为控制自主行为的主要方式。 (anthropic.com)

然而，沙箱必须被视为软件安全边界。Codex漏洞表明，路径配置逻辑中的错误可能会破坏预期的工作区边界。 (github.com)

一个强大的沙箱应包括：

• 一次性虚拟机或加固容器。
• 无法访问开发人员的主目录。
• 无法访问安全外壳密钥或云命令行凭证。
• 挂载在已知路径的专用工作区。
• 对基础镜像的只读访问。
• 无特权容器模式。
• 受限的进程创建。
• CPU、内存、磁盘和执行时间配额。
• 无法访问生产网络。
• 任务完成后自动销毁。
• 用于审查的最终工作区快照或工件。

策略引擎

策略引擎应位于模型和工具之间。它不应依赖模型进行自我审查。

与其允许代理发出任意shell命令，不如暴露类型化操作，例如：

• 在工作区内读取文件。
• 在工作区内写入文件。
• 运行批准的测试命令。
• 从批准的注册表安装依赖项。
• 创建分支。
• 打开拉取请求。
• 请求部署审批。

策略引擎应独立验证：

• 用户身份。
• 代码库。
• 目标路径。
• 命令或工具。
• 数据分类。
• 目标位置。
• 预期的副作用。
• 审批状态。
• 会话剩余预算。

可复现的工具执行

可复现性通常被视为构建质量特性，但它也是一种安全控制。

对于每次代理运行，记录：

• 确切的模型版本。
• 确切的代理版本。
• 确切的工具版本。
• 容器镜像摘要。
• 依赖项锁定文件。
• 代码库提交。
• 网络策略。
• 策略版本。
• 工具调用序列。
• 生成的工件哈希。

NIST的安全软件开发框架强调安全开发环境和收集软件组件的来源数据。 (csrc.nist.gov)

不要使用可变值，例如：

• 最新包版本。
• 未固定的容器标签。
• 未经审查的远程脚本。
• 浮动工具定义。
• 未经验证的分支名称。
• 跨特权级别的共享缓存。

秘密信息编辑和代理

秘密信息编辑应在多个点进行操作：

1. 在内容进入模型上下文之前。
2. 在发送工具参数之前。
3. 在返回工具输出之前。
4. 在存储日志之前。
5. 在提交文件之前。
6. 在网络请求离开运行器之前。
7. 在创建评论、问题和拉取请求之前。

专用的秘密代理比环境变量更强大。代理要求代理执行一个狭义定义的操作，例如下载私有包，而无需接收原始凭证。

出站过滤

网络访问应默认拒绝。

一个实用的出站代理应记录：

• 目标域名和地址。
• 请求方法。
• 请求大小。
• 响应大小。
• 请求身份。
• 发起请求的工具。
• 是否存在敏感数据。
• 目标是否获得批准。
• 请求是否在敏感审批操作期间发生。

GitHub的代理工作流架构使用专用防火墙、受信任的模型上下文协议网关和隔离的模型认证代理。 (github.blog)

出站控制还必须考虑间接通道。对受信任的源代码控制服务的请求仍可能创建包含被盗数据的恶意问题或拉取请求。因此，网络控制必须与安全输出规则和内容扫描相结合。

推荐的参考架构

安全的自主编程部署应包含这些层：

1. 上下文摄取层

该层收集代码库文件、问题、测试结果和工具输出。它应按以下方式标记每个项目：

• 来源。
• 信任级别。
• 作者。
• 时间戳。
• 代码库。
• 数据分类。
• 是否包含可执行内容。
• 是否包含指令。

2. 指令和数据分离

代理应收到明确声明，即代码库内容、工具输出、网页和问题文本是数据，除非另行授权。

系统应保留每个上下文片段的来源，而不是将所有内容扁平化为单一的、无差别的提示。

3. 策略执行点

每次工具调用都应通过一个策略引擎，该引擎检查：

• 身份。
• 能力。
• 目标。
• 参数。
• 数据敏感性。
• 网络目标。
• 审批要求。
• 资源预算。

4. 能力代理

代理接收临时能力而非广泛凭证。代理应为当前步骤颁发所需的最小权限，并在之后撤销。

5. 隔离的执行环境

代理在一次性环境中运行，具有：

• 无生产连接。
• 无开发人员凭证挂载。
• 无法访问不相关的代码库。
• 受限的文件系统范围。
• 严格的资源限制。
• 不可变的基础镜像。

6. 工具网关

通过网关访问外部工具，该网关执行：

• 工具身份验证。
• 参数验证。
• 速率限制。
• 输出过滤。
• 权限检查。
• 审计日志记录。
• 凭证隔离。

7. 出站代理

所有外部通信都通过受控代理。应阻止来自代理的直接网络访问。

8. 安全输出暂存

代理应生成：

• 一个补丁。
• 一个分支。
• 一个更改请求。
• 一个部署提案。
• 一个包候选。

它不应直接合并、部署、发布或更改生产状态。

9. 独立审查和提升

一个独立过程使用以下方法审查提议的输出：

• 秘密信息扫描。
• 静态安全分析。
• 依赖项分析。
• 许可证和来源检查。
• 测试结果。
• 策略验证。
• 人工审查高影响更改。

GitHub的云代理遵循类似模式，通过创建草稿拉取请求、限制分支访问、要求人工审查、限制工作流执行和提供会话日志。 (docs.github.com)

可操作的缓解措施清单

启用代理之前

• 为代理创建库存条目。
• 确定代理所有者和业务目的。
• 记录代理可以访问的每个工具、连接器和外部服务。
• 记录代理可以访问的每个凭证。
• 确认没有生产凭证存在。
• 在一次性环境中运行代理。
• 除非明确批准，否则禁用自动包安装。
• 禁用不受限制的网络访问。
• 固定模型、代理、工具、依赖项和容器镜像。
• 使用代码所有权规则保护代理指令文件和配置文件。
• 定义哪些操作需要人工审批。
• 定义最大会话持续时间和成本。
• 创建回滚计划。

允许代码库访问之前

• 将代码库分类为公共、内部、机密或高度受限。
• 审查所有由代码库控制的代理配置。
• 将README文件、问题内容、评论和测试输出视为不受信任。
• 禁用钩子和工作区命令的自动执行。
• 扫描依赖项和安装脚本。
• 使用干净、隔离的工作区。
• 阻止访问不相关的代码库。
• 验证工作区或构建日志中不存在秘密信息。
• 使用恶意问题文本和投毒文档进行测试。
• 记录代码库提交和代理配置哈希。

允许工具使用之前

• 尽可能用类型化操作替换任意shell访问。
• 对工具和目标使用允许列表。
• 在规范化后验证路径。
• 拒绝符号链接逃逸。
• 阻止工具修改自己的策略文件。
• 阻止代理更改自己的审批模式。
• 在包含敏感数据的网络访问前要求确认。
• 记录每个工具调用及其结果。
• 设置文件大小、命令时间、网络流量和令牌使用的限制。
• 审查模型上下文协议服务器描述和权限。
• 拒绝未签名或未验证的工具定义。

允许代码发布或部署之前

• 要求代理和人工发起者具有独立的身份。
• 在合并前要求人工审查。
• 在部署前要求独立审批。
• 使用短期发布凭证。
• 使用受信任的发布或工作负载身份代替长期令牌。
• 要求工件签名和来源。
• 扫描秘密信息和恶意依赖项。
• 从没有共享可变缓存的干净环境中构建。
• 验证工件与审查过的源代码匹配。
• 维护快速的包或扩展回滚流程。
• 测试备份和快照的恢复。

事件响应期间

• 终止受影响的代理会话。
• 隔离运行器或工作站。
• 撤销代理可用的所有凭证。
• 撤销工具和连接器可用的凭证。
• 保留会话、工具、网络和源代码控制日志。
• 检查提交、问题、拉取请求、评论和包发布。
• 检查缓存和安装脚本。
• 将已发布的工件与受信任的来源进行比较。
• 搜索未经授权的出站目的地。
• 审查持久内存和配置文件。
• 通知代码库、包注册表和工具供应商。
• 如果凭证可能已暴露，在取证分析后再次轮换凭证。
• 记录是否有数据离开了批准的环境。

提议的安全服务水平协议

这些是提议的部署目标，并非通用的行业标准。组织应根据其风险承受能力进行调整。

对于高度敏感的环境，最重要的服务水平协议应该是零次成功的关键路径泄露，而不是平均检测率。一次成功的发布令牌盗窃可能比数千次无害的阻止尝试更具破坏性。

每个部署都应生成的审计工件

成熟的部署事后应该能够回答：

• 谁启动了代理？
• 涉及哪些用户和服务身份？
• 使用了哪个代码库和提交？
• 运行了哪个模型和代理版本？
• 哪些指令处于活动状态？
• 哪些外部内容进入了上下文？
• 哪些工具可用？
• 实际调用了哪些工具？
• 发送了哪些参数？
• 读取或更改了哪些文件？
• 联系了哪些网络目的地？
• 请求了哪些凭证？
• 哪些策略允许或拒绝了每个操作？
• 获得了哪些人工审批？
• 生成了哪个工件？
• 发布了哪个工件？
• 最终处置是什么？

至少保留以下工件：

1. 代理库存记录
2. 威胁模型和数据流图
3. 能力和权限清单
4. 工具和连接器库存
5. 模型、提示和策略版本记录
6. 容器镜像和依赖项物料清单
7. 网络策略和出站日志
8. 秘密信息暴露和编辑报告
9. 会话和工具调用追踪
10. 人工审批记录
11. 安全评估和红队报告
12. 发布来源和工件签名
13. 内存来源和回滚记录
14. 事件响应和恢复测试
15. 供应商安全公告和补丁记录

日志应具有防篡改性、访问控制性，并根据数据敏感性进行保留。普通开发会话可能需要保留90天，而访问发布系统、受监管数据或高价值代码库的会话可能需要一年或更长时间。

OpenAI描述了内部监控，审查编程代理交互、工具调用和潜在可疑行为，而GitHub强调会话日志、签名提交、归属和审计记录。这些模式支持更广泛的原则：代理行为必须独立于代理自身对所做事情的解释而可观察。 (openai.com)

第一个实用步骤

最好的第一步不是将代理部署到生产代码库。

相反：

1. 创建一个临时测试代码库。
2. 给代理一个只读任务。
3. 在全新的沙箱中运行它。
4. 关闭对开发人员凭证的访问。
5. 阻止除模型提供商之外的所有网络流量。
6. 添加一个故意的恶意问题、README指令、工具描述和配置文件。
7. 记录所有尝试的文件访问、工具调用、命令和网络请求。
8. 使用结果创建您的第一个权限清单和安全服务水平协议。

如果代理在这些条件下无法安全地完成只读任务，那么它尚未准备好进行写入访问、发布自动化或生产系统。

结论

自主编程代理应被视为不受信任、具有身份的自动化系统，而不是普通的开发人员工具。

决定性的安全问题不是：

“模型会遵循正确的指令吗？”

而是：

“如果模型在拥有真实权限的同时遵循了错误的指令，会发生什么？”

提示注入、工具利用、秘密信息盗窃、数据投毒和供应链入侵是导致相同底层故障的不同入口点：代理被允许跨越太多的信任边界而没有独立的强制执行。

2025年和2026年的事件表明，最有效的控制是架构性的：

• 让代理远离秘密信息。
• 使用一次性能力沙箱。
• 在模型之外强制执行策略。
• 将开发与生产分离。
• 将配置和内存视为可执行攻击面。
• 使用受控的出站。
• 从特权发布工作流中移除共享缓存。
• 固定并验证每个工具和工件。
• 分阶段执行所有写入。
• 对不可逆操作要求独立审批。
• 保留详细、防篡改的审计记录。

自治可能有用且安全，但前提是系统设计得当，使得混淆、被操纵或受损的代理具有有限的权限、有限的范围、有限的时间和清晰可恢复的故障模式。