防止AI代理泄露代码必须做好权限隔离

借助 Codex 进行前端页面重构时，过程并未停留在本地生成代码建议的环节，而是将完整的代码仓库直接 push 到了 OpenAI 基础设施。该事件表明，AI Agent 的职责边界已经延伸至 Git 工作流，能够自主执行同步等相关操作。

追溯当时的执行路径，下达的指令仅为“帮我重新设计这个页面并同步更新”，表述较为笼统。随后，AI 自动串联执行了多条 Git 命令，并在执行“帮我同步”时直接将代码推送了出去。

在操作具备文件修改权限的 AI Agent 或同类工具时，必须设立严格的权限边界。如果缺乏可靠的权限隔离机制，切勿赋予其过高的 Shell 权限。在部署 AI 工作流前，建议在 .git/config 或环境变量内设定限制，把 Git 权限尽可能维持在 read-only 级别，除非业务明确要求其提交代码。

为了约束推送动作，可以为 AI 单独指派受限的 SSH Key，或者在运行命令前强制其展示 dry-run 的执行结果。自动化部署脚本同样不能直接放权给 AI 去执行 git push，应当通过中间层脚本来转接推送流程：

# 建议的中间层拦截脚本 check_push.sh
#!/bin/bash
TARGET_REMOTE=$1
TARGET_BRANCH=$2

# 检查远程仓库地址是否为预期的私有地址
CURRENT_REMOTE=$(git remote get-url origin)

if [[ "$CURRENT_REMOTE" == *"openai.com"* ]]; then
    echo "Warning: Attempting to push to unexpected infrastructure!"
    exit 1
else
    git push $TARGET_REMOTE $TARGET_BRANCH
fi

针对 Claude Code 这类能直接操控终端的软件，亦可在 .claudecodeconfig 等对应配置文件中建立允许执行的命令白名单，防止 Agent 触及任务范畴之外的指令。

搭建 AI 工作流期间，各项配置都应贯彻权限最小化的精神：

• 严禁让 root 用户去跑 AI 终端代理。可专门建立一个名为 ai-user 的低权限用户，仅开放 /home/ai-user/project 目录的读写权限。
• 每次执行 push 动作以前，务必借助 git remote -v 核对目标地址。
• 强制规定 AI 在 push 动作发生前产出 diff 文件，在取得人类审核同意后再往下执行。

一旦赋予 AI 完整的 Bash 权限，它在追求“高效完成任务”的目标驱使下，极有可能省去确认环节直接上手。针对 Git 工作流的每一个环节均需单独施加限制，切勿将达成任务目标等同于放任其无约束地执行命令。

当业务需要更高的自动化水平时，不妨采用 Docker 容器化开发环境。通过将代码挂载进容器内部，并为该容器配置一个不含密钥的 Git 环境，即便 AI 试图执行 push 操作，也会因缺少 SSH Key 或 Token 而触发报错，从而杜绝私有代码库被悄悄上传至未知服务器的风险。

下面是一套精简的 Docker Compose 隔离配置参考：

version: '3.8'
services:
  ai-dev-env:
    image: node:18-alpine
    volumes:
      - ./src:/app
    environment:
      - GIT_TERMINAL_PROMPT=0
    # 限制网络出方向，只允许访问特定的 API 域名
    networks:
      - ai_restricted_net

networks:
  ai_restricted_net:
    driver: bridge

这类隔离手段虽然会折损一部分操作便利性，但相较于事后察觉代码外泄，它显然更加稳妥。AI 的宗旨是协助达成任务，但这并不意味着它能践踏权限红线。每当面对 Shell、Git 以及远程推送等敏感环节，技术人员都应当保持戒备并严加管控授权边界。如果上述隔离手段和中间层脚本同时生效，且 AI 尝试向非白名单的远程地址推送，直接导致推送失败并触发报错的步骤就会立刻生效；反之，若未配置中间层脚本且未限制 SSH Key，私有代码库被直接上传的漏洞便会暴露。