最近一段时间，围绕 Claude Code、Cursor、Codex 这类 AI 编程助手的讨论越来越多，各个团队都在探索怎么把 AI 编程能力接入日常开发。但效率提升的同时，安全团队的压力也在快速上升：AI 助手能读仓库代码、能执行 shell 命令、能调用外部 API，它到底接触了哪些敏感信息、执行了什么操作、把什么数据发送到了模型服务端，这些问题如果说不清楚，就很难放心让它在生产环境里大规模使用。
Uber 开源了内部用于监控 Claude Code、Cursor 和 Codex 的安全方案，让这个话题从“要不要监控”进入了“怎么监控”的阶段。本文不打算逐行解读 Uber 仓库里的实现代码，而是结合这次开源背后的工程思路，拆解一套企业可以在自己环境中参考落地的 AI 编程助手安全监控方案。内容包含风险模型、监控链路设计、针对三类工具的差异化配置、一套可运行的极简监控示例，以及高频问题排查思路。适合安全工程师、DevOps、后端开发以及正在推动 AI 编程工具落地的技术负责人阅读。
1. AI 编程助手普及之后，安全团队在焦虑什么
1.1 从“本地工具”变成“高权限代理”
早期我们用 AI 写代码，主要是把代码片段复制到网页对话框里。这种模式下，AI 工具和你本地的代码库、命令行是隔离的，就算不小心泄露了代码片段，影响范围也相对可控。
但 Claude Code、Cursor、Codex 这类工具改变了模型和开发环境的连接方式。它们不再是“代码片段输入工具”，而是“能读文件、能执行命令、能直接修改代码仓库的代理”。
举个例子：
- Claude Code 可以直接在终端里读取项目文件，并根据上下文生成修复方案。
- Cursor 作为 AI 代码编辑器，会索引本地仓库内容，辅助补全和问答。
- Codex 是 Agent 形态的编程助手，可以把一个需求拆解成多个操作步骤，并自动完成。
这些能力让开发效率提升一个档次，但也意味着 AI 工具拥有了类似“开发者本人”的操作权限。如果缺少监控，安全团队很难判断一次异常变更到底是人为操作还是 AI 自动执行的结果。
1.2 Uber 开源安全监控的参考价值
Uber 开源的这一动作，本质上承认了一个现实：AI 编程工具不是简单的“编辑器插件”，它已经成为开发基础设施的一部分。既然是基础设施，就必须有配套的观测、审计和安全响应手段。
对大多数团队来说，Uber 的代码不一定能直接拿来就用，因为每家公司的网络架构、身份体系、合规要求都不一样。但它至少验证了几个方向：
- AI 编程助手的会话是安全事件的重要来源，必须记录。
- 进程级行为采集是通用的监控手段。
- 把工具权限、网络出口、文件访问、敏感信息扫描整合到一条链路里，是完全可行的。
所以这篇文章的重点不是复制 Uber 的实现，而是把这些工程思路变成一套“读者可以自己在测试环境里跑起来”的方案。
1.3 读完本文你能得到什么
如果你负责安全运营，你能得到一套监控 AI 编程助手的分析框架。
如果你是普通开发者或者技术负责人，你能了解到 AI 编程工具的权限模型、常见误用方式，以及如何在团队里建立“不阻碍效率、但能兜住风险”的配置策略。
无论哪种角色，文章中出现的代码和配置都可以直接复制到自己的实验环境里验证，再根据公司实际规范调整。
2. AI 编程助手的安全风险模型
2.1 提示注入与指令篡改
提示注入（Prompt Injection）是 AI 编程场景里最容易理解的安全风险。攻击者可以把恶意指令藏在代码注释、README 文档、第三方依赖包的说明文件，甚至某条 Issue 标题里。
当 AI 编程助手读取这些内容时，相当于收到了来自不可信数据源的“新指令”。如果它的权限足够大，就可能被诱导去执行本不该执行的操作，比如：
- 读取本不该读取的敏感文件。
- 执行隐藏在网络请求返回内容里的命令。
- 在代码中插入后门，再建议开发者提交。
这类问题的核心难点在于，AI 助手分不清“用户本人的指令”和“文档中的恶意指令”的边界。安全监控能做的就是尽量记录 AI 读取了哪些文件、执行了哪些命令，方便事后追溯。
2.2 敏感信息与密钥泄漏
开发者的终端环境里充满了敏感信息。.env文件里的数据库密码、云厂商 AccessKey、内部服务地址、未发布的业务逻辑，随时可能出现在 AI 工具的上下文里。
风险点有两个：
第一，模型服务端可能位于公司外部。如果代码中包含了真实密钥，这些密钥会被发送到第三方模型服务，即使不用于训练，也增加了泄露面。
第二，AI 工具会记录会话历史。如果终端日志、命令历史、IDE 插件日志中混入了密钥，安全监控系统本身也可能成为新的泄露源。
所以，密钥泄漏监控不能只盯着“AI 有没有把密钥发出去”，还要关注“监控日志里有没有落盘真实密钥”。这也是为什么很多安全方案会做脱敏处理。
2.3 不可信代码执行与供应链风险
AI 生成的命令不一定都是安全的。它可能建议你：
- 执行一段从互联网复制的脚本。
- 安装一个名字看起来合理但来路不明的 npm、pip 包。
- 用
curl | bash的方式安装工具。
这些行为的本质是供应链风险。AI 只是根据训练数据和当前上下文生成建议，它并不知道某个包是否已经被投毒。一旦开发者盲目执行，恶意代码就进入了开发环境。
对于安全监控来说，重点不是阻止所有命令执行，而是记录“谁在什么时间执行了什么命令，命令关联了哪些外部下载行为”。
2.4 第三方模型接口与组织策略风险
当开发者使用个人账号登录 AI 编程工具时，企业往往丢失了管控能力。员工可能绕过企业出口网关直接访问模型服务，也可能因为账号权限过大访问了公司不允许的数据。
反过来，如果组织启用了严格策略，又可能出现“your organization has disabled claude subscription access for claude code”这样被限制使用的情况。这些现象本质上都说明：AI 编程工具的身份、订阅、权限已经和企业 IAM 体系产生了强关联，必须纳入统一管理。
下面用一个表格来汇总核心风险类型：
| 风险类型 | 典型攻击/泄漏路径 | 影响 |
|---|---|---|
| 提示注入 | 恶意指令隐藏在代码、文档、第三方包中 | 诱导 AI 执行危险操作、植入后门 |
| 敏感信息泄漏 | 密钥、口令、内网地址进入模型上下文 | 密钥泄露、数据外传、合规风险 |
| 不可信代码执行 | AI 建议执行未知脚本、安装带毒依赖 | 供应链污染、开发机被控 |
| 越权与违规访问 | 开发者使用个人账号、超出授权范围读取代码 | 合规审计缺失、权限边界失效 |
| 组织策略冲突 | 订阅策略/网络策略配置不当 | 工具不可用、绕过管控 |
3. 企业安全监控的整体设计
3.1 先想清楚监控目标
搭建 AI 编程助手安全监控之前，不要一上来就堆工具。建议先回答三个问题：
- 谁能用：哪些开发者、哪些账号可以使用 AI 编程工具。
- 能访问什么：工具能读取哪些代码库、执行哪些命令、发送哪些数据。
- 出问题怎么追溯：当异常发生时，能不能还原完整链路。
这三个问题决定了监控的深度。如果公司只是小规模试用，日志采集到进程维度就够了；如果要在整个研发团队推广，就需要考虑网络层审计、敏感信息检测和告警联动。
3.2 五层监控链路
一个完整的监控链路可以拆成五层：
- 进程层：通过 auditd、EDR 或自研脚本采集 AI 工具进程的执行行为。
- 文件层：记录 AI 工具访问了哪些重要文件，尤其是密钥文件、配置文件。
- 网络层：通过企业出口网关记录 AI 工具与模型服务端的 API 调用元数据。
- 应用层：解析 Claude Code、Cursor、Codex 自身产生的日志和会话记录。
- 行为层：分析命令执行序列，判断是否存在批量读取、批量下载等异常行为。
这五层不一定全都要做，但至少需要覆盖进程层和应用层。网络层是很多团队的盲区，因为 AI 编程工具默认直连外部服务，如果没有统一出口，监控就会出现断层。
3.3 默认拒绝而非默认放行
AI 编程工具的能力边界应该遵循最小权限原则。默认情况下，不应该让工具读取所有文件、执行所有命令、访问所有网络地址。
正确的做法是：
- 只授予当前项目需要的权限。
- 对高危操作（删除文件、修改权限、执行未知脚本）进行二次确认。
- 对生产环境的密钥文件做访问控制，从源头上避免 AI 接触到敏感信息。
最小权限不只是安全策略，它同时也能减少 AI 误操作的概率。权限边界越清晰，AI 生成的风险命令就越少。
4. 面向 Claude Code、Cursor、Codex 的差异化监控
4.1 Claude Code：权限模式与会话审计
Claude Code 是 Anthropic 推出的命令行编程助手，典型的运行方式是直接在终端里执行，读取当前目录下的代码文件并生成操作建议。
使用 Claude Code 时，首先要关注权限模式。不同版本支持的权限模式可能不同，可以使用帮助命令查看：
claude --help在示例场景中，常见做法是限制 Claude Code 只能在当前项目目录下读写文件，并且禁止它执行高风险 shell 命令。类似下面的参数只是示意，需要根据你安装的版本确认：
# 仅作为示例，具体参数以实际版本帮助信息为准 claude --permission-mode acceptEdits从安全监控角度看，Claude Code 的会话内容可能包含大量代码上下文。建议将日志重定向到统一日志采集目录，再通过敏感信息扫描脚本过滤密钥。至少要做到：每条命令执行记录里，能看到执行时间、工作目录、涉及文件。
4.2 Cursor：隐私模式与索引范围控制
Cursor 是目前讨论度很高的 AI 代码编辑器，它和 Claude Code 的区别在于，它本身就是一个 IDE，会索引整个项目目录。
监控 Cursor 时，有几个关键点：
- 隐私模式：建议通过组织策略开启隐私模式，避免代码片段被用于模型训练，具体菜单位置以编辑器的当前版本为准。
- 索引范围：限制 Cursor 只能索引特定目录，阻止它读取生产配置、密钥目录。
- 插件权限：Cursor 插件和普通 VS Code 插件一样，具有扩展能力，需要审查插件来源。
由于 Cursor 有图形界面，进程监控脚本照样可以覆盖它。只要检测到 cursor 进程的启动时间、运行时长和调试日志路径，就能为后续审计提供基础数据。
4.3 Codex CLI：Agent 操作的完整记录
Codex 类工具更接近“自主 Agent”，它可以把一个任务拆成多步操作并自动执行，这意味着它的风险等级比普通补全工具高。
针对 Codex，我建议做三件事：
第一，用沙箱环境运行。让 Codex 在一个隔离的容器或虚拟机里访问代码，避免直接操作宿主机上的生产环境。
第二，记录批准链路。Codex 在执行操作时通常需要审批，安全监控要能记录“哪条命令由谁批准”，这个环节可以对接内部变更审批系统。
第三，审计 API 调用。Codex 会调用代码托管服务、云平台 API，如果有异常的大范围读取行为，应该触发告警。
4.4 统一进程监控：以 auditd 为例
无论使用哪款 AI 编程工具，Linux 平台都可以用 auditd 做进程级行为采集。auditd 是 Linux 自带的审计框架，适合记录文件访问和进程执行。
安装并启动 auditd：
sudo apt-get update sudo apt-get install auditd -y sudo systemctl enable auditd sudo systemctl start auditd添加针对 AI 工具的监控规则：
# 监控 claude 可执行文件 sudo auditctl -w /usr/local/bin/claude -p wa -k ai_agent # 监控 codex 可执行文件 sudo auditctl -w /usr/local/bin/codex -p wa -k ai_agent # 监控用户主目录下 AI 工具配置目录写入 sudo auditctl -w /home/youruser/.claude -p wa -k ai_agent sudo auditctl -w /home/youruser/.codex -p wa -k ai_agent参数含义：
-w：指定要监控的路径。-p：监控权限类型，w表示写入，a表示属性变更。-k：给规则打标签，方便后续检索。
查看审计日志：
sudo ausearch -k ai_agent -ts recent这条命令能查最近一段时间内，与 AI 工具相关的文件写入和属性变更事件。如果团队已经把审计日志接入 SIEM，可以参考这个检索条件做后续分析。
4.5 网络层流量审计
网络层监控最直接的方法是让 AI 工具的出站流量统一经过企业出口网关，并在网关侧记录目标域名、请求体大小、调用频率。
不过这里要处理一个隐私问题：CLI 工具发送给模型服务的内容可能包含源代码片段。如果直接保存完整请求体，反而会扩大敏感数据暴露面。更稳妥的做法是只记录元数据：目标域名、时间、请求字节数、响应状态码。只有在检测到高风险行为时，才把完整会话拉出来人工分析。
常见模型服务域名包括 Anthropic、OpenAI 相关接口。具体域名列表需要根据公司实际使用的服务确认，不要照抄网上的清单，因为服务商可能随时调整。
5. 完整实战：搭建一套极简 AI 编程助手监控示例
这一节从一个空目录开始，逐步搭建一个可运行的监控脚本组合。它不依赖复杂组件，只需要一台 Linux 机器和 Python 3 环境，适合先在小范围测试。
5.1 环境准备
- 操作系统：Ubuntu 22.04（其他 Linux 发行版也可）
- 审计工具：auditd
- Python 3.9+
- 已安装任意一款 AI 编程工具，例如 Claude Code、Cursor 或 Codex
版本不需要刻意统一，本文示例侧重演示监控思路，实际部署时需要根据你的环境微调。
5.2 创建项目目录结构
sudo mkdir -p /opt/ai-monitor/scripts sudo mkdir -p /opt/ai-monitor/config sudo mkdir -p /opt/ai-monitor/logs目录说明：
scripts：存放采集、扫描、告警脚本。config：存放规则配置。logs：存放监控日志和告警记录。
5.3 编写进程采集脚本
新增文件/opt/ai-monitor/scripts/capture_process.sh：
#!/bin/bash # 功能：检测 AI 编程助手进程，并记录到日志文件 LOG_FILE="/opt/ai-monitor/logs/ai-agent.log" mkdir -p "$(dirname "$LOG_FILE")" # 使用 ps 采集进程信息，过滤 AI 工具关键词 ps -eo pid,ppid,etime,cmd \ | grep -E 'claude|cursor|codex' \ | grep -v grep \ >> "$LOG_FILE" 2>&1 # 记录一条空行作为时间分隔 echo "--- $(date '+%Y-%m-%d %H:%M:%S') capture done ---" >> "$LOG_FILE"这个脚本的核心逻辑是：调用ps命令列出所有进程，用grep -E过滤出包含claude、cursor、codex关键字的进程，然后追加写入日志文件。
给脚本添加执行权限：
sudo chmod +x /opt/ai-monitor/scripts/capture_process.sh手动运行一次：
sudo /opt/ai-monitor/scripts/capture_process.sh然后查看日志：
sudo tail -n 20 /opt/ai-monitor/logs/ai-agent.log如果当前没有启动任何 AI 工具，日志里可能只有一行分隔标记，这是正常的。
5.4 编写敏感信息扫描脚本
新增文件/opt/ai-monitor/scripts/scan_secrets.py：
#!/usr/bin/env python3 # 功能：扫描日志中的常见密钥特征，输出命中记录 import re import sys LOG_FILE = "/opt/ai-monitor/logs/ai-agent.log" # 规则列表，实际使用时根据公司标准增删 PATTERNS = [ ("aws_access_key", r"AKIA[0-9A-Z]{16}"), ("openai_api_key", r"sk-[A-Za-z0-9]{20,}"), ("github_token", r"gh[pousr]_[A-Za-z0-9]{36,}"), ("private_key", r"-----BEGIN [A-Z ]*PRIVATE KEY-----"), ] def scan_file(path): hits = [] try: with open(path, "r", encoding="utf-8", errors="ignore") as fp: for line_no, line in enumerate(fp, 1): for name, pattern in PATTERNS: if re.search(pattern, line): hits.append((line_no, name, line.strip())) break except FileNotFoundError: return hits return hits if __name__ == "__main__": target = sys.argv[1] if len(sys.argv) > 1 else LOG_FILE for line_no, key_type, content in scan_file(target): print(f"[{key_type}] line {line_no}: {content}")运行方式：
sudo python3 /opt/ai-monitor/scripts/scan_secrets.py如果日志中出现匹配的密钥格式，脚本会打印出命中行号、密钥类型和内容。需要特别说明：这个脚本只是演示正则匹配的基本思路，生产环境还要做误报过滤、脱敏和动态密钥失效。
5.5 编写告警推送脚本
新增文件/opt/ai-monitor/scripts/push_event.sh：
#!/bin/bash # 功能：将告警内容推送到 Webhook 地址 # 用法：push_event.sh <webhook_url> <title> <message> WEBHOOK_URL="${1:?Usage: $0 <webhook_url> <title> <message>}" TITLE="$2" MESSAGE="$3" curl -s -X POST "$WEBHOOK_URL" \ -H "Content-Type: application/json" \ -d "{\"title\": \"$TITLE\", \"message\": \"$MESSAGE\"}"企业微信、钉钉、飞书、Slack 的 Webhook JSON 结构各不相同，这段代码是通用示例，接入真实告警通道时需要改成对应格式。
给脚本添加执行权限：
sudo chmod +x /opt/ai-monitor/scripts/push_event.sh5.6 组合成一个定时任务入口
新增文件/opt/ai-monitor/scripts/run_scan.sh：
#!/bin/bash # 功能：采集进程信息，并执行敏感信息扫描 SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)" # 1. 采集进程 "$SCRIPT_DIR/capture_process.sh" # 2. 扫描敏感信息 HITS=$("$SCRIPT_DIR/scan_secrets.py" 2>/dev/null) if [ -n "$HITS" ]; then echo "$HITS" >> /opt/ai-monitor/logs/secrets_alert.log # 3. 推送告警（把 URL 替换成真实 Webhook 地址） "$SCRIPT_DIR/push_event.sh" \ "https://example.com/webhook" \ "AI Agent Secret Detected" \ "$HITS" fi给脚本添加执行权限：
sudo chmod +x /opt/ai-monitor/scripts/run_scan.sh加入 crontab 定时执行：
sudo crontab -e添加以下内容：
*/5 * * * * /opt/ai-monitor/scripts/run_scan.sh >> /opt/ai-monitor/logs/cron.log 2>&1这样每 5 分钟会自动执行一次进程采集和敏感信息扫描。
5.7 运行与验证
为了验证扫描能力，可以手动在日志里写入一条测试密钥。注意不要使用真实密钥：
echo "api_key=sk-test1234567890abcdefghijklmnopqrstuvwxyz" >> /opt/ai-monitor/logs/ai-agent.log sudo /opt/ai-monitor/scripts/scan_secrets.py预期输出会包含类似内容：
[openai_api_key] line 5: api_key=sk-test1234567890abcdefghijklmnopqrstuvwxyz这说明扫描脚本工作正常。验证完成后，删除测试日志：
sudo sed -i '/sk-test1234567890abcdefghijklmnopqrstuvwxyz/d' /opt/ai-monitor/logs/ai-agent.log这个极简示例的定位是“最小可用闭环”，它覆盖了采集、检测、告警三个环节。在生产环境落地时，还需要接入正式的日志平台，把ai-agent.log上报到 Elasticsearch、Loki 或其他 SIEM 系统。
6. 常见问题与排查思路
在部署 AI 编程助手安全监控的过程中，可能会遇到工具本身的报错，也可能会遇到监控脚本的问题。下面整理几个高频场景。
| 问题现象 | 常见原因 | 解决思路 |
|---|---|---|
| auditd 规则添加失败 | 路径不存在或权限不足 | 确认可执行文件路径，使用 sudo 执行 |
| 监控日志为空 | 当前没有 AI 工具进程运行 | 启动一次工具后再执行采集脚本 |
| 扫描脚本误报多 | 正则过于宽泛，匹配到示例代码 | 收窄正则，增加白名单，结合上下文判断 |
cc switch local proxy failed while handling codex endpoint /responses | 切换本地接口时和 Codex 服务通信失败 | 检查本地服务地址、网络连通性、认证配置 |
the 'gpt-5.6-sol' model is not supported when using codex with a | 客户端版本与模型能力不匹配 | 升级 CLI 版本，或改用组织支持的模型 |
deepseek-v4-pro is not a model this version of claude code recognizes | 自定义模型别名未正确配置 | 检查模型路由配置，确认模型名称与客户端版本兼容 |
your organization has disabled claude subscription access for claude code | 组织订阅策略限制使用 | 联系管理员开通订阅权限，并记录变更审计日志 |
| Cursor 显示免费次数用完 | 免费额度达到上限 | 配置组织账号或等待额度刷新，避免使用个人账号 |
关于cc switch local proxy failed这类报错，需要说明一点：这里提到的本地服务切换属于开发工具配置问题，而不是网络绕过工具。排查时重点看本地服务进程是否存活、请求路由是否正确、配置中的 endpoint 路径是否有变更。
7. 最佳实践与工程建议
7.1 密钥管理前置
AI 编程助手的安全监控不能替代密钥管理。理想状态是，AI 工具根本接触不到生产密钥。建议把数据库密码、云厂商 AccessKey 等敏感信息迁移到密钥管理平台，在代码仓库中只保留占位符。这样即使日志泄漏，攻击者拿到的也不是有效密钥。
7.2 日志脱敏与数据分级
监控系统本身也是敏感数据的存储方。进程日志可能包含命令参数，命令参数里可能带有密码。在日志进入集中存储之前，需要做脱敏处理。
推荐的日志分级策略：
- 普通调试日志：保留进程名、时间、操作类型，不记录完整参数。
- 安全审计日志：保留完整命令，但必须加密存储，并限制访问权限。
- 告警日志：只保留脱敏后的摘要和关联事件 ID。
7.3 使用沙箱运行高风险 Agent
Codex 这类自主 Agent 工具，优先在容器内运行：
docker run --rm -it \ -v /path/to/project:/workspace \ -w /workspace \ --read-only \ my-ai-agent-image关键点是给容器配置只读文件系统，并限制网络访问。如果 Agent 需要联网，再单独开放白名单域名。这样即使发生意外，也不会污染宿主机环境。
7.4 建立异常分级响应机制
不是所有监控告警都需要立即阻断。建议建立三个等级：
- 低危：检测到可疑的密钥格式，但无流量外发证据。只需记录并通知开发者自查。
- 中危：AI 工具访问了敏感目录，或向外部域名发送了大体积请求。需要安全团队介入分析。
- 高危：发现已知恶意命令、疑似后门代码、密钥外发。需要立即断开网络、轮换密钥、隔离开发机。
7.5 与现有安全体系联动
AI 编程助手监控不应该独立存在。建议把审计日志和事件关联到现有 SIEM，并和身份认证系统、代码托管平台联动。当检测到异常时，能直接定位到对应开发者账号和代码仓库，而不是只有一串进程 ID。
8. 总结与后续学习方向
本文从 Uber 开源 Claude Code、Cursor、Codex 安全监控这一事件切入，梳理了 AI 编程助手面临的风险模型，并给出了一套从风险分析、监控链路设计到极简落地示例的完整思路。核心要点可以总结成几句话：
AI 编程助手的安全监控不是要限制创新，而是要让创新处在可观测、可追溯的边界内。最小权限、日志采集、敏感信息扫描、分层告警，这四件事做好了，大部分风险都能兜住。
下一步可以沿着这些方向继续深入：
- 学习 eBPF 技术，在更底层捕获系统调用和网络行为。
- 研究模型服务端的审计接口，看是否能把会话级事件直接拉回企业日志平台。
- 梳理公司内部的密钥管理流程，把 AI 工具的权限控制与身份平台统一。
如果你正在公司里推进 AI 编程工具的落地，建议先从一个小团队开始，搭建一套最简监控，运行两周后复盘日志中出现了哪些异常，再逐步扩大范围。安全方案只有真正跑在真实开发流程里，才会变得可靠。如果这篇文章对你有帮助，可以收藏备用，后续有新的实践也会继续分享。
