自主漏洞挖掘管线的安全边界：defending-code-reference-harness 的沙箱隔离与防护实践

人工智能AI Agent应用安全漏洞扫描【免费下载链接】defending-code-reference-harnessSkills for threat modeling, scanning, triage, patching, plus an autonomous scanning harness you can /customize项目地址https://gitcode.com/gh_mirrors/de/defending-code-reference-harness点击查看免费下载本指南基于仓库 docs/security.md 展开系统讲解该参考管线的安全模型为什么必须在代码层面强制约束 Agent、如何用 gVisor 内部网络 出口白名单代理把每次运行目标代码的自主扫描锁进隔离边界以及如何防范提示注入、分离构建与攻击阶段、安全退出沙箱。读完你可以独立完成沙箱搭建、隔离验证并安全地运行bin/vp-sandboxed驱动的自主漏洞挖掘流水线。一、TL;DR先记住三条安全红线仓库文档开篇给出了一段浓缩版安全指引可以提炼为三条不可妥协的红线自主管线必须通过bin/vp-sandboxed启动。该包装脚本会先验证沙箱是否就绪再把每一个 Agent 关进 gVisor 容器并将网络出口限制为仅能访问模型 API。绝不把承载凭据的路径挂载进 Agent 可达的任何环境例如~/.aws、.env。交互式技能无需沙箱但/customize需要人工审查。/threat-model、/vuln-scan、/triage、/quickstart只读写文件因此可以无沙箱运行而/customize会修改管线源码并可能执行验证命令批准前必须审查其提出的改动计划。之所以把第一条红线放在首位是因为本仓库的自主管线会真实执行目标代码——这正是它与纯静态扫描工具的本质区别也是沙箱不可省略的根本原因。二、为什么沙箱是必需品约束必须写进代码而不是提示词前沿模型越来越擅长绕开限制这既是它们成为高效漏洞猎手的原因也是它们可能对自身执行环境采取意外行动的原因。博客文章 docs/blog-post.md 的沙箱章节记录了真实案例一个团队告诉模型没有网络访问但实际有模型很快发现它可以自行从 GitHub 拉取代码另一个团队观察到 Agent 在扫描中途直接回复了一个 GitHub issue。两个行为都非恶意但都说明了一个结论——模型会使用它实际拥有的全部能力而不只是你告诉它拥有的能力。因此本仓库遵循一条核心原则约束必须在代码中强制而不是写在提示词里。这条原则在源码中得到了严格贯彻。每个 Agent 都运行在 gVisor 容器内详见 docs/agent-sandbox.md网络出口仅限模型 API而所有会派生 Agent 的子命令都拒绝在沙箱外启动除非显式传入--dangerously-no-sandbox。实现上harness/sandbox.py 的require()函数是这道闸门当环境变量VULN_PIPELINE_AGENT_RUNTIME未设置即没有沙箱运行时且未传入 override 时它返回一段明确报错——要求改用bin/vp-sandboxed或显式传--dangerously-no-sandboxharness/cli.py 则在run、recon、report、patch四个子命令解析参数后统一调用sandbox.require()一旦返回错误即以退出码 1 拒绝启动。对应地tests/test_sandbox.py 用单元测试锁死了这一行为test_require_refuses_without_runtime_or_override验证在无运行时且无 override 时报错并提示bin/vp-sandboxed与--dangerously-no-sandboxtest_require_checks_runtime_is_registered验证即使设置了运行时Docker 里不存在该 runtime 时同样拒绝。三、运行自主 Agent 的安全规则操作清单docs/security.md 给出了一份可直接照做的规则清单每一条都可以在源码或脚本里找到对应实现规则要点实现证据用bin/vp-sandboxed启动启动前验证沙箱就绪再派生 Agentbin/vp-sandboxed不要在普通 Dockerrunc中跑自主 Agent普通容器与宿主共享内核内核漏洞可波及宿主scripts/setup_sandbox.sh 用 runsc 替换默认运行时不要加--privileged或 host 网络避免提权与网络暴露沙箱容器统一挂到vp-internal内部网络隔离级别匹配任务只读代码的 Agent 用普通容器即可运行目标代码必须更强隔离gVisor / Kata / FirecrackerAgent 与目标同处 gVisor 容器绝不挂载凭据路径~/.aws、.env等不得进入 Agent 环境harness/auth.py 不转发AWS_PROFILE/~/.aws不连接可写外界的 MCP 服务生产基础设施、邮件、云存储都不允许容器网络无默认路由仅代理出口交互式驱动时依赖权限分类器 人工审批任何触达仓库之外的操作都要人工确认--permission-mode在无沙箱时回退到auto四、沙箱的架构级拆解三道隔离装置从 harness/sandbox.py 的模块注释可以完整还原沙箱的实现骨架管线为每个 find / grade / report / recon Agent 在--internalDocker 网络上启动一个 gVisor 容器该网络的唯一出口是白名单代理默认api.anthropic.com:443Bedrock/Vertex 时由harness.auth派生。4.1 第一道gVisor —— 与宿主内核解耦gVisorrunsc为容器提供自己的用户态内核。Agent 的Read、Write、Bash工具全部在容器内执行容器运行在 gVisor 内核而非宿主内核之上。因此即使 Agent 或它运行的目标代码做了意外的事影响也被限制在容器内部。docs/agent-sandbox.md 用一张表格精确刻画了有沙箱 vs 无沙箱的差异隔离面无沙箱有沙箱AgentRead/Write宿主文件系统仅容器文件系统AgentBash宿主 shell仅容器 shellgVisor netstack/kernel网络出口宿主任意网络配置的白名单默认api.anthropic.com:443宿主耦合完全耦合docker exec cat取出 PoC、-v found_bugs.jsonl:ro只读挂入4.2 第二道vp-internal内部网络 —— 与互联网解耦Agent 容器挂载在名为vp-internal的 Docker 网络上该网络没有到互联网的路由。出口路径只有同网络上的一个小型代理容器它只转发到模型 API 的流量。在代码里harness/sandbox.py 定义了NETWORK_ENV VULN_PIPELINE_AGENT_NETWORK与NETWORK_DEFAULT vp-internalnetwork()函数在沙箱激活时默认返回vp-internal无沙箱时回退到 Docker 默认的bridge。一个值得注意的细节agent_container()允许对特定容器传networknone。测试test_agent_container_network_override验证了这一点——T0–T2 补丁验证器只运行目标代码、从不跑claude -p因此连代理出口都不给彻底切断网络。4.3 第三道白名单出口代理 —— 与外界解耦scripts/egress_proxy.py 是一个约 100 行的纯 Python CONNECT 代理从环境变量VP_EGRESS_ALLOW读取白名单默认api.anthropic.com:443监听 3128 端口只放行精确匹配host:port或*.domain.tld:port通配条目通配仅用于显式覆盖自动派生的默认值从不使用通配符的 CONNECT 请求其余一律返回 403 并打印[egress DENY]日志——被拒绝的尝试日志本身就是 Agent 试图对外联系的有用信号。代理与harness.auth中的_host_allowed()保持同步实现并有配套的预检check_egress_satisfied()若运行中的代理白名单未覆盖当前 Provider 所需的出口主机bin/vp-sandboxed会在启动前直接报错退出。4.4 强制入口bin/vp-sandboxedbin/vp-sandboxed 是普通vuln-pipeline命令的包装脚本它做四件事检查 runsc runtime 是否已注册到 Dockerdocker info里找runsc缺失则提示先跑scripts/setup_sandbox.sh检查vp-egress-proxy容器确实挂在vp-internal网络上对docker inspect输出做显式判空防止容器存在但不在该网络的假阳性导出三个环境变量VULN_PIPELINE_AGENT_RUNTIMErunsc、VULN_PIPELINE_AGENT_NETWORKvp-internal、VULN_PIPELINE_EGRESS_PROXYhttp://proxy_ip:3128管线各阶段模块即 harness/sandbox.py通过它们解析沙箱配置用harness.auth.check_egress_satisfied预检代理白名单覆盖当前 Provider 所需主机然后exec真正的vuln-pipeline。任何一步失败都停止并让你先跑 setup而不是静默降级为无沙箱运行。4.5 权限模式的自动切换沙箱还影响容器内claude -p会话的权限模式。harness/sandbox.py 的permission_mode()返回bypassPermissions沙箱激活时或auto无沙箱时。逻辑很清晰有 gVisor 出口白名单时容器本身就是边界权限分类器只需挡住 Agent 自己对/work的写入而--dangerously-no-sandbox时容器边界变弱则回退到auto让分类器继续把关高风险 Bash 等副作用操作。harness/agent.py 的run_agent()通过docker exec调用claude -p时传入--permission-mode并设置CLAUDECODE阻止嵌套会话检查与IS_SANDBOX1允许 CLI 接受bypassPermissions。五、一次性搭建与自证scripts/setup_sandbox.sh每台机器运行一次需要sudo安装新 Docker 运行时并编辑/etc/docker/daemon.json可安全重跑./scripts/setup_sandbox.sh脚本完成五件事与 docs/agent-sandbox.md 一一对应下载并安装 gVisor从 Google 存储桶下载固定版本runsc默认RUNSC_RELEASE20260420可传RUNSC_RELEASEyyyymmdd换版本校验 sha512 后安装到/usr/local/bin/runsc仅支持 Linux x86_64 / aarch64。注册 Docker runtime把runsc写进/etc/docker/daemon.json并SIGHUP重载 dockerd。注册参数含--overlay2none保证 Agent 写入的 PoC 文件对编排器的docker exec cat可见和--ignore-cgroups见下文回退逻辑。创建内部网络 出口代理创建docker network create --internal vp-internal构建并启动vp-egress-proxy双网卡桥接 vp-internal白名单来自VP_EGRESS_ALLOW未设置时由harness.auth.required_egress_hosts()按当前 Provider 自动派生。构建镜像为targets/*/下每个目标构建目标镜像再用 harness/agent_image.py 在其上叠加 Claude Code CLI 层共享vuln-pipeline-agent-base:cli-version基础层避免每个目标重复 nodenpm 安装。执行验证逐一证明隔离生效见下一节。一个工程细节脚本把首个 runsc 容器当作 cgroup 探针。在 rootless Docker 或嵌套 Docker 场景下runsc 可能无法用 dockerd 的凭据管理 cgroups探针失败且错误信息含 cgroup 时脚本自动以--ignore-cgroups重新注册并重试若仍失败则回滚配置并报错。--ignore-cgroups只损失容器级--memory上限不影响 gVisor 内核、网络白名单与文件系统隔离。平台限制gVisor 仅运行于 Linux。macOS / Windows 上要么在 Linux VM 内运行管线要么使用--dangerously-no-sandbox代价见后文。六、隔离验证亲手证明沙箱在工作搭建脚本和文档都提供了可重复的验证手段。你可以自己执行以下四条命令来自 docs/agent-sandbox.md# 1. gVisor 是否真的生效两行应打印不同的内核版本 docker run --rm --runtimerunsc vuln-pipeline-drlibs-latest-agent:latest uname -r uname -r # 2. 宿主文件系统是否不可达cat 应报 No such file or directory echo host /tmp/probe-$$; \ docker run --rm --runtimerunsc vuln-pipeline-drlibs-latest-agent:latest cat /tmp/probe-$$ # 3. 模型 API 能否到达应打印任意 HTTP 状态码 docker run --rm --runtimerunsc --networkvp-internal -e HTTPS_PROXYhttp://proxy_ip:3128 \ vuln-pipeline-drlibs-latest-agent:latest sh -c curl -sI https://api.anthropic.com/ -o /dev/null -w %{http_code}\n # 4. 其他主机能否到达连接应被拒绝 docker run --rm --runtimerunsc --networkvp-internal -e HTTPS_PROXYhttp://proxy_ip:3128 \ vuln-pipeline-drlibs-latest-agent:latest sh -c curl -sI https://example.com/ -o /dev/null -w %{http_code}\n仓库还内置了两层自动化验证真实基础设施测试tests/test_agent_sandbox.py 通过REPRO1 pytest tests/test_agent_sandbox.py -v运行默认pytest tests/保持封闭覆盖 guest 内核与宿主不同、宿主文件不可达、白名单出口生效API 可达、example.com 与直连 8.8.8.8 被阻断、gVisor 下claude --version可用、runtime 名拼错时大声失败等检查项。模块级 fixture 会先幂等地重跑setup_sandbox.sh。单元级守卫tests/test_sandbox.py 验证require()的拒绝逻辑、权限模式随 runtime 切换、代理环境变量大小写HTTPS_PROXY/https_proxy都注入兼容 AWS SDK透传等。七、分离构建与攻击阶段先联网冻结再断网攻击docs/security.md 强调的通用模式是把需要互联网的事全部放在前面拉依赖、装工具然后冻结结果让攻击阶段除了模型 API 之外没有任何出口。仓库里这个拆分具体化为Setup构建docker build以正常网络权限拉取依赖并编译目标含 ASAN。之后 Agent 在这个镜像上、于vp-internal网络内运行唯一出路是白名单代理。Freeze冻结镜像即快照。基础镜像、commit SHA、依赖版本全部 pin 在目标的Dockerfile中保证每次运行使用完全相同的二进制。harness/agent_image.py 在此基础上更进一步agent 镜像的 tag 由目标 tag CLI 版本组成如vuln-pipeline-canary-latest-agent:latest连重攻击时提交的patched-uuid快照也拥有独立 tag不会与原始目标镜像混淆——测试test_agent_tag_distinguishes_committed_snapshots验证了这一点。这样每次扫描都从同一个干净快照开始发现 Agent 与验证 Agent 操作的是攻击者真正会面对的那份产物。八、第三方模型提供商的凭据与出口配置沙箱场景下凭据的引入方式与出口白名单必须一起设计。以 harness/auth.py 为单一事实来源配 docs/agent-sandbox.md 的说明Amazon Bedrock。运行setup_sandbox.sh前设置CLAUDE_CODE_USE_BEDROCK1AWS_REGION如us-east-1二选一AWS_BEARER_TOKEN_BEDROCK推荐——单用途、无 IAM 横向移动风险或AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY可加AWS_SESSION_TOKEN使用 access key 时把 IAM principal 的范围收紧到仅bedrock:InvokeModel*——这些凭据对沙箱内的 Agent 进程可见。AWS_PROFILE和~/.aws不会被转发沙箱从不挂载凭据文件凭据必须来自环境变量长时批量运行请用 ≥12h TTL 的长期 key 或会话 token。刻意不支持的场景实例配置文件 / IMDS 凭据。Agent 容器没有到169.254.169.254的路由、也没有 STS 出口——这样敌对目标代码既偷不走实例角色也无法经 AssumeRole 横向移动。只有角色凭据的机器请用eval $(aws configure export-credentials --format env)物化到环境注意导出的会话凭据沿用角色会话 TTL应从一个能活过整个运行的会话开始。模型 ID 与出口Bedrock 模型 ID 带跨区域推理配置文件前缀us./eu./apac./global.如--model us.anthropic.claude-opus-4-6-v1且前缀必须匹配部署的区域组韩国ap-northeast-2部署需要apac.anthropic.claude-sonnet-4-5-...而不是us.anthropic....。裸 foundation-model IDanthropic.开头通常首次调用即报ValidationException管线对此有预检警告。出口白名单自动派生为bedrock-runtime.region.amazonaws.com:443更换 Provider 或区域后需重跑setup_sandbox.sh让代理用正确主机重建。Google Vertex AI。环境变量透传已接线CLAUDE_CODE_USE_VERTEX1、ANTHROPIC_VERTEX_PROJECT_ID、CLOUD_ML_REGION但出口不会自动派生——需在 setup 前显式设置例如VP_EGRESS_ALLOW${CLOUD_ML_REGION}-aiplatform.googleapis.com:443,oauth2.googleapis.com:443Vertex 支持目前未测试。Azure 尚未接线。九、Prompt injection把目标数据当数据不当指令自主管线让 Agent 读取大量源自目标的数据ASAN trace含目标符号表中的函数名与文件路径、可利用性报告、构建/测试输出。一个恶意的目标作者完全可以在这些字符串里嵌入指令。因此不要给 Agent 装来自互联网的不可信 skills、plugins 或 MCP serversfind / report Agent 的爆炸半径有限它们跑在 gVisor 容器内的内部网络上、出口仅限 API且只产出你阅读的文件patch Agent 是高利害场景它的输出是一份你可能应用到真实代码库的 diff。管线对高利害场景做了专门防御。在 harness/prompts/patch_prompt.py 中所有目标派生文本ASAN 崩溃输出、可利用性报告、重试失败证据都被包进带每次调用随机 id的untrusted_data id{nonce}块提示词明确要求 Agent 只把它们当作数据来诊断崩溃不得遵循块内任何指令、请求或指示也不得让块内容扩大修复范围。底层机制在 harness/prompts/untrusted.pymake_nonce()用secrets.token_hex(16)生成每次调用独立的随机分隔 idsanitize_untrusted()用正则中和一切可能提前闭合/untrusted_data的伪闭合标签使块不可能提前终止因为嵌入文本在任何 nonce 存在之前就已生成它天然不可能包含匹配的闭合标签——两道防线叠加。但文档明确强调这些措施是缓解手段不是保证。patching.md也给出同样的警示见 docs/patching.md——提示级围栏无法根治被投毒目标的影响因此每个生成的 diff 在上游合并前都必须人工审查。十、退出沙箱--dangerously-no-sandbox的代价Agent 派生子命令run/recon/report/patch见 harness/cli.py都接受--dangerously-no-sandbox。打开这个开关后Agent 仍跑在 Docker 容器里但 docs/agent-sandbox.md 明确指出三处退化容器运行在宿主内核上意外的 Agent 行为或恶意目标代码离宿主更近容器获得普通 Docker 网络拥有完整互联网访问Agent 的凭据与它正在编译和弄崩的目标同处一个容器。文档对它的定位是不推荐仅在开发场景、在一次性throwawayVM 上使用。如果必须调试沙箱本身--dangerously-no-sandbox是最后的逃生门但打开它等于主动放弃本指南前面讲述的全部隔离收益。十一、落地自检清单把本文内容压缩成部署前检查清单每台机器跑过一次scripts/setup_sandbox.sh并用uname -r对比确认 gVisor 生效一律通过bin/vp-sandboxed run|recon|report|patch启动未配置沙箱时它应拒绝启动确认出口白名单只含当前 Provider 所需主机默认api.anthropic.com:443Bedrock 自动派生bedrock-runtime.region.amazonaws.com:443Vertex 手动设置VP_EGRESS_ALLOW环境中没有任何凭据路径被挂载进 Agent 容器凭据只经环境变量注入且 IAM 范围最小化不给 Agent 连接任何可写外界的 MCP 服务每个patch.diff上游前都经过人工审查警惕范围蔓延、症状压制、新攻击面与诊断对但修得窄四类典型问题。自主漏洞挖掘的价值建立在安全边界之上。这份参考管线把约束写进代码落实成了 gVisor 内核隔离、内部网络 白名单代理、强制入口脚本与提示注入围栏四层机制——它们共同保证即使模型真的创造性起来它的活动半径也永远够不到你的宿主与生产系统。赞分享人工智能AI Agent应用安全漏洞扫描【免费下载链接】defending-code-reference-harnessSkills for threat modeling, scanning, triage, patching, plus an autonomous scanning harness you can /customize项目地址https://gitcode.com/gh_mirrors/de/defending-code-reference-harness点击查看免费下载相关推荐为自主漏洞扫描 Agent 构建 gVisor 沙箱defending-code-reference-harness 的隔离实践深度解析为自主漏洞扫描 Agent 构建 gVisor 沙箱defending code reference harness 的隔离实践深度解析 本文以仓库 docs人工智能AI Agent应用安全漏洞扫描老Mac升级macOSOCLP 4步装完老Mac升级macOSOCLP 4步装完 2012 年的 MacBook Pro某天点进 App Store 想装个新 Office跳出来一句需要 ma操作系统固件驱动开发Firecracker安全沙箱cgroups与namespaces的深度隔离Firecracker安全沙箱cgroups与namespaces的深度隔离 引言云原生时代的安全隔离挑战 在当今云原生和Serverless计算环境中多虚拟化云原生上一篇PHPWord读取Word文档教程内容提取与解析技巧下一篇现代C UI库设计思想Breeze Shell架构全解析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考