4.9 KiB
执行与安全
本章讲 Astrion 如何安全地执行 AI 发起的操作：沙箱执行的实际行为、路径授权、审批机制。概念层面的四组开关（部署/权限/执行环境/运行模式）请先看《核心概念》，本章聚焦具体行为与日常管理。
范围说明：「实时终端」只是观察面板，与安全机制无关，见《对话》一章。
1. 命令是怎么被执行的（host 模式）
run_command：两段式执行
以默认推荐的 approval 模式为例，一条 AI 发起的 shell 命令的实际旅程是：
- 先在只读沙箱执行——能读不能写；
- 如果命令没碰写操作，直接返回结果，全程无感；
- 如果触发权限拒绝（要写文件、要改系统），自动转为向你发起审批；
- 你批准后，仅这一条命令以可写沙箱重试；你拒绝或超时未处理，则本次不执行；
- AI 拿到的是最终结果，中间过程不干扰它的思路。
auto_approval 模式把第 3 步的审批者换成自动审批智能体；unrestricted 模式跳过审批直接执行；readonly 模式下写入类请求直接拒绝。
终端会话：切换即关闭
持久终端会话（terminal 系列工具）在启动时绑定当时的执行环境与沙箱策略。当你切换执行环境（sandbox ⇄ direct）、切换工作区或容器时，现有终端会话会被直接关闭——不会带着旧策略继续运行，后续操作在重新拉起的会话中按新策略执行。这也意味着：跑长任务时不要切换这些开关，任务会随会话一起终止。
子智能体与后台命令
子智能体的终端进程同样经过执行环境策略：sandbox 下经宿主机沙箱启动，direct 下直接宿主机启动；docker 模式则在容器内执行。后台命令（run_in_background）与前台命令走同一套只读/可写沙箱判定，不会因为放后台就绕过权限。
2. 路径授权的日常管理
入口：输入栏 + 菜单 →「路径授权」。
- 可读可写路径：AI 的完整工作范围，通常就是你的项目目录；
- 仅可读路径：允许 AI 参考但禁止修改，比如参考文档、线上配置样例、别的项目源码。
建议实践：
- 保持最小授权——只加当前任务需要的目录；
- 敏感目录（
~/.ssh、密钥库、系统目录）永远不要加入任何一类； - 任务性质变化时及时调整，授权是即时生效的（新终端会话除外，见上）。
3. 网络权限
输入栏权限菜单中独立的一组：
- 受限（默认）：仅本地回环，AI 无法访问外部网络——适合纯本地任务，也杜绝了数据外发；
- 完全开放：允许出站/入站连接——需要 AI 联网搜索、调外部 API、装依赖时开启。
网络权限与文件沙箱相互独立，且在 plan 模式下也可调整。
4. 审批面板
入口：+ 菜单 →「审批面板」。这里能看到审批记录：哪些命令/写入被提请审批、谁批的（人工或自动审批智能体）、结果如何。auto_approval 模式下如果不想让面板自动弹出打扰，个人空间有开关（默认不自动打开）。
5. 禁止命令清单
部署级配置 forbidden_commands.json（放 <数据根>/config/）可以配置绝对禁止执行的命令特征，命中即拒，与权限模式无关。这是兜底防线，适合在服务器部署时封死 rm -rf /、shutdown 这类命令。
6. 关于 direct 模式的忠告
direct = 命令直接在宿主机执行，没有任何沙箱。合理使用场景只有一个：某条命令在沙箱里确实跑不了（需要系统级权限），且没有替代方案。此时：
- 临时切到 direct；
- 跑完立即切回 sandbox；
- 注意 direct 切换后永久生效、不会自动回退——忘记切回等于长期裸奔。
7. docker 模式的安全现状
docker 模式下，隔离边界是容器本身：每个用户的终端在独立容器中，互相不可见。但要注意：
- 目前没有与 host 模式同等的 OS 级只读沙箱，「只读→审批→可写重试」两段式在容器内不适用，容器内的权限约束主要靠提示词层面的规范；
- 多用户部署时应配合容器资源限制、镜像最小化等常规容器安全实践。
8. 各平台安全水位
再次强调《核心概念》中的结论，因为它直接影响你该信任沙箱到什么程度：
- Windows（WSL2）：可做到完全数据隔离，需先安装 WSL2；
- macOS（sandbox-exec）：能限制写入，但文件系统全局可读，不能防止数据泄露，请勿在可读范围内放置敏感数据；
- Linux（bwrap+seccomp）：尚未实测，不要依赖其隔离性。
无论哪个平台，沙箱的首要价值是防误操作；涉及真正的敏感数据，请叠加路径授权最小化、网络受限、readonly 权限等手段综合防护。