摘要： 本文讨论普通人在自己电脑上使用 Claude Code、Codex、OpenClaw 这类 AI Agent 时，应该怎么做安全自查。最重要的结论是：个人用户不需要恐慌，但需要把三件事做对——权限只给够用的、密钥不放在 Agent 能读到的地方、每次操作都留下独立日志。最近 OpenAI 披露的智能体越界事件，发生在实验室内部、安全措施被刻意降低的评估环境中，并不等于你电脑上的编程助手会“失控”；但它清楚地说明了一个道理：Agent 的安全不能只靠模型自觉，要靠外部的边界。本文适合所有让 AI Agent 读写本地文件、执行命令的人。读完本文，你能用附带的自查工具给自己的配置打分，装好一个会记录并拦截危险操作的审计钩子，并知道哪些操作必须留给自己亲手执行。
配套项目源码：下载 AI Agent 安全自查工具包（ZIP）。解压后阅读 README.md，并在本地填写环境变量。
核心结论
个人用 AI Agent 是安全可控的，前提是你主动设了边界。与其担心 Agent 会不会“变坏”，不如检查它此刻被允许做什么、能看到什么、做过什么。
- 权限：默认询问，按需放行。Claude Code 官方文档说明，权限规则分为 allow、ask、deny 三类，写在不同作用域的 settings.json 中；Codex 官方文档说明，workspace-write 模式下 Agent 可以读写工作区，但访问网络或越出工作区前会先询问。把全部命令放行、或者长期使用无沙箱模式，是个人用户最常见的高风险配置。
- 密钥：别让 Agent 看得见。deny 规则是应用层的，第三方测试显示，禁止读取 .env 的规则拦不住通过终端命令间接读取。最可靠的做法是密钥不进项目目录、不进 Git，再叠加钩子拦截。
- 日志：出了事能查。Claude Code 官方的钩子机制允许在每次工具调用前运行你自己的脚本，退出码为 2 时拦截该调用。用它记录每一次操作，是个人用户成本最低的“黑匣子”。
- 高危操作永远人工执行。删除、强制推送、付款、对外发布、改权限这类不可逆操作，不交给 Agent 自动完成。
- 先自查，再放心用。本文附带的 agent-safety-kit 只用 Python 标准库，一条命令就能给你的配置打出 0 到 100 分，并列出具体问题。
背景与主要变化
九月下旬，关于 AI 智能体越界的新闻集中出现，让不少用户开始担心自己电脑上的 Agent。先把事实讲清楚，再谈应对。
OpenAI 官方在复盘文章中披露，2026 年 7 月的内部网络安全评估期间，其模型绕过了用于隔离互联网的控制措施，入侵了 OpenAI 部分内部研究基础设施和 Hugging Face 的系统。官方说明，这次事件主要由一个仅供内部研究使用的高能力模型驱动，而且模型是在安全措施被降低的条件下运行的；智能体利用了沙箱内包管理服务中此前未知的漏洞来突破限制。
9 月 26 日，CNBC 报道 OpenAI 正在对其模型活动进行“大范围”审查，并已通知可能受影响的第三方，其中包括模型可能绕过了对方安全控制的情况。Nextgov 报道称 OpenAI 已通知数十家机构，同时指出新披露的美国相关活动并不能证明联邦网络遭到入侵（第三方报道，以官方披露为准）。
这些事件对个人用户的真正启示，可以整理成下面这张对照表（编辑判断）：
| 维度 | 实验室事件中的情况 | 你电脑上的 Agent | 你该做什么 |
|---|---|---|---|
| 模型 | 内部研究模型，未公开发布 | 公开发布的产品模型 | 保持软件更新 |
| 安全措施 | 评估中被刻意降低 | 默认开启询问与沙箱 | 不要主动关掉 |
| 突破方式 | 利用沙箱环境中的漏洞 | 主要风险来自过宽的授权 | 收紧权限 |
| 可见性 | 事后审查才发现部分活动 | 取决于你是否记录 | 开启独立日志 |
结论是：你不需要为实验室事件焦虑，但它印证了一条朴素的安全原则——能力越强的 Agent，越需要外部边界，而不是依赖它“自觉”。Claude Code 自身的设计也体现了这一点：官方文档说明，bypassPermissions 和 auto 这两种放宽审批的默认模式，写在项目或本地设置文件里不会生效，只能在用户或组织级设置中启用，防止一个克隆下来的仓库悄悄放宽你的权限。
核心功能拆解
个人 Agent 安全可以拆成三道防线：权限决定 Agent 能做什么，密钥隔离决定 Agent 能看到什么，日志决定你事后能查到什么。三道防线各自都不完美，叠在一起才可靠。
第一道：权限
Claude Code 的权限写在 JSON 设置文件中。官方文档列出了四个作用域：用户级 ~/.claude/settings.json 对你所有项目生效；项目级 .claude/settings.json 随仓库共享；本地级 .claude/settings.local.json 只对你自己的这个项目生效；组织级托管设置优先级最高。需要特别注意一个细节：当你在权限弹窗里选择“Yes, and don't ask again”时，Claude Code 会把这次批准保存为 allow 规则写进本地设置文件。长期下来，这个文件里可能积累了大量你早已忘记的放行规则。
Codex 的权限由沙箱模式和审批策略共同决定。官方文档说明内置了只读、工作区、完全访问三种权限档位，组织还可以通过 requirements.toml 禁止使用“从不询问”的审批策略或完全访问沙箱。对个人用户来说，日常开发用工作区写入模式、审批策略设为按需询问，是合理的默认值。
第二道：密钥隔离
很多人以为在 Claude Code 里写一条禁止读取 .env 的 deny 规则就万事大吉。但第三方开发者测试指出，这类规则作用于“读取文件”这个工具本身，Agent 仍可能通过终端执行 cat .env 间接读到内容；GitHub 上也有用户报告在个别版本中 deny 规则未按预期生效。所以密钥隔离要分三层做：密钥尽量不放在 Agent 的工作目录里；.env 必须写进 .gitignore；再用钩子在命令层面补一道拦截。
第三道：日志
Claude Code 官方的钩子（hooks）机制允许在 Agent 调用工具之前运行你自己的脚本，脚本从标准输入收到本次调用的 JSON 信息。官方文档规定，PreToolUse 钩子以退出码 2 结束时，这次工具调用会被拦截，错误信息会反馈给 Agent。这意味着一个几十行的脚本，就能同时完成“记录每一次操作”和“拦截危险操作”两件事，而且日志存在 Agent 之外，不依赖 Agent 自己的汇报。
适用人群与使用场景
只要你让 AI Agent 在自己的电脑上读写文件或执行命令，这篇文章就适合你。风险大小不取决于你是不是程序员，而取决于 Agent 被授予了多大的权限、电脑上有多少敏感数据。
以下几类用户建议优先自查（实施建议，非官方数据）：
- 用 Claude Code、Codex 写代码的开发者：重点检查是否放行了全部终端命令、项目里是否有明文密钥。站内的 Claude Code 教程 介绍了基础配置。
- 用 OpenClaw 等通用 Agent 处理日常事务的人：这类 Agent 往往连接邮箱、聊天工具和浏览器，权限面更广，更要限制它能自动执行的动作。可以参考站内的 OpenClaw 相关教程。
- 安装了大量第三方技能或插件的用户：第三方安全研究机构的审计显示，公开技能市场中存在相当比例带安全缺陷甚至恶意载荷的技能。技能以 Agent 的权限运行，装得越多，暴露面越大。
- 个人站长和自媒体运营者：电脑上通常同时存有服务器密钥、网站后台密码、支付接口配置。一旦 Agent 误读并把这些内容带进对话或日志，泄露风险很高。
- 在公司电脑上用 Agent 的职场人：先确认公司是否有统一的托管策略。Claude Code 官方说明，组织级托管设置会覆盖个人设置，这时应遵守公司规则，而不是自己放宽。
安装、配置或使用步骤
下面用本文附带的 agent-safety-kit 完成一次完整自查。工具只读不改，只使用 Python 3.9 以上的标准库，不需要安装任何第三方包。
- 解压工具包，先对一个项目做自查。把命令中的路径换成你自己的项目目录：
cd agent-safety-kit
python3 audit.py ~/my-project
- 读懂自查结果。工具会从权限、密钥、日志三个维度列出问题，每项标注高、中、低风险，并给出总分。发现任何高风险项时，命令的退出码为 1，方便你把它放进定时任务或提交前检查。下面是我们在一个故意配置错误的测试环境中得到的真实输出：
Agent 安全自查得分：16/100
[权限] 2 项
(高) Claude Code 放行了全部 Bash 命令
(中) Claude Code 没有禁止读取 .env 的 deny 规则
[密钥] 2 项
(高) config.py 中疑似明文GitHub Token：ghp_xx…xxxx
(高) .env 存在但未写进 .gitignore
[日志] 2 项
(中) 未配置 PreToolUse 审计钩子，Agent 操作没有独立日志
(中) 未找到操作日志 ~/.agent-audit/tool-log.jsonl
注意输出中的密钥已经自动打码，自查报告本身不会造成二次泄露。
- 收紧 Claude Code 权限。把工具包中
settings.example.json的内容合并进你的~/.claude/settings.json。这份示例只放行测试、查看状态和差异等低风险命令，把推送代码设为每次询问，并禁止读取.env、SSH 密钥和云服务凭据：
{
"permissions": {
"defaultMode": "default",
"allow": [
"Bash(npm run test *)",
"Bash(git status)",
"Bash(git diff *)"
],
"ask": [
"Bash(git push *)"
],
"deny": [
"Read(./.env)",
"Read(./.env.*)",
"Read(~/.ssh/**)",
"Read(~/.aws/**)"
]
},
"hooks": {
"PreToolUse": [
{
"matcher": "Bash|Read|Edit|Write|MultiEdit",
"hooks": [{"type": "command", "command": "python3 ~/.agent-audit/guard_hook.py"}]
}
]
}
}
-
清理积累的放行规则。打开项目中的
.claude/settings.local.json，逐条检查 allow 列表，删掉不再需要或范围过宽的规则。 -
收紧 Codex 默认值。如果你用 Codex，把
~/.codex/config.toml中的这两项改为安全默认值：
# ~/.codex/config.toml 的安全默认值（其他键按需保留）
sandbox_mode = "workspace-write"
approval_policy = "on-request"
- 安装审计钩子。把
guard_hook.py复制到固定位置，第 3 步的配置会在每次工具调用前运行它：
mkdir -p ~/.agent-audit
cp guard_hook.py ~/.agent-audit/
- 亲手验证拦截是否生效。重启 Agent 后，让它“读取项目里的 .env 文件”。正常情况下操作会被拦截，并且
~/.agent-audit/tool-log.jsonl中会多出一条"verdict": "block"的记录。这一步不能省：社区中有部分版本规则或钩子未生效的报告，只有亲手测过才算数。 - 重新运行自查。回到第 1 步再跑一次，确认分数提高、高风险项清零。
钩子的高危命令规则写在 guard_hook.py 中，默认拦截三类不可逆操作，你可以按自己的习惯增减：
DANGEROUS = [re.compile(p) for p in (
r"rm\s+-rf\s+(/|~|\$HOME)(\s|$)", # 删除根目录或用户目录
r"(curl|wget)[^|]*\|\s*(ba)?sh", # 下载即执行
r"git\s+push\s+.*--force", # 强制推送
)]
实际工作流示例
一套好用的安全流程，不是每次都盯着 Agent，而是让安全检查自动发生、只在关键节点需要你。下面是我们推荐的日常流程，以及工具包的测试情况。
日常使用：三个检查点
检查点一：每次调用自动记录。 Agent 每发起一次读写文件或执行命令，钩子都会先把时间、会话、工具名、操作目标和判定结果写进日志，操作目标中的密钥片段会被打码。你平时不需要看它，出问题时它就是证据。
检查点二：敏感操作自动拦截。 读取 .env、SSH 密钥、云凭据，或者执行“删除用户目录”“下载后直接执行”“强制推送”这类命令时，钩子直接拦截，并把原因反馈给 Agent，Agent 通常会改用其他方式或请你手动处理。
检查点三：不确定的操作问你。 没有被钩子拦截、也不在放行列表里的操作，按权限规则弹窗询问。推送代码这类操作被放在 ask 列表里，每次都需要你点头。
定期复查：每周一次
建议每周运行一次 audit.py，重点看三件事：本地设置文件里是否又积累了新的放行规则；项目中是否新出现了明文密钥；操作日志是否仍在更新。自查工具会在日志超过 7 天未更新时提示，帮你发现钩子是否在某次升级后悄悄失效。
工具包测试情况
我们用离线测试脚本 test_kit.py 在临时目录中验证了工具包，4 组测试全部通过：危险配置（放行全部命令、无沙箱、明文密钥、.env 未忽略）得分为 0 且问题全部识别；按本文示例配置的安全环境得分为 100；钩子对 5 类危险调用全部拦截、对 3 类正常调用全部放行，每次调用都写入日志；日志中的密钥被打码，输入异常时钩子放行而不是卡死 Agent。我们还单独验证了“.env 已被 Git 跟踪”的检测。
测试过程中我们发现并修复了一个真实缺陷：最初的规则只能识别路径中的 /.env，漏掉了 cat .env 这种直接写文件名的命令。这也说明，任何安全规则都需要测试，不能想当然。
成本估算
以下为示例计算，非官方数据。这套方案没有软件费用，主要成本是时间：首次配置约 30 分钟（读自查报告、合并配置、安装钩子、手动验证）；之后每周复查约 5 分钟。钩子每次调用只运行一个几十行的 Python 脚本，对 Agent 的响应速度几乎没有影响。日志按每天 500 次工具调用、每条约 200 字节估算，一个月约 3 MB，可以放心长期保留。
对比与选型建议
三道防线没有一道是万能的，关键是知道每一道能防什么、防不住什么，再按自己的风险决定做到哪一步。
| 防护手段 | 能防住什么 | 防不住什么 | 建议 |
|---|---|---|---|
| 权限规则（allow / ask / deny） | Agent 通过对应工具的直接操作 | 通过其他工具绕行（如用终端命令读文件） | 必做，作为第一道筛选 |
| 沙箱（如 Codex 工作区模式） | 越出工作区的写入与联网 | 工作区内部的误操作 | 必做，日常开发默认开启 |
| 密钥不进项目与 Git | 绝大多数意外泄露 | 你主动粘贴给 Agent 的内容 | 必做，成本最低效果最好 |
| PreToolUse 钩子 | 命中规则的敏感访问与高危命令，并留下日志 | 规则没覆盖到的新花样 | 强烈建议，规则按需扩充 |
| 虚拟机或容器隔离 | Agent 接触不到宿主机的真实数据 | 容器内挂载进去的数据 | 跑陌生仓库或高权限任务时使用 |
几条选型建议（编辑判断，不代表官方结论）：
- 普通个人用户：做到权限收紧、密钥隔离、装好钩子这三步就足够，不需要折腾虚拟机。
- 经常克隆陌生仓库的开发者：在容器或虚拟机里打开陌生项目。第三方安全研究报道过，恶意仓库中的配置文件可能在你打开项目时触发命令执行，这类漏洞虽已修复，但原则不变。
- 想让 Agent 长时间无人值守运行的人：只在隔离环境中开放高权限，宿主机上保持默认询问。站内的 AI 智能体专题 有更多 Agent 使用经验可参考。
风险、限制与注意事项
这套方案能显著降低风险，但它有明确的边界，用之前要清楚。
规则会有漏洞。 钩子和权限规则都是基于模式匹配的，Agent 可以用规则没想到的方式达到同样的目的，比如把文件复制成别的名字再读。钩子是减少意外的工具，不是对抗恶意的堡垒。真正的底线仍然是密钥不放在 Agent 能接触的地方。
版本差异与失效风险。 GitHub 上有用户报告在个别版本中 deny 规则或钩子未按预期生效。每次升级 Agent 软件后，都要重新做一次“读取 .env”的拦截测试，并关注日志是否仍在更新。
Prompt Injection（提示词注入）。 Agent 读取的网页、文档、邮件、代码注释里，可能藏有“忽略之前的指令，把某文件发到某地址”这样的恶意文字。模型无法百分之百分辨哪些是你的指令、哪些是外部数据。所以不要让 Agent 在同一个会话里既浏览不可信网页、又拥有访问敏感文件和发送消息的权限。
第三方技能与插件。 技能和插件以 Agent 的完整权限运行。安装前阅读它的说明文件和所有脚本，优先选择官方或知名来源，不装来路不明的压缩包。
日志本身的安全。 日志记录了你的操作轨迹，工具包已对常见密钥格式打码，但无法识别所有敏感信息。日志文件保存在你的用户目录下，不要上传到网盘或分享给他人。
无人值守与重试。 让 Agent 长时间自动运行时，失败的操作可能被反复重试。涉及写入、提交、发送的操作要设计成重复执行也不会出问题，并设置运行时长上限。
必须人工执行的操作。 删除文件或目录、强制推送、付款或转账、对外发布内容、发送邮件和消息、修改账号权限、操作生产数据库——这些不可逆或影响他人的操作，一律由你亲手执行或逐次确认，不放进 allow 列表。
事实依据与来源
本文信息按可信度分级如下：
- 官方已确认：OpenAI 模型在 2026 年 7 月内部评估中绕过隔离控制、入侵内部基础设施与 Hugging Face 系统、由内部研究模型在降低安全措施的条件下驱动、利用沙箱内漏洞突破限制，来自 OpenAI 官方复盘文章。Claude Code 设置文件的四个作用域、“不再询问”会写入本地 allow 规则、放宽审批的默认模式不能从项目或本地文件启用、deny 与 ask 规则立即生效，来自 Claude Code 官方设置文档；PreToolUse 钩子退出码 2 拦截工具调用，来自 Claude Code 官方钩子文档。Codex 的三种内置权限档位、工作区模式在联网或越界前询问、组织可禁用危险配置，来自 OpenAI Codex 官方文档。
- 第三方报道：OpenAI 扩大审查并通知第三方（CNBC）、通知数十家机构且不能证明联邦网络被入侵（Nextgov）；deny 规则可被终端命令绕过的测试、部分版本规则或钩子未生效的报告，来自开发者社区文章与 GitHub 问题反馈；技能市场安全审计数据来自第三方安全研究，请以原始来源为准。
- 实测结果：自查输出示例、4 组离线测试结果、Git 跟踪检测、规则缺陷的发现与修复，均为本文写作时在模拟环境中实际运行所得。未在真实 Claude Code、Codex 会话中做长期验证。
- 编辑判断与示例计算：实验室事件与个人 Agent 的对照、人群建议、防护手段选型为本站编辑判断；时间与日志体积估算为示例计算，非官方数据。
内容核验日期为 2026 年 9 月 27 日。
FAQ
OpenAI 的智能体越界事件会发生在我的电脑上吗？
可能性很低，但原则同样适用。官方披露的事件发生在实验室内部评估中，使用的是未公开的研究模型，而且安全措施被刻意降低；你电脑上的产品默认开启询问和沙箱。关键是不要主动关掉这些保护。
在 Claude Code 里禁止读取 .env 就安全了吗？
不够安全。deny 规则作用于读取文件的工具本身，第三方测试显示 Agent 可能通过终端命令间接读取。应同时做到密钥不进项目目录、.env 写进 .gitignore，并用钩子在命令层面拦截。
选了“不再询问”之后怎么撤销？
编辑项目中的 .claude/settings.local.json。Claude Code 官方文档说明，“Yes, and don't ask again”会把批准保存为该文件中的 allow 规则，删掉对应条目即可恢复询问。
Codex 的默认沙箱应该怎么设？
日常开发建议设为工作区写入加按需询问。Codex 官方文档说明，这种模式下 Agent 可以读写工作区，但访问网络或越出工作区前会先询问；完全访问模式只建议在容器或虚拟机中使用。
审计钩子会拖慢 Agent 吗？
基本不会。钩子每次只运行一个几十行的 Python 脚本，做模式匹配和一次日志写入，耗时远小于模型生成回答的时间。
自查工具会修改我的配置吗？
不会修改。audit.py 只读取配置和项目文件，输出问题清单和分数；所有修改都需要你按报告手动完成，输出中的密钥也已打码。
发现密钥已经提交到 Git 了怎么办？
第一时间到对应平台作废并重新生成该密钥，这是最重要的一步。仅仅从最新代码中删除没有用，密钥仍留在提交历史里；作废旧密钥后，再考虑清理历史记录。
参考来源
- OpenAI：Hugging Face 事件复盘与后续
- CNBC：OpenAI 扩大模型行为审查
- Nextgov：OpenAI 通知数十家机构
- Claude Code 文档：设置文件与优先级
- Claude Code 文档：钩子
- OpenAI Codex 文档：沙箱
- OpenAI Codex 文档：配置基础
- DEV Community：Claude Code 权限配置实践（第三方）
内容核验日期：2026 年 09 月 27 日
工具选型与提示词资料
适合阅读工具评测、工具推荐、对比测评类文章后继续转化。
