人工智能AI Agent代码智能体Agent 编排CLIAI 应用【免费下载链接】gsd-2A powerful meta-prompting, context engineering and spec-driven development system that enables agents to work for long periods of time autonomously without losing track of the big picture项目地址https://gitcode.com/gh_mirrors/gs/gsd-2点击查看免费下载本篇技术指南以 GSD 项目docs/dev/building-coding-agents/24-security-trust-boundaries.md的安全设计文档为主线系统讲解如何把 Agent 当作高能力但未经审查的承包商来构建安全环境包括不可逾越的硬边界、分层沙箱架构、能力化安全模型以及针对 AI 生成代码的常见脆弱模式与配置落地方法。读完你将掌握在 GSD 中配置沙箱、白名单、凭据注入与安全覆盖的具体命令和参数。1. 核心安全立场让环境安全而非让 Agent 受限文档提出的第一个关键结论是安全的重点不是通过限制 Agent 能力来让 Agent 安全而是把环境设计得足够安全让 Agent 在环境中可以最大限度地发挥能力。Think of the agent as ahighly capable but unvetted contractor.Give them the codebase and dev environment. Dont give them production credentials, deployment access, or the ability to modify security infrastructure. The goal isnt to make the agent safe by limiting capabilities — its to make theenvironmentsafe so the agent can be maximally capable within it.这一定位直接决定了后续所有设计决策的方向信任不放在 Agent 身上而是放在环境的隔离、验证与审计机制上。因此 GSD 的整个安全体系由三个层次构成——硬边界Hard Boundaries、沙箱架构Sandboxing Architecture与能力化安全模型Capability-Based Security Model。2. 硬边界Agent 绝不应做的事通用共识文档给出了所有 Agent 系统都应遵守的硬边界清单这些属于不需要讨论、必须遵守的通用共识禁止行为原因直接访问生产系统Agent 的世界就是开发环境仅此而已Agents world is the dev environment, full stop访问或嵌入机密信息API 密钥、凭据永远不应出现在 Agent 的上下文或输出中向任意目的地发起网络请求配置限制性防火墙只白名单必要的服务修改自身的编排器、提示词或工具防止移除安全约束本身在项目目录之外执行命令沙箱限制在项目目录 临时工作目录内从 GSD 源码看这条硬边界被落实为全局配置优先的原则威胁模型明确针对克隆仓库中可能包含的恶意项目级配置因此安全覆盖只允许来自全局设置与环境变量项目级配置一律忽略。见 src/security-overrides.ts 第 4-6 行的注释// Both overrides are global-only (not project-level) because the threat model is // malicious project-level config in cloned repos. Global settings and env vars // represent the users own authority on their machine.3. 沙箱架构五层纵深隔离文档定义了沙箱架构的五层机制GSD 仓库中有对应的真实实现层级机制执行层Execution容器化Docker seccomp、受限文件系统、网络策略文件系统层Filesystem内容寻址存储——Agent提议变更后端在写入前验证机密层SecretsVault 代理 短期令牌绝不直接暴露真实凭据命令层Commands解析并拦截危险模式如rm -rf /、curl到未知主机依赖层Dependencies批准的依赖清单——新依赖需要自动批准预批准清单或人工批准3.1 执行层Docker 沙箱模板GSD 提供现成的沙箱镜像模板 Dockerfile.sandbox其关键安全设计包括基于node:24-bookworm-slim精简基础镜像只安装必要工具git、curl、ca-certificates、openssh-client、gosu创建非 root 用户gsdUID 1000容器内进程以低权限用户运行RUN groupadd --gid 1000 gsd \ useradd --uid 1000 --gid gsd --shell /bin/bash --create-home gsd只暴露默认 Web UI 端口 3000EXPOSE 3000通过entrypoint.sh完成UID/GID 重映射 权限降级。entrypoint.sh 中展示了完整的权限链容器以 root 启动 → 根据宿主机PUID/PGID重映射gsd用户 → 预创建关键文件防止 bind-mount 把文件路径变成目录 → 基于哨兵文件.bootstrapped执行一次性初始化 → 最终用exec gosu ${GSD_USER} $替换进程并降级为非 root 用户同时保证 PID 1 信号转发SIGTERM/SIGINT正确。# 构建并使用沙箱模板Docker Sandbox CLIMicroVM 级隔离 docker sandbox create --template ./docker --name gsd-sandbox docker sandbox exec -it gsd-sandbox bash gsd auto implement the feature described in issue #42也可以使用容器级隔离的 Compose 方案docker-compose.yamlcp docker/.env.example docker/.env # 编辑 docker/.env 填入你的 API 密钥 docker compose -f docker/docker-compose.yaml up -d docker exec -it gsd-sandbox bash gsd auto implement the feature described in issue #423.2 文件系统层受控的工作区挂载沙箱通过受限挂载把 Agent 的活动范围锁定在项目目录内。Compose 的卷配置docker-compose.full.yaml展示了推荐挂载方式volumes: - ../:/workspace # 项目根目录挂载进容器 - gsd-state:/home/gsd/.gsd # GSD 状态目录跨重启持久化 # - ~/.ssh:/home/gsd/.ssh:ro # SSH 密钥以只读方式挂载可选 # - ~/.gitconfig:/home/gsd/.gitconfig:ro # 宿主机 git 配置可选注意注释掉的 SSH 密钥与 git 配置即便需要让 Agent 操作 git也只读挂载Agent 无法修改宿主机上的密钥文件。同时PUID/PGID重映射避免了 bind-mount 卷上的权限冲突docker/README.md 中建议用id -u/id -g查询宿主用户 ID 填入。3.3 命令层危险命令拦截与命令前缀白名单命令层的拦截逻辑分两个层面a内置安全前缀白名单GSD 将可以安全执行的命令前缀集中定义在 packages/pi-coding-agent/src/core/resolve-config-value.ts 第 14-25 行的SAFE_COMMAND_PREFIXES中用于!command解析export const SAFE_COMMAND_PREFIXES [ pass, op, aws, gcloud, vault, security, gpg, bw, gopass, lpass, ];这些前缀正是凭据管理器pass、1Password 的op、Bitwarden 的bw、gopass、lpass与云 CLIaws、gcloud、vault、security它们由 Agent 安全调用以获取短期/临时凭据而不会把机密文本直接带入上下文。测试 packages/pi-coding-agent/src/core/resolve-config-value.test.ts 中有一个值得注意的用例sops不在内置白名单中因此默认会被拦截必须显式加入白名单后才能使用——这印证了新能力必须显式批准的设计理念。b用户级命令前缀覆盖setAllowedCommandPrefixes()允许以全局设置或环境变量替换默认白名单。若传入空数组会输出警告并阻断所有!command见 resolve-config-value.ts 第 39-41 行——这是 fail-closed 的默认行为。3.4 网络层SSRF 防护与出口白名单网络访问在两层被限制aSSRF 防护src/resources/extensions/search-the-web/url-utils.ts 中的isBlockedUrl()实现了一套完整的 SSRF 拦截逻辑协议校验非https:/http:的 URL 一律拦截内置黑名单主机名localhost、metadata.google.internal、instance-data云元数据服务是 SSRF 的经典攻击目标私有 IP 段拦截覆盖127.*、10.*、172.16-31.*、192.168.*、169.254.*链路本地地址、0.*、::1、fc00:*、fd*IPv6 ULA、fe80:*IPv6 链路本地防止 Agent 通过 fetch 访问内网资源。b出口域名白名单文档要求限制性防火墙只白名单必要服务。若你在沙箱中限制出站网络GSD 需要放行的端点见 docker/README.md 的 Network Allowlisting 一节用途端点LLM APIapi.anthropic.com、api.openai.com、generativelanguage.googleapis.com、openrouter.ai包注册表registry.npmjs.org研究工具api.search.brave.com、api.tavily.com、r.jina.aiGitHubapi.github.com、github.com3.5 机密层凭据注入而不是凭据暴露沙箱内的 Agent 依然需要调用 LLM API密钥如何进去文档给出两条路径Docker Sandbox自动Docker 的代理层会把宿主机 shell 配置~/.bashrc、~/.zshrc中设置的 API key 自动转发进沙箱密钥永不存储在沙箱内部Docker Compose手动复制docker/.env.example为docker/.env填入密钥该文件被 gitignore 且永不提交。两条路径都贯彻了Agent 拿不到原始凭据的原则——对应文档中Vault 代理 短期令牌的设计意图Agent 通过受控通道使用凭据而非在上下文中持有明文。3.6 依赖层批准清单文档要求依赖走批准的依赖清单 自动/人工批准。GSD 沙箱内置工具由镜像固定npm install -g gsd-pi${GSD_VERSION}版本通过构建参数锁定如docker compose -f docker/docker-compose.yaml build --build-arg GSD_VERSION2.51.0新增依赖默认需要批准——与命令白名单的显式加入才可用逻辑一致都属于 fail-closed 设计。4. 能力化安全模型编排器在沙箱之外Agent 只有工具这是文档中承上启下的关键架构The orchestrator runsoutsidethe sandbox. The agent requests operations through a controlled API. The orchestrator validates every request before executing. The agent doesnt have direct access to anything — it has access totools that the orchestrator mediates.即Agent 没有直接访问任何东西的能力它拥有的只是编排器中介过的工具。编排器运行在沙箱之外Agent 的一切操作都必须通过受控 API 提出请求由编排器在执行前逐一验证。这个模型把能力从访问权限中解耦——即便 Agent 被诱导或出 bug也无法绕开编排器直接触达系统资源。这一点在 GSD 中同样体现为编排器在沙箱外、Agent 在沙箱内的部署形态宿主侧的编排进程负责验证容器内只运行gsd命令本身。docker-compose.yaml中容器仅挂载项目目录与.gsd状态卷宿主机其他目录与进程对容器不可见即Agent 的世界就是开发环境的执行层落实。5. 微妙风险AI 特有的不安全模式文档特别指出一个容易被忽视的事实Agent 引入漏洞往往不是出于恶意而是通过看起来很合理的不安全模式。典型三类字符串拼接构造 SQL 查询应改用参数化查询为图方便禁用 CORS应保留跨域校验为调试而记录敏感数据应脱敏并限制日志级别。因此安全 lint 规则应专门针对这些AI 常见模式进行调优而不是只按人类开发者的常见错误配置。这意味着安全护栏的默认值应当覆盖 Agent 的便利性倾向例如 GSD 对fetch_page工具默认启用 SSRF 拦截、对命令默认拒绝未批准前缀都是对这一原则的实现。6. 落地配置安全覆盖Security OverridesGSD 把上述原则转化为一组用户可配置的安全覆盖参数集中在 src/security-overrides.ts 中统一应用。该文件的优先级设计为环境变量 settings.json 全局设置 内置默认值见文件第 8 行注释。6.1 命令前缀白名单覆盖通过GSD_ALLOWED_COMMAND_PREFIXES环境变量或全局settings.json中的allowedCommandPrefixes覆盖内置的SAFE_COMMAND_PREFIXES# 环境变量方式逗号分隔 export GSD_ALLOWED_COMMAND_PREFIXESpass,op,aws,gcloud,vault,security,gpg,bw,gopass,lpass,sops对应settings.json{ allowedCommandPrefixes: [pass, op, aws, gcloud, vault, security, gpg, bw, gopass, lpass, sops] }从 settings-manager.ts 第 220 行可知该配置为global-only项目设置中会被忽略——这是防止克隆仓库在项目级配置中偷偷放宽命令限制的关键设计对应硬边界禁止 Agent 修改自身安全约束。6.2 网络白名单覆盖SSRF 豁免通过GSD_FETCH_ALLOWED_URLS或全局设置中的fetchAllowedUrls设置豁免 SSRF 拦截的主机名export GSD_FETCH_ALLOWED_URLSapi.github.com,registry.npmjs.org{ fetchAllowedUrls: [api.github.com, registry.npmjs.org] }同样为 global-only。这些主机名会被注入 url-utils.ts 的fetchAllowedHostnames集合isBlockedUrl()会先检查豁免清单再检查内置黑名单与私有 IP 段见该文件第 42-56 行。7. 从文档到实践完整的安全边界检查清单结合文档五条硬边界与 GSD 的落地实现将理论映射为可直接核查的安全清单硬边界GSD 落地实现核查点不访问生产系统Dockerfile.sandbox entrypoint.sh 非 root 用户、exec gosu降权容器内进程 UID ≠ root不访问/不嵌入机密docker/README.md 凭据注入、Vault 类前缀白名单.env被 gitignore密钥只在宿主机侧不访问任意网络url-utils.ts SSRF 拦截 出口白名单私有 IP 段全部被拦截不修改自身安全约束security-overrides.ts global-only项目级配置忽略安全覆盖不出项目目录执行Compose 卷挂载只覆盖/workspace与/home/gsd/.gsd宿主机其他路径对容器不可见8. 已知限制与适用前提沙箱网络策略需要配合防火墙/代理才能真正白名单化——Docker 容器默认 bridge 网络本身不提供出站过滤文档要求的限制性防火墙属于部署环境责任Docker Sandbox CLI 需 Docker Desktop 4.58macOS/WindowsLinux 支持为实验性Compose 方案提供容器级隔离作为替代docker/README.md 的 Known LimitationsDocker 自带的命名 Agentclaude、codex 等由 Docker 自身注册第三方工具无法注册新命名 AgentGSD 改用通用 shell 沙箱类型 自定义模板沙箱运行 UbuntuDebian环境macOS 专属依赖可能无法在沙箱内工作需在宿主侧验证环境一致性。这些限制并不削弱信任边界的有效性——它们只是提示沙箱是安全环境的最后一层而非全部。硬边界共识 五层沙箱架构 编排器中介的能力化模型共同构成了环境安全、Agent 自由的完整体系。延伸阅读本文安全设计出自 docs/dev/building-coding-agents/24-security-trust-boundaries.md同系列其余章节如 17-irreversible-operations-safety-architecture.md、20-error-taxonomy-routing.md可配合阅读沙箱部署细节见 docker/README.md源码入口见 security-overrides.ts 与 resolve-config-value.ts。赞分享人工智能AI Agent代码智能体Agent 编排CLIAI 应用【免费下载链接】gsd-2A powerful meta-prompting, context engineering and spec-driven development system that enables agents to work for long periods of time autonomously without losing track of the big picture项目地址https://gitcode.com/gh_mirrors/gs/gsd-2点击查看免费下载相关推荐自主漏洞挖掘管线的安全边界defending-code-reference-harness 的沙箱隔离与防护实践自主漏洞挖掘管线的安全边界defending code reference harness 的沙箱隔离与防护实践 本指南基于仓库 docs/security.人工智能AI Agent应用安全漏洞扫描NumPy 安全指南信任边界、漏洞报告与不可信数据防护实践NumPy 安全指南信任边界、漏洞报告与不可信数据防护实践 导读 本文基于 NumPy 官方安全文档 doc/source/reference/securi科学计算数据分析Apache Iceberg 安全模型与漏洞报告指南信任边界、威胁建模与凭据防护Apache Iceberg 安全模型与漏洞报告指南信任边界、威胁建模与凭据防护 本文以 Apache Iceberg 官方安全文档 site/docs/s数据湖大数据数据存储上一篇Agent-Native MCP应用构建可安装的智能体扩展下一篇Hyper-RAG 超图检索Hyper-Extract N 元超边复杂关系建模指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
GSD 安全与信任边界实践：沙箱隔离、能力化安全模型与 AI 常见漏洞防护
人工智能AI Agent代码智能体Agent 编排CLIAI 应用【免费下载链接】gsd-2A powerful meta-prompting, context engineering and spec-driven development system that enables agents to work for long periods of time autonomously without losing track of the big picture项目地址https://gitcode.com/gh_mirrors/gs/gsd-2点击查看免费下载本篇技术指南以 GSD 项目docs/dev/building-coding-agents/24-security-trust-boundaries.md的安全设计文档为主线系统讲解如何把 Agent 当作高能力但未经审查的承包商来构建安全环境包括不可逾越的硬边界、分层沙箱架构、能力化安全模型以及针对 AI 生成代码的常见脆弱模式与配置落地方法。读完你将掌握在 GSD 中配置沙箱、白名单、凭据注入与安全覆盖的具体命令和参数。1. 核心安全立场让环境安全而非让 Agent 受限文档提出的第一个关键结论是安全的重点不是通过限制 Agent 能力来让 Agent 安全而是把环境设计得足够安全让 Agent 在环境中可以最大限度地发挥能力。Think of the agent as ahighly capable but unvetted contractor.Give them the codebase and dev environment. Dont give them production credentials, deployment access, or the ability to modify security infrastructure. The goal isnt to make the agent safe by limiting capabilities — its to make theenvironmentsafe so the agent can be maximally capable within it.这一定位直接决定了后续所有设计决策的方向信任不放在 Agent 身上而是放在环境的隔离、验证与审计机制上。因此 GSD 的整个安全体系由三个层次构成——硬边界Hard Boundaries、沙箱架构Sandboxing Architecture与能力化安全模型Capability-Based Security Model。2. 硬边界Agent 绝不应做的事通用共识文档给出了所有 Agent 系统都应遵守的硬边界清单这些属于不需要讨论、必须遵守的通用共识禁止行为原因直接访问生产系统Agent 的世界就是开发环境仅此而已Agents world is the dev environment, full stop访问或嵌入机密信息API 密钥、凭据永远不应出现在 Agent 的上下文或输出中向任意目的地发起网络请求配置限制性防火墙只白名单必要的服务修改自身的编排器、提示词或工具防止移除安全约束本身在项目目录之外执行命令沙箱限制在项目目录 临时工作目录内从 GSD 源码看这条硬边界被落实为全局配置优先的原则威胁模型明确针对克隆仓库中可能包含的恶意项目级配置因此安全覆盖只允许来自全局设置与环境变量项目级配置一律忽略。见 src/security-overrides.ts 第 4-6 行的注释// Both overrides are global-only (not project-level) because the threat model is // malicious project-level config in cloned repos. Global settings and env vars // represent the users own authority on their machine.3. 沙箱架构五层纵深隔离文档定义了沙箱架构的五层机制GSD 仓库中有对应的真实实现层级机制执行层Execution容器化Docker seccomp、受限文件系统、网络策略文件系统层Filesystem内容寻址存储——Agent提议变更后端在写入前验证机密层SecretsVault 代理 短期令牌绝不直接暴露真实凭据命令层Commands解析并拦截危险模式如rm -rf /、curl到未知主机依赖层Dependencies批准的依赖清单——新依赖需要自动批准预批准清单或人工批准3.1 执行层Docker 沙箱模板GSD 提供现成的沙箱镜像模板 Dockerfile.sandbox其关键安全设计包括基于node:24-bookworm-slim精简基础镜像只安装必要工具git、curl、ca-certificates、openssh-client、gosu创建非 root 用户gsdUID 1000容器内进程以低权限用户运行RUN groupadd --gid 1000 gsd \ useradd --uid 1000 --gid gsd --shell /bin/bash --create-home gsd只暴露默认 Web UI 端口 3000EXPOSE 3000通过entrypoint.sh完成UID/GID 重映射 权限降级。entrypoint.sh 中展示了完整的权限链容器以 root 启动 → 根据宿主机PUID/PGID重映射gsd用户 → 预创建关键文件防止 bind-mount 把文件路径变成目录 → 基于哨兵文件.bootstrapped执行一次性初始化 → 最终用exec gosu ${GSD_USER} $替换进程并降级为非 root 用户同时保证 PID 1 信号转发SIGTERM/SIGINT正确。# 构建并使用沙箱模板Docker Sandbox CLIMicroVM 级隔离 docker sandbox create --template ./docker --name gsd-sandbox docker sandbox exec -it gsd-sandbox bash gsd auto implement the feature described in issue #42也可以使用容器级隔离的 Compose 方案docker-compose.yamlcp docker/.env.example docker/.env # 编辑 docker/.env 填入你的 API 密钥 docker compose -f docker/docker-compose.yaml up -d docker exec -it gsd-sandbox bash gsd auto implement the feature described in issue #423.2 文件系统层受控的工作区挂载沙箱通过受限挂载把 Agent 的活动范围锁定在项目目录内。Compose 的卷配置docker-compose.full.yaml展示了推荐挂载方式volumes: - ../:/workspace # 项目根目录挂载进容器 - gsd-state:/home/gsd/.gsd # GSD 状态目录跨重启持久化 # - ~/.ssh:/home/gsd/.ssh:ro # SSH 密钥以只读方式挂载可选 # - ~/.gitconfig:/home/gsd/.gitconfig:ro # 宿主机 git 配置可选注意注释掉的 SSH 密钥与 git 配置即便需要让 Agent 操作 git也只读挂载Agent 无法修改宿主机上的密钥文件。同时PUID/PGID重映射避免了 bind-mount 卷上的权限冲突docker/README.md 中建议用id -u/id -g查询宿主用户 ID 填入。3.3 命令层危险命令拦截与命令前缀白名单命令层的拦截逻辑分两个层面a内置安全前缀白名单GSD 将可以安全执行的命令前缀集中定义在 packages/pi-coding-agent/src/core/resolve-config-value.ts 第 14-25 行的SAFE_COMMAND_PREFIXES中用于!command解析export const SAFE_COMMAND_PREFIXES [ pass, op, aws, gcloud, vault, security, gpg, bw, gopass, lpass, ];这些前缀正是凭据管理器pass、1Password 的op、Bitwarden 的bw、gopass、lpass与云 CLIaws、gcloud、vault、security它们由 Agent 安全调用以获取短期/临时凭据而不会把机密文本直接带入上下文。测试 packages/pi-coding-agent/src/core/resolve-config-value.test.ts 中有一个值得注意的用例sops不在内置白名单中因此默认会被拦截必须显式加入白名单后才能使用——这印证了新能力必须显式批准的设计理念。b用户级命令前缀覆盖setAllowedCommandPrefixes()允许以全局设置或环境变量替换默认白名单。若传入空数组会输出警告并阻断所有!command见 resolve-config-value.ts 第 39-41 行——这是 fail-closed 的默认行为。3.4 网络层SSRF 防护与出口白名单网络访问在两层被限制aSSRF 防护src/resources/extensions/search-the-web/url-utils.ts 中的isBlockedUrl()实现了一套完整的 SSRF 拦截逻辑协议校验非https:/http:的 URL 一律拦截内置黑名单主机名localhost、metadata.google.internal、instance-data云元数据服务是 SSRF 的经典攻击目标私有 IP 段拦截覆盖127.*、10.*、172.16-31.*、192.168.*、169.254.*链路本地地址、0.*、::1、fc00:*、fd*IPv6 ULA、fe80:*IPv6 链路本地防止 Agent 通过 fetch 访问内网资源。b出口域名白名单文档要求限制性防火墙只白名单必要服务。若你在沙箱中限制出站网络GSD 需要放行的端点见 docker/README.md 的 Network Allowlisting 一节用途端点LLM APIapi.anthropic.com、api.openai.com、generativelanguage.googleapis.com、openrouter.ai包注册表registry.npmjs.org研究工具api.search.brave.com、api.tavily.com、r.jina.aiGitHubapi.github.com、github.com3.5 机密层凭据注入而不是凭据暴露沙箱内的 Agent 依然需要调用 LLM API密钥如何进去文档给出两条路径Docker Sandbox自动Docker 的代理层会把宿主机 shell 配置~/.bashrc、~/.zshrc中设置的 API key 自动转发进沙箱密钥永不存储在沙箱内部Docker Compose手动复制docker/.env.example为docker/.env填入密钥该文件被 gitignore 且永不提交。两条路径都贯彻了Agent 拿不到原始凭据的原则——对应文档中Vault 代理 短期令牌的设计意图Agent 通过受控通道使用凭据而非在上下文中持有明文。3.6 依赖层批准清单文档要求依赖走批准的依赖清单 自动/人工批准。GSD 沙箱内置工具由镜像固定npm install -g gsd-pi${GSD_VERSION}版本通过构建参数锁定如docker compose -f docker/docker-compose.yaml build --build-arg GSD_VERSION2.51.0新增依赖默认需要批准——与命令白名单的显式加入才可用逻辑一致都属于 fail-closed 设计。4. 能力化安全模型编排器在沙箱之外Agent 只有工具这是文档中承上启下的关键架构The orchestrator runsoutsidethe sandbox. The agent requests operations through a controlled API. The orchestrator validates every request before executing. The agent doesnt have direct access to anything — it has access totools that the orchestrator mediates.即Agent 没有直接访问任何东西的能力它拥有的只是编排器中介过的工具。编排器运行在沙箱之外Agent 的一切操作都必须通过受控 API 提出请求由编排器在执行前逐一验证。这个模型把能力从访问权限中解耦——即便 Agent 被诱导或出 bug也无法绕开编排器直接触达系统资源。这一点在 GSD 中同样体现为编排器在沙箱外、Agent 在沙箱内的部署形态宿主侧的编排进程负责验证容器内只运行gsd命令本身。docker-compose.yaml中容器仅挂载项目目录与.gsd状态卷宿主机其他目录与进程对容器不可见即Agent 的世界就是开发环境的执行层落实。5. 微妙风险AI 特有的不安全模式文档特别指出一个容易被忽视的事实Agent 引入漏洞往往不是出于恶意而是通过看起来很合理的不安全模式。典型三类字符串拼接构造 SQL 查询应改用参数化查询为图方便禁用 CORS应保留跨域校验为调试而记录敏感数据应脱敏并限制日志级别。因此安全 lint 规则应专门针对这些AI 常见模式进行调优而不是只按人类开发者的常见错误配置。这意味着安全护栏的默认值应当覆盖 Agent 的便利性倾向例如 GSD 对fetch_page工具默认启用 SSRF 拦截、对命令默认拒绝未批准前缀都是对这一原则的实现。6. 落地配置安全覆盖Security OverridesGSD 把上述原则转化为一组用户可配置的安全覆盖参数集中在 src/security-overrides.ts 中统一应用。该文件的优先级设计为环境变量 settings.json 全局设置 内置默认值见文件第 8 行注释。6.1 命令前缀白名单覆盖通过GSD_ALLOWED_COMMAND_PREFIXES环境变量或全局settings.json中的allowedCommandPrefixes覆盖内置的SAFE_COMMAND_PREFIXES# 环境变量方式逗号分隔 export GSD_ALLOWED_COMMAND_PREFIXESpass,op,aws,gcloud,vault,security,gpg,bw,gopass,lpass,sops对应settings.json{ allowedCommandPrefixes: [pass, op, aws, gcloud, vault, security, gpg, bw, gopass, lpass, sops] }从 settings-manager.ts 第 220 行可知该配置为global-only项目设置中会被忽略——这是防止克隆仓库在项目级配置中偷偷放宽命令限制的关键设计对应硬边界禁止 Agent 修改自身安全约束。6.2 网络白名单覆盖SSRF 豁免通过GSD_FETCH_ALLOWED_URLS或全局设置中的fetchAllowedUrls设置豁免 SSRF 拦截的主机名export GSD_FETCH_ALLOWED_URLSapi.github.com,registry.npmjs.org{ fetchAllowedUrls: [api.github.com, registry.npmjs.org] }同样为 global-only。这些主机名会被注入 url-utils.ts 的fetchAllowedHostnames集合isBlockedUrl()会先检查豁免清单再检查内置黑名单与私有 IP 段见该文件第 42-56 行。7. 从文档到实践完整的安全边界检查清单结合文档五条硬边界与 GSD 的落地实现将理论映射为可直接核查的安全清单硬边界GSD 落地实现核查点不访问生产系统Dockerfile.sandbox entrypoint.sh 非 root 用户、exec gosu降权容器内进程 UID ≠ root不访问/不嵌入机密docker/README.md 凭据注入、Vault 类前缀白名单.env被 gitignore密钥只在宿主机侧不访问任意网络url-utils.ts SSRF 拦截 出口白名单私有 IP 段全部被拦截不修改自身安全约束security-overrides.ts global-only项目级配置忽略安全覆盖不出项目目录执行Compose 卷挂载只覆盖/workspace与/home/gsd/.gsd宿主机其他路径对容器不可见8. 已知限制与适用前提沙箱网络策略需要配合防火墙/代理才能真正白名单化——Docker 容器默认 bridge 网络本身不提供出站过滤文档要求的限制性防火墙属于部署环境责任Docker Sandbox CLI 需 Docker Desktop 4.58macOS/WindowsLinux 支持为实验性Compose 方案提供容器级隔离作为替代docker/README.md 的 Known LimitationsDocker 自带的命名 Agentclaude、codex 等由 Docker 自身注册第三方工具无法注册新命名 AgentGSD 改用通用 shell 沙箱类型 自定义模板沙箱运行 UbuntuDebian环境macOS 专属依赖可能无法在沙箱内工作需在宿主侧验证环境一致性。这些限制并不削弱信任边界的有效性——它们只是提示沙箱是安全环境的最后一层而非全部。硬边界共识 五层沙箱架构 编排器中介的能力化模型共同构成了环境安全、Agent 自由的完整体系。延伸阅读本文安全设计出自 docs/dev/building-coding-agents/24-security-trust-boundaries.md同系列其余章节如 17-irreversible-operations-safety-architecture.md、20-error-taxonomy-routing.md可配合阅读沙箱部署细节见 docker/README.md源码入口见 security-overrides.ts 与 resolve-config-value.ts。赞分享人工智能AI Agent代码智能体Agent 编排CLIAI 应用【免费下载链接】gsd-2A powerful meta-prompting, context engineering and spec-driven development system that enables agents to work for long periods of time autonomously without losing track of the big picture项目地址https://gitcode.com/gh_mirrors/gs/gsd-2点击查看免费下载相关推荐自主漏洞挖掘管线的安全边界defending-code-reference-harness 的沙箱隔离与防护实践自主漏洞挖掘管线的安全边界defending code reference harness 的沙箱隔离与防护实践 本指南基于仓库 docs/security.人工智能AI Agent应用安全漏洞扫描NumPy 安全指南信任边界、漏洞报告与不可信数据防护实践NumPy 安全指南信任边界、漏洞报告与不可信数据防护实践 导读 本文基于 NumPy 官方安全文档 doc/source/reference/securi科学计算数据分析Apache Iceberg 安全模型与漏洞报告指南信任边界、威胁建模与凭据防护Apache Iceberg 安全模型与漏洞报告指南信任边界、威胁建模与凭据防护 本文以 Apache Iceberg 官方安全文档 site/docs/s数据湖大数据数据存储上一篇Agent-Native MCP应用构建可安装的智能体扩展下一篇Hyper-RAG 超图检索Hyper-Extract N 元超边复杂关系建模指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
