Coding Agent Workspace 安全不是一个开关，而是一组相互配合的边界：项目之间的隔离、项目内部的成员角色、Runtime 可以获取的 Credential、Agent 获得的工具权限，以及每项改动周围的 Review 与恢复流程。
每一层解决的问题都不同。隔离的 Workspace 不能证明 Agent 命令一定安全；Viewer 角色保护不了已经提交进仓库的 Secret；批准提示也不能保证获批 Patch 是正确的。安全工作流的起点，是把每类风险交给真正能降低它的控制措施。
使用分层安全模型
下面这张表把 Coding Agent 环境中的主要控制分开。
不要把这些边界全部压缩成“Sandbox”。Sandbox 只是一层执行边界，不等于完整的信任模型。
Agent.Space Workspace 隔离负责什么？
截至 2026 年 8 月 28 日，根据 Agent.Space 产品文案与 Workspace 合同核验，产品描述了这些边界：
- 项目、文件和 Session 运行在与其他工作分开的 Workspace 环境中；
- 只有 Owner 与受邀成员能够按自己的角色访问 Workspace 上下文；
- 团队成员使用受支持的服务访问时，不需要交换上游账号或登录密码；
- 代码、文件和结果保持普通目录和标准格式，需要时可以导出；
- 任务数据用于完成用户要求的 Agent 工作，而不是广告。
这些内容定义的是产品边界，并不代表绝对安全，不能替代对 Provider 当前条款的检查，也不能证明产品具备未明确记录的合规认证。
Workspace 只有一份当前文件状态。多个 Agent Session 可以在其中工作，但 Agent.Space 不承诺为每个 Session 提供私有分支、隐藏文件版本、自动冲突解决或隐式回滚。不同 Workspace 之间相互隔离，不等于同一个 Workspace 里的每位写入者彼此隔离。
对团队成员使用最小权限
成员角色控制哪些人能在 Workspace 中执行操作。应该使用能完成当前工作的最小角色。
- **Owner：**管理角色、移除成员、管理邀请，并可以转让唯一的 Workspace 所有权。
- **Editor：**可以修改文件，以及创建或接续 Agent 与 Session 工作。
- **Viewer：**可以检查共享上下文与获准 Preview，但不能修改文件、Agent、Session 或成员。
只读 Reviewer 通常应从 Viewer 开始；必须修改项目的协作者才需要 Editor 或 Owner 能力。项目阶段变化、外部成员离开，或某位成员不再需要写权限时，应重新检查访问。
创建邀请前，可以先阅读 Workspace 角色与权限指南，了解三类角色在实际操作中的区别。
角色边界可以降低成员误改或越权修改的风险，却不会限制一个已经获授权的 Agent 进程如何使用 Runtime 中可用的 Credential 或工具权限。
把 API Key 当作独立的安全边界
API Key 会把任务连接到另一个服务或额度来源，它的作用范围可能超出当前文件树，因此必须与 Workspace 成员关系分开管理。
Agent.Space 的 Developer API 界面支持创建、命名、查看、轮换和撤销 Key。涉及 Secret 的敏感操作需要当前账号重新验证。连接说明要求把完整 Key 保存在服务端或本地环境变量中，不能写进浏览器代码或项目仓库。
可以按下面的生命周期管理：
- **创建用途明确的 Key。**名称应该标出环境或 Integration，而不是只写某个人名。
- **保存在项目内容之外。**不要把它粘贴进源码、Prompt、截图、测试 Fixture 或共享记录。
- **限制周围环境。**即使 Key 存在环境变量中，能够访问该环境的进程仍然可能使用它。
- **无法确认是否暴露时轮换。**Key 可能进入日志、Transcript 或意外文件后，应更换 Credential。
- **Integration 结束后撤销。**删除已经不需要的 Key，比为“以后也许会用”长期保留更稳妥。
Agent.Space Developer API 指南会说明当前连接路径和 Key 管理要求。不要假设 API Key 会自动继承讨论它的 Workspace 成员权限。
限制 Agent 权限，并谨慎处理不可信输入
Coding Agent 可能在仓库文档、Issue 文本、复制的网页、依赖输出、测试 Fixture 和生成文件中读到各种指令。这些内容应该先被当作需要判断的数据，不能自动获得与用户任务相同的权威级别。
Prompt Injection（提示词注入）就是其中一种风险：不可信内容试图改变 Agent 方向、索取 Secret、扩大任务范围或触发外部操作。Runtime 隔离可以限制部分影响，却无法替人判断新指令是否符合原始意图。
可以使用这些实际控制：
- 从任务所需的最小文件、命令、网络和外部目录访问开始；
- 删除、发布、Credential、基础设施或生产数据相关动作必须由人决定；
- 把只读 Review 与编辑任务分开；
- 不要把生产 Credential 放进通用开发环境；
- 批准命令前检查目标、账号和回退路径；
- 文件或工具输出要求 Agent 忽略原始范围、暴露机密数据时，立即停止。
即使在托管 Workspace 中，harness 自己的权限控制仍然重要。一个具体例子是 OpenCode 如何使用 allow、ask 和 deny。不同 Agent harness 与版本的控制方式并不相同，应检查最终生效配置，而不是只凭产品名称判断。
对于 Anthropic harness，可以继续看 Claude Code 权限与沙箱配置指南，把同一原则落实到 deny、ask、allow 与 Bash Sandbox。
让文件可以 Review，也可以恢复
普通文件与导出能力让项目结果更容易迁移，但“可以迁移”不等于自带历史或回滚。
在适合的源码项目中使用版本控制：
- 从一个已知 Revision 开始；
- 保持改动边界并检查 Diff；
- 分开无关工作；
- 针对最终整合状态运行验证；
- 只提交已经 Review 的文件；
- 为真正有风险的数据准备准确恢复路径。
版本控制通常覆盖已跟踪文件，不会自动覆盖所有运行进程、数据库写入、Cloud Mutation、Credential 暴露或外部 API 动作。高影响副作用需要自己的 Preview、批准、备份或恢复机制。
导出 Workspace 结果时，应确认复现工作所需的文件都已包含。不要假设导出内容会带上 Agent 隐藏推理、外部服务状态、临时进程或 Runtime 曾经使用的每个 Secret。
在第一个任务开始前检查安全边界
把 Coding Agent 接入项目之前，先回答下面这些问题。
项目与 Runtime
- Workspace 是否只包含当前任务需要的项目？
- 无关敏感文件是否位于不可达环境中？
- Runtime 能够连接哪些进程或服务？
人员与角色
- 谁是 Owner？
- 哪些成员确实需要 Editor？
- Reviewer 能否使用 Viewer 完成工作？
- 工作结束后是否有移除访问的安排？
Secret 与外部系统
- 哪些 API Key、仓库 Token、数据库和部署账号可以被访问？
- 开发与生产 Credential 是否分开？
- 每个 Credential 能否快速轮换或撤销？
Agent 动作
- 允许哪些读取、编辑、命令和网络动作？
- 哪些动作需要明确批准？
- 哪些操作完全不属于当前任务？
证据与恢复
- 用什么 Diff、Preview、测试或日志证明结果？
- 哪些影响无法自动回滚？
- 谁负责接受安全敏感改动？
如果其中一个问题没有答案，就应该先缩小任务或环境。不要试图用更自信的 Prompt 掩盖模糊边界。
怀疑发生暴露时如何处理？
如果 Secret、敏感文件或意外动作可能已经暴露：
- 停止受影响的 Agent 工作，阻止更多外部操作；
- 撤销或轮换相关 Credential，而不是只从当前可见文件中删除；
- 保留理解事件所需的最少日志与 Diff，同时避免继续传播 Secret；
- 检查仓库历史、共享 Transcript、构建输出、截图和可能保存副本的外部系统；
- 在可能时恢复到已知状态，再重新运行验证；
- 调整导致暴露的角色、权限、环境或 Review Gate。
从当前文件删除 Secret，并不能让历史或日志中的副本失效。真正终止未来使用的是 Credential 撤销。
判断 Workspace 边界是否适合任务
Agent.Space 面向这样的工作：受支持的 Agent harness 在相互隔离的 Workspace 环境中使用持久项目文件、Session、Preview，并与受邀成员协作。它可以减少环境配置与账号共享摩擦，同时让当前项目状态保持可见。
如果工作必须完全留在你独立运营的基础设施中，需要产品未明确记录的认证或控制，或依赖不受支持的工具与模型组合，那么 Agent.Space 可能并不适合。Provider 条款、仓库权限、部署系统与团队自己的数据规则仍然有效。
先查看 Agent.Space 的安全与信任边界，再用非生产 Credential 开始一项边界明确、可回退的任务。扩大任务范围前，分别确认隔离、成员访问、Agent 权限、验证、导出与恢复是否符合要求。