AI Agent 执行 Terraform destroy 前，怎样加一道确定性拦截？AWS SafeBox 本地实践
让编码 Agent 能直接运行 Terraform、AWS CLI 或 kubectl，确实能减少重复操作；但一条合法的命令也可能造成不可逆后果。terraform destroy、kubectl delete 或递归删除 S3 对象，都不应该只靠模型“判断一下是否安全”。AWS SafeBox 的思路是把本地策略放在 Agent 与基础设施命令之间：先按显式规则判定，再决定是否放行。
它拦截什么，又不是什么
SafeBox Community Edition 0.1.0 是 MIT 许可的本地命令防护层，要求 Python 3.11+，面向 macOS 与 Linux。它提供 TOML 规则、命令规范化、破坏性命令检测、复合命令评估和可执行文件代理。默认规则覆盖 Terraform destroy、kubectl delete、EC2 终止实例、RDS 删除、递归 S3 删除和 CloudFormation 删除栈等操作。
关键差别在于，判定依据是本地确定性策略，而不是再问一次模型。无法安全解析的 shell 形式会按 fail-closed 处理；当前文档列出的不支持形式包括管道、后台执行、命令替换和反引号。它支持用 &&、||、; 连接的部分复合命令，但不要因此把任意 shell 脚本都视为已受保护。
先用 check 做无副作用验证
开发安装后，可以先检查一条命令，不执行它：
git clone https://github.com/aws-safebox/aws-safebox.git cd aws-safebox python3 -m venv .venv source .venv/bin/activate python -m pip install -e ".[dev]" safebox check "terraform plan" safebox check "terraform destroy"
README 给出的预期结果分别是允许 terraform plan，以及以 terraform_destroy 规则阻止 terraform destroy。检查操作本身不会运行目标命令。确认策略符合团队预期后，safebox run "terraform plan" 可在判定允许时执行命令；被拦截时不会调用 Terraform。
自定义策略可以明确表达规则，例如：
[[rules]] id = "terraform_destroy" description = "Destroy Terraform-managed infrastructure" action = "block" severity = "critical" command = ["terraform", "destroy"]
指定策略文件检查命令的写法是：
safebox check "terraform destroy" --policy /path/to/policy.toml
示例展示的是工具的策略格式，不代表这条规则足以覆盖所有 Terraform 参数或工作流。把规则应用到真实环境前，应通过测试验证命令解析边界，并为团队的危险操作建立明确的审查流程。
需要常规命令也经过代理时
SafeBox 还支持建立可执行文件代理。运行 safebox setup 后，默认代理目录是 ~/.safebox/bin，默认针对 terraform、aws 与 kubectl 创建代理；它不会自动修改 shell 配置。按官方说明，可把代理目录放在真实工具之前：
export PATH="$HOME/.safebox/bin:$PATH"
之后，Agent 或开发者照常调用 terraform plan，由代理检查后再决定是否转交给真实可执行文件。若要使用其他代理目录，可运行 safebox setup --proxy-dir /path/to/proxy-directory。改动 PATH 前，先确认目录中代理已正确生成，并确保团队成员实际使用的是经过代理解析的命令。
本地护栏不等于安全边界
项目明确说明，SafeBox 不是强化隔离沙箱，也不替代 IAM 最小权限、AWS Organizations SCP、备份、代码审查或环境隔离。能通过绝对路径找到真实程序的进程，可能绕开仅依赖 PATH 的代理；它目前也不分析 Terraform plan 的语义、不区分生产与非生产账号，也不计算影响范围。因此适合把它作为额外的本地防误操作层，而不是唯一控制措施。
一个稳妥的落地顺序是：先在开发容器或测试账号中用 safebox check 验证规则；再用非生产环境验证代理与 PATH；确认阻断行为和允许行为都符合预期后，才考虑纳入团队工作流。对于生产变更，仍应保留云端权限边界与人工审批。
相关链接