AI Agent 沙箱配置安全审计实战：识别 Vector H 危险沙箱配置，阻断 CI Runner 上的任意代码执行

AI Agent 沙箱配置安全审计实战：识别 Vector H 危险沙箱配置，阻断 CI Runner 上的任意代码执行

【免费下载链接】anomalibAn anomaly detection library comprising state-of-the-art algorithms and features such as experiment management, hyper-parameter optimization, and edge inference.项目地址: https://gitcode.com/GitHub_Trending/an/anomalib

本篇技术指南是 anomalib 仓库内置的agentic-actions-auditor技能中Vector H（Dangerous Sandbox Configurations）参考文档的深度解读与实践扩充。它面向负责审查 GitHub Actions 工作流的开发者与安全工程师，帮助你在调用 Claude Code Action、OpenAI Codex、Gemini CLI 等 AI 编码 Agent 的 CI/CD 流水线中，识别"沙箱/安全策略被完全关闭"的配置级弱点，理解它如何将一次 prompt 注入从"文本影响"升级为"Runner 上的远程代码执行（RCE）"，并给出可落地的检测要点、漏洞模式与修复方案。读完本文，你将能够独立审计任意工作流中的 AI Action 步骤，定位Bash(*)、danger-full-access、--yolo等危险配置，并正确区分真正的高危发现与误报。

一、Vector H 的本质：配置级弱点，而非注入路径

Vector H 描述的场景是：AI Action 的沙箱或安全配置被设置为完全禁用保护的值，从而赋予 AI Agent 无限制的 Shell 访问、文件系统访问或免审批执行能力。它与其他向量（A–G）有一个根本区别：

• Vector A–G 解决的是"攻击者输入能否到达 AI"（注入路径）；
• Vector H 解决的是"注入一旦成功，爆炸半径有多大"（配置弱点）。

正如 Vector H 参考文档 所强调的，这类配置级弱点会放大任何 prompt 注入向量的影响——把"攻击者可以影响 AI 文本输出"转变为"攻击者在 CI Runner 上实现任意代码执行"。

在 agentic-actions-auditor 技能主文档 中，该技能明确定义了审计范围：静态审查 GitHub Actions 工作流中调用 AI 编码 Agent（Claude Code Action、Gemini CLI、OpenAI Codex、GitHub AI Inference）的集成，检测攻击者可控输入到达 CI/CD 流水线中 AI Agent 的攻击向量，其中明确包含"危险沙箱配置"与"通配符用户白名单"。Vector H 正是这一技能中 9 个检测向量（A–I）的第八个。

二、适用动作与风险面

并非所有 AI Action 都具备"可配置的沙箱"。参考文档给出了精确的适用性判定：

关键结论：GitHub AI Inference 不适用 Vector H，因为它是仅推理的 API 调用，没有 Shell 访问可被配置关闭。这一分类在 action-profiles.md 中有更细的佐证——GitHub AI Inference 的默认安全姿态即为"无 Shell 访问、无文件系统访问、无可配置沙箱"。

三、触发事件与数据流模型

触发事件：任何事件均可。Vector H 关注的是 Action 的配置而非触发条件——触发条件决定攻击者输入能否到达 AI，本向量决定 prompt 注入成功后的爆炸半径。

数据流：Vector H 没有直接的数据流，它是一个配置弱点。其危险性可用如下模型概括：

ANY prompt injection vector (A-F) succeeds + sandbox/safety protections disabled (this vector) = unrestricted code execution on the runner

即：没有危险配置时，一次成功的 prompt 注入仍可能被工具限制和沙箱边界约束；存在危险配置时，AI Agent 对 Shell、文件系统、环境变量和网络拥有完全访问权。

四、逐 Action 检测要点

参考文档为三类适用 Action 提供了明确的"找什么"指引。这些检测点全部落在 AI Action 步骤的with:块中。

4.1 Claude Code Action（anthropics/claude-code-action）

• with.claude_args包含--allowedTools Bash(*)或--allowedTools "Bash(*)"——无限制 Shell 访问，AI 可执行任意命令；
• with.claude_args包含跨多个无限制类别的宽泛工具模式（如Bash(npm:*) Bash(git:*) Bash(curl:*)）；
• with.settings指向外部 settings 文件——需标记人工复核，该文件可能以工作流 YAML 中不可见的方式覆盖工具权限。

4.2 OpenAI Codex（openai/codex-action）

• with.sandbox: danger-full-access——禁用全部文件系统限制，AI 可读写 Runner 上任意位置；
• with.safety-strategy: unsafe——对所有操作禁用安全执行；
• 两者同时出现代表最大暴露：无限制文件系统 + 无安全检查。

4.3 Gemini CLI（google-github-actions/run-gemini-cli、google-gemini/gemini-cli-action）

• with.settingsJSON 包含"sandbox": false——完全禁用沙箱；
• CLI 参数包含--yolo或--approval-mode=yolo——对所有工具调用禁用审批提示，AI 无需确认即执行命令；
• with.settingsJSON 中包含无限制run_shell_command的宽泛coreTools列表（与 Vector F 的具体工具分析相关）。

4.4 检索位置

审计时聚焦 AI Action 步骤的with:块：

• Claude：解析with.claude_args字符串中的--allowedTools模式；同时检查with.settings的外部配置文件路径；
• Codex：直接检查with.sandbox与with.safety-strategy字段值；
• Gemini：解析with.settingsJSON 字符串中的"sandbox": false与审批模式设置；检查所有 args 风格字段中的--yolo或--approval-mode=yolo。

这些字段名在技能主文档 SKILL.md 的"Step 3a：捕获步骤级安全上下文"中均有对应记录，是审计流程中必须捕获的安全相关输入字段。

五、漏洞示例：三个危险配置的完整模式

参考文档给出了来自研究 Example 8 的三段真实漏洞模式 YAML，完整复现如下：

# Claude Code Action -- unrestricted shell - uses: anthropics/claude-code-action@v1 with: claude_args: "--allowedTools Bash(*)" prompt: "Review this issue and fix the code" # OpenAI Codex -- unrestricted filesystem + no safety - uses: openai/codex-action@v1 with: sandbox: danger-full-access safety-strategy: unsafe prompt: "Fix the bug described in this issue" # Gemini CLI -- sandbox disabled - uses: google-github-actions/run-gemini-cli@v1 with: settings: | {"sandbox": false} prompt: "Analyze and fix this issue"

注意三者的共性：危险配置全部隐藏在with:块中，工作流 YAML 表面看起来"只是调用了一次 AI Action"，但从安全视角看，它们分别禁用了 Shell 限制、文件系统限制和沙箱边界，任何一个 prompt 注入向量（如 Vector B 直接表达式注入、Vector A 环境变量中介）成功，都会直接落入无保护执行。

六、为什么重要：无保护 AI Agent 的能力边界

参考文档明确指出，没有沙箱限制时，AI Agent 可以：

• 在 Runner 上执行任意 Shell 命令；
• 读写 Runner 文件系统上的所有文件；
• 访问环境变量，包括GITHUB_TOKEN与仓库 Secrets；
• 发起出站网络请求（数据外泄）；
• 修改仓库内容、创建 Release 或推送代码。

结合技能主文档 SKILL.md 中"要拒绝的合理化借口"第四条——"沙箱能防止任何实际损害"——可以更深刻地理解这一点：danger-full-access、Bash(*)、--yolo等错误配置会完全禁用保护；即便沙箱配置正确，只要 AI Agent 能读取环境变量或挂载文件，仍可能泄露 Secrets。沙箱边界的安全强度只取决于它的配置。

七、误报判定：哪些配置是安全的

审计最怕误报。参考文档给出了明确的 False Positives 清单，逐条继承如下：

• Claude 的具体受限工具模式：--allowedTools "Bash(npm test:*)"或--allowedTools "Bash(echo:*)"——这些是限制性配置而非危险配置（不过它们可能通过 Vector F 的子 Shell 展开被利用）；
• Codex 工作区级沙箱：sandbox: workspace-write允许写入但局限于工作区边界，并非完全系统访问；
• Gemini 具体工具列表：coreTools包含具体工具但不包含run_shell_command——属于工具级限制，而非完全禁用沙箱；
• 默认配置：未显式设置沙箱/安全配置字段的 Action——默认值通常是安全的（Claude 默认限制工具，Codex 默认sandbox: workspace-write，Gemini 默认沙箱启用）；
• Claude 窄模式--allowedTools：例如--allowedTools "Read(*) Grep(*)"——只读工具风险极小。

7.1 误报判定的底层依据

这些误报判定的正确性可以从 action-profiles.md 中每类 Action 的默认安全姿态得到交叉验证：

其中 Codex 的受保护路径（.git、.agents/、.codex/目录即使在可写沙箱中也是只读的）值得特别关注——这正是"工作区可写但非全系统访问"的落地机制。

八、在审计流程中如何落地：方法论串联

Vector H 参考文档是技能方法论中的一个向量模块。要正确使用它，需要把它放回 SKILL.md 的完整审计流程中：

1. Step 0/1：确定本地或远程分析模式，发现并读取工作流文件（.github/workflows/*.yml/*.yaml）；
2. Step 2：识别 AI Action 步骤，uses:值与anthropics/claude-code-action、openai/codex-action、google-github-actions/run-gemini-cli、google-gemini/gemini-cli-action、actions/ai-inference前缀匹配（忽略@后的版本）；
3. Step 3：捕获安全上下文——对 Vector H 而言，重点是各 Action 的沙箱/工具配置字段；
4. Step 4：按向量表逐一检测，Vector H 的快速检查是：danger-full-access、Bash(*)、--yolo、safety-strategy: unsafe；
5. Step 5：生成结构化报告。

8.1 严重度判断与放大机制

技能主文档对 Vector H 的严重度判定有专门规定：Vector H（危险沙箱配置）和 Vector I（通配符用户白名单）是配置弱点，它们放大共存的注入向量（A–G），本身不是独立的注入路径。没有共存的注入向量时，Vector H 或 I 单独出现只能评为 Info 或 Low——危险配置但无已证明的注入路径。

具体判断因素包括：

• 触发事件暴露面：面向外部的触发器（pull_request_target、issue_comment、issues）提升严重度；
• 沙箱与工具配置：危险模式（danger-full-access、Bash(*)、--yolo）提升严重度，限制性工具列表与安全默认值降低严重度；
• 数据流直接性：直接注入（Vector B）比间接多跳路径（Vector A/C/E）评级更高；
• 权限与 Secrets 暴露：过宽的github_token权限或广泛的 Secrets 可用性提升严重度。

报告时，配置弱点类发现需用"影响放大说明"替代数据流部分：说明该配置弱点在存在共存注入向量时会使攻击者达成何种后果。当 Vector H 与注入向量共存于同一步骤时，应在报告中注明配置弱点放大了注入发现的严重度。

8.2 跨文件审计的补充

AI Agent 也可能隐藏在 composite action 或可复用工作流中。参考 cross-file-resolution.md 的分类算法：./path/to/action为本地 composite action（读取其action.yml，检查runs.using: composite后扫描runs.steps[]），job 级uses:为可复用工作流（按完整工作流分析），解析深度固定为 1 层。在解析出的文件中找到 AI Action 后，同样对其with:块执行 Vector H 检测——危险沙箱配置不会因为藏在被引用的文件里就变得安全。

九、修复建议：恢复最小权限的默认姿态

针对三类 Action，action-profiles.md 提供了与 Vector H 直接对应的修复模式：

Claude Code Action——限制 Shell 访问：

claude_args: '--allowedTools "Bash(npm test:*) Bash(git diff:*)"'

移除Bash(*)，改用具体工具模式；在公开仓库保持show_full_output: false默认值防止日志泄密。

OpenAI Codex——收紧沙箱与安全策略：

sandbox: workspace-write # default: workspace access only, no network safety-strategy: drop-sudo # default: removes sudo privileges

分析型任务可进一步收紧为sandbox: read-only；更严格可选safety-strategy: unprivileged-user（以非特权用户运行）。组织层面可使用requirements.toml阻止danger-full-access，防止单个仓库削弱沙箱策略。

Gemini CLI——启用沙箱并移除危险审批模式：

settings: '{"sandbox": true}'

或通过--sandbox标志启用；从 CLI 参数中移除--yolo与--approval-mode=yolo，恢复要求工具调用确认的默认审批模式；若确需 Shell 访问，应使用基于容器的沙箱来限制爆炸半径，而非仅依赖内置沙箱 profile。

十、与其他向量的协同与延伸阅读

Vector H 并非孤立存在。审计时建议联动以下参考文档形成完整判断：

• Vector F：受限工具列表中的子 Shell 展开——Bash(echo:*)等"看似受限"的工具模式可能通过echo $(env)绕过限制实现任意命令执行，与 Vector H 同属工具/沙箱配置域；
• Vector I：通配符用户白名单——allowed_non_write_users: "*"、allow-users: "*"移除用户级门禁，与 Vector H 一样是放大注入影响的配置弱点；
• Shared Foundations：攻击者可控输入模型——理解github.event.*表达式、env:块求值时机与三类数据流路径，是判断"注入是否可能成功"的前提；
• Action Security Profiles——每类 Action 的默认安全姿态、危险配置模式与修复方案的完整速查表。

最终的审计结论应形成结构化报告：先用执行摘要（如 "Analyzed X workflows containing Y AI action instances. Found Z findings: N High, M Medium, P Low, Q Info"）概括，再按工作流分组、按严重度降序呈现每个发现，包含标题、严重度、文件、步骤（含行号）、影响、证据 YAML、数据流（或配置弱点的放大说明）与修复建议。记住这条核心判定原则：危险沙箱配置的价值不在于它本身，而在于它让任何一条 prompt 注入向量都直达 Runner 上的无限制代码执行。

【免费下载链接】anomalibAn anomaly detection library comprising state-of-the-art algorithms and features such as experiment management, hyper-parameter optimization, and edge inference.项目地址: https://gitcode.com/GitHub_Trending/an/anomalib