四大AI编程代理曝出相同安全漏洞：企业如何构建AI Agent的“技能”安全审计体系？

【软盟资讯·新闻导读】近日，多家媒体援引网络安全公司 Air 的披露称，Claude Code、OpenAI Codex、Gemini CLI 和 GitHub Copilot 等 AI 编程代理的“技能”更新机制存在相似风险：攻击者可能伪装同名技能，借更新链路诱导代理执行恶意指令，进而接触代码、凭证或开发环境数据。无论具体产品后续如何修复，这一事件都说明，企业不能只审查模型输出，还必须把 Agent 的技能供应链、工具调用和运行行为纳入统一安全体系。

“技能”为什么会成为新的攻击面

传统软件通常通过安装包、依赖库和插件扩展能力。AI Agent 的“技能”与之类似，但风险更复杂：它不只是被程序调用的代码，也可能包含供模型理解的说明、工具参数、执行步骤和环境约束。

当编程代理根据任务动态选择技能时，攻击链可能由以下环节组成：

1. 用户提出开发或运维任务。
2. Agent 发现本地或远程技能，并读取技能说明。
3. 技能引导 Agent 调用终端、文件系统、代码仓库或网络工具。
4. Agent 在当前身份和环境权限下执行操作。
5. 恶意指令通过输出、文件、日志或工具返回结果继续影响后续决策。

这意味着，技能文件即使没有直接包含明显的恶意程序，也可能通过提示注入、隐蔽参数、异常工具组合或伪造错误信息，改变 Agent 的行为。

据公开报道，此次风险集中在“技能”自动更新机制：攻击者可能以同名内容伪装合法更新，利用校验不足或信任关系绕过安全检查。相关信息可参考虎嗅的报道以及36氪快讯。目前公开资料主要描述了共性逻辑风险，企业不应据此推断某个具体版本一定已经遭到攻击，也不应把媒体披露直接等同于厂商最终漏洞公告。

企业真正面对的是“能力供应链”风险

如果只把这类问题理解为一次插件漏洞，防御范围就会过窄。企业需要关注的是一条完整的 Agent 能力供应链：

其中最容易被忽视的是“合法技能执行恶意组合”。单个动作可能看似正常，例如读取项目配置、执行测试命令或访问依赖仓库；但多个动作串联后，可能形成凭证搜索、代码打包和外传路径。

因此，传统静态代码审计仍然必要，却无法独立解决 Agent 安全问题。企业需要将审计对象从“代码是否有漏洞”扩展为“技能在什么身份下，以什么顺序调用了哪些工具，并影响了哪些数据”。

从静态审计转向动态行为监控

先建立技能资产清单

企业应为每个技能建立可追踪的资产记录，至少包括：

• 唯一名称、版本号和来源仓库；
• 发布者、维护者和业务负责人；
• 内容哈希、签名信息和最近更新时间；
• 可调用工具及其参数范围；
• 可访问的目录、网络地址和数据类型；
• 适用环境，例如开发、测试还是生产；
• 审批记录、风险等级和回滚版本。

技能不能因为“只是一个提示词文件”就被排除在资产管理之外。只要它能够改变 Agent 的工具选择或执行路径，就应当像代码依赖、CI 插件和基础设施脚本一样纳入供应链治理。

更新必须从“自动信任”改为“可验证变更”

技能更新至少应经过以下检查：

1. 来源校验：确认仓库、发布者和提交权限是否符合白名单。
2. 完整性校验：对技能包和关键文件进行哈希或数字签名验证。
3. 差异审查：比较新旧版本在指令、工具权限、网络地址和脚本上的变化。
4. 风险扫描：识别敏感文件读取、命令执行、数据外传和提示注入特征。
5. 隔离试运行：在无生产凭证、受限网络和临时目录中运行。
6. 人工审批：高风险变更由技能负责人和安全人员共同确认。
7. 可回滚发布：保留上一稳定版本，并能够快速禁用新版本。

一个简化的技能元数据示例可以是：

name: repository-review
version: 1.4.2
source: internal-registry
digest: sha256:replace-with-approved-digest
allowed_tools:
  - read_file
  - search_code
  - run_test
network:
  mode: deny-by-default
filesystem:
  read:
    - /workspace/project
  write:
    - /workspace/project/test-results
secrets:
  access: none
approval:
  required: true
risk_level: medium

这类配置不能替代安全产品或运行时控制，但可以把“技能能做什么”从自然语言承诺转化为可检查的策略对象。

权限隔离：不要让 Agent 继承开发者的全部能力

Agent 安全的核心不是“让模型永远不犯错”，而是即使模型被误导，错误行为也不能轻易扩大影响。

按任务划分身份

企业不应让所有编程任务共用一个长期有效的高权限账号。更合理的方式是为不同任务分配短时、最小化的身份：

• 代码阅读：只读代码仓库和文档目录；
• 单元测试：允许访问临时构建目录，不允许读取生产密钥；
• 依赖更新：仅允许访问经过批准的镜像源；
• 发布操作：必须人工确认，并使用一次性凭证；
• 生产运维：默认禁止由通用编程代理直接执行。

权限应同时绑定用户、Agent、技能、项目、环境和任务上下文。单纯依靠“用户本人有权限，所以 Agent 也有权限”的继承模式，容易造成权限逃逸。

采用分层隔离

一个可落地的运行架构可以分为四层：

1. 控制层：负责技能注册、版本审批、策略下发和熔断。
2. 代理层：运行模型和任务编排，不直接持有长期高权限凭证。
3. 工具网关层：统一代理访问文件、代码仓库、数据库和网络服务。
4. 执行沙箱层：在容器或微虚拟机内执行命令，限制文件、网络和系统调用。

所有高风险工具都应经过工具网关，而不是由 Agent 直接访问。网关可以检查调用者身份、技能版本、目标资源、参数范围和审批状态，并将完整调用记录写入审计系统。

动态审计应该记录什么

只记录最终回答远远不够。一次 Agent 任务至少需要形成可关联的事件链：

{
  "task_id": "task-2026-0001",
  "agent_id": "agent-dev-test",
  "skill": "repository-review@1.4.2",
  "tool": "run_test",
  "target": "/workspace/project",
  "network": "denied",
  "credential_scope": "none",
  "approval": "pre-approved",
  "result": "success",
  "timestamp": "2026-09-18T10:00:00Z"
}

实际系统中还应记录：

• 模型接收到的任务和关键上下文；
• 技能版本及其内容摘要；
• 工具调用顺序和参数；
• 访问过的文件、仓库、接口和数据分类；
• 被拒绝的调用及拒绝原因；
• 网络连接、文件打包和异常输出行为；
• 人工确认、策略变更和应急禁用操作。

审计的重点不是无限保存所有模型对话，而是保证一次高风险行为能够被还原：谁发起了任务、哪个 Agent 选择了哪个技能、技能调用了什么工具、工具访问了什么资源、结果是否流向外部。

建立一套可执行的落地路线

第一阶段：盘点和止血

适用于已经在企业内部使用 AI 编程代理的团队：

• 暂停不必要的自动技能更新；
• 导出当前使用的技能和插件清单；
• 禁止代理直接读取生产密钥、个人凭证和全量代码库；
• 对技能目录、配置文件和外连日志进行基线留存；
• 检查是否存在异常同名文件、未知仓库来源或近期权限变化；
• 为高风险技能设置人工确认。

这一阶段的目标不是马上完成完整平台建设，而是先切断“自动更新—自动执行—高权限访问”的连续链路。

第二阶段：纳入研发安全流程

将 Agent 技能纳入现有 DevSecOps 流程：

• 技能变更进入代码评审或安全评审；
• 在 CI 中执行内容差异、依赖、脚本和敏感操作扫描；
• 为技能生成软件物料清单或等价的能力清单；
• 在测试环境执行攻击模拟，包括提示注入、工具越权和数据外传；
• 将技能版本与项目、Agent 身份和部署环境绑定；
• 把拒绝事件、异常调用和高风险行为接入安全运营平台。

第三阶段：建立运行时防御

当 Agent 开始进入生产流程后，应增加运行时控制：

• 默认拒绝未登记的工具和网络目的地；
• 对读取密钥、批量导出、修改权限、删除文件等操作强制人工确认；
• 对异常调用频率、非预期目录访问和数据体积变化进行告警；
• 为每个任务设置时间、调用次数、网络流量和数据范围上限；
• 提供按技能、Agent、项目和环境维度的快速熔断；
• 保留可验证的审计日志，防止运行后被覆盖或修改。

企业应如何判断防护是否有效

可以用几个工程指标持续评估：

安全控制不能只追求“全部禁止”。如果审批流程过重，开发团队可能转向个人设备、非受控账号或未经批准的 Agent，反而形成新的影子使用风险。更合理的做法是按任务和数据敏感度分级：低风险只做自动校验，中风险需要沙箱和策略审批，高风险必须人工确认并限制执行环境。

结语

“技能劫持”暴露的并不只是某个更新接口或某种插件机制的问题，而是 AI Agent 进入研发和企业流程后，传统身份、权限、供应链和运行时安全边界被重新组合。企业如果仍以“模型输出审核”作为主要防线，就难以覆盖 Agent 自主选择工具、读取上下文和执行连续动作带来的风险。

对技术负责人而言，优先级应当是明确 Agent 的身份边界，冻结不必要的自动更新，建立技能资产清单和版本校验，再通过工具网关、沙箱和动态审计逐步扩展使用范围。对安全架构师而言，真正需要保护的对象已经从单一代码文件扩展到“技能—模型—工具—数据—身份”的完整调用链。

【软盟观察】这次共性风险值得关注之处，在于它提醒企业：AI Agent 的安全问题正在从模型层转向能力供应链和执行环境。静态扫描仍有价值，但它只能回答“文件看起来是否可疑”，不能回答“代理在真实任务中会如何组合工具、访问哪些数据”。未来的企业级 Agent 治理，很可能需要同时具备软件供应链安全、身份权限管理、数据防泄露和运行时检测能力。企业不必因为一次披露就全面停止使用 AI 编程工具，但应把默认信任改为分级授权，把自动执行改为可观测、可阻断、可回滚。只有当技能来源、权限范围和行为结果都能够被验证，Agent 才可能从个人效率工具稳步进入受控的生产环境。