正文

OALABS 在 2026-06-16 披露了一起 AI Agent 被滥用于进攻性网络操作的案例。报告称，攻击者使用 Claude 和 Codex 这类 Agent 辅助完成目标识别、侦察、漏洞验证、脚本编写和数据整理等步骤。Help Net Security 和 TechRadar 后续也转述了这起事件，其中 TechRadar 提到受影响组织数量达到 14 家。

这件事对开发者的提醒很直接：AI Agent 不是只能写代码的聊天框。只要它能跑命令、访问网络、读文件、调用工具或接触凭据，它就可能参与真实攻击链。你启动 Claude / Codex 前，先把权限边界收窄，再让它进入项目。

现在先检查不要默认放开
命令执行Shell、安装依赖、脚本、删除、Git 写操作
网络访问外部 API、下载脚本、扫描目标、上传日志
凭据读取.env、SSH key、npm token、GitHub token、云厂商密钥
外部工具MCP、浏览器、数据库、邮件、GitHub、CI
留痕审计工具调用、命令参数、diff、日志、token 轮换记录

这起事件说明了什么

OALABS 的报告重点不在“模型自己攻击了谁”，而在攻击者把 Agent 当成了执行放大器。低门槛提示词可以让 Agent 协助拆解目标、生成命令、改脚本、整理结果，并把多步操作串起来。

对日常开发者来说，真正危险的地方不是你会不会主动攻击别人，而是你本地的 AI 工作台也具备类似能力：

  • 它能读仓库和配置文件。
  • 它能建议或执行 Bash / PowerShell 命令。
  • 它能安装 npm、PyPI、Cargo 依赖。
  • 它能访问网络、下载脚本或调用 API。
  • 它能接 MCP Server、浏览器、GitHub、数据库和内部系统。
  • 它可能在日志、提示词或工具参数里接触 token 和客户数据。

如果这些能力没有边界，Agent 出错、被提示注入、装到恶意包、接入恶意 MCP Server，或者被用户随手允许高风险命令时，影响就不再停留在“生成了一段坏代码”。

启动 Agent 前先选权限模式

先把默认模式设成“能看当前项目、能改当前任务、越界要问”。不要把全盘文件系统、网络和高风险命令一次性放开。

场景建议边界
读代码、找文件、看 diff可以自动执行
修改当前任务相关文件可以执行，但必须看 diff
跑 lint、typecheck、单元测试可以按项目规则放行
安装依赖、访问网络、改 lockfile必须人工确认
读取 .env、密钥、私钥、浏览器会话默认禁止
删除目录、重置 Git、发布、部署、改生产库不交给 Agent 自动执行

Claude Code 用户先检查 /permissions 和 settings 里的 allow / ask / deny。Codex 用户先检查 sandbox、approval policy 和当前 profile。不要只靠一句“不要做危险操作”的提示词；提示词不是硬边界。

哪些命令不能直接允许

命令权限要按影响半径分层。只读命令和本地验证命令可以减少确认；会下载、安装、删除、提交、发布、扫描或上传的命令必须停下来。

命令类型处理方式
rg、git diff、git status可以放进安全 allow
pnpm run lint、pnpm run typecheck、pnpm test项目确认后可以放行
pnpm add、npm install、pip install、cargo add先查包名、来源、scripts 和 lockfile
npx、uvx、curl | sh、远程脚本默认高风险，先看完整命令
rm -rf、git reset --hard、清库、迁移、部署不让 Agent 自动执行

可以把项目规则写成明确的权限说明：

Text
Agent command policy:
- Auto: read files in this repository, run rg, git diff, git status, pnpm run lint, pnpm run typecheck.
- Ask first: install dependencies, access network, modify lockfiles, run migrations, push commits.
- Never: read .env or private keys, run curl|sh, publish packages, deploy production, delete data.

这段规则不能替代沙箱，但能让 Agent 在提出命令前先按你的边界自查。真正执行时，仍然以客户端权限和操作系统权限为准。

网络请求先问三个问题

Agent 要访问网络时，先确认它要连哪里、为什么连、会发什么内容。很多风险不是来自模型回答，而是来自命令把本地信息带出去了。

问题你要看到什么
连哪里域名、IP、API endpoint、registry 或仓库地址
为什么连下载依赖、查文档、调用测试 API、访问内部服务
会发什么请求参数、headers、日志、错误输出、文件内容

下面几类网络动作不要直接点允许：

  • 访问陌生 IP、短链接、paste 站、临时文件托管。
  • 扫描公司内网、客户域名或第三方目标。
  • 把日志、环境变量、错误栈、配置文件上传到外部服务。
  • 通过 curl 下载脚本后立刻执行。
  • 把 GitHub token、npm token、云厂商 key 放进 headers 或 query string。

如果 Agent 需要查官方文档，让它先给出 URL 和要查的问题。你可以允许打开文档，但不要允许它顺手执行文档里的安装脚本。

凭据和敏感文件默认隔离

AI Agent 不要默认读到开发机上的所有凭据。.env、SSH key、npm token、GitHub token、云厂商密钥、浏览器 cookie、AI 工具登录文件，都先隔离。

重点检查这些位置：

Text
.env
.env.local
.env.production
~/.ssh/
~/.npmrc
~/.gitconfig
~/.config/
~/.aws/
~/.azure/
~/.codex/
~/.claude/

如果 Agent 需要一个环境变量来跑测试，优先给假值、测试账号或只读账号。不要把生产 token 粘进聊天记录，不要让 Agent 打印完整 secret，也不要让它把 secret 写进项目 settings。

团队项目可以把敏感路径写进规则文件，但真正的防线还要靠权限、忽略规则、secret manager、只读账号和最小 scope。

MCP 和外部工具不要一次全接

MCP Server、浏览器自动化、GitHub、数据库、邮件和 CI 工具会扩大 Agent 的行动范围。每多接一个工具，就多一个权限边界。

先按这个顺序检查：

  1. 工具来源是否可信，版本是否固定。
  2. 工具 description 和参数里有没有隐藏动作。
  3. 工具能读哪些目录、账号和外部系统。
  4. OAuth scope 是否最小。
  5. 写操作、发送操作、删除操作是否会再次确认。
  6. 工具调用日志能不能追到具体用户、参数和时间。

陌生 MCP Server 不要和文件系统、GitHub、邮件、数据库、浏览器这类敏感工具放进同一个会话。即使每个工具单独看都正常，组合后也可能让 Agent 把一个工具读到的信息交给另一个工具。

已经给过高权限先查什么

如果你已经让 Agent 以高权限跑过陌生命令、安装过依赖、接过 MCP Server，先按可能泄露处理，不要只把配置删掉就结束。

先查这些痕迹：

  • 最近执行过的 shell 命令和终端历史。
  • Git diff、lockfile、package scripts、CI 配置。
  • 新增依赖、postinstall、setup.py、build.rs、GitHub tarball。
  • MCP 配置、OAuth 授权、工具调用日志。
  • 外部网络请求、临时文件、下载脚本。
  • 日志里是否出现 token、cookie、客户数据、内部路径。

如果 Agent 可能读过 secret，先轮换凭据：

Text
Rotate tokens:
- GitHub personal access token
- npm token
- cloud provider access key
- database password
- AI provider API key
- OAuth grants used by MCP servers

轮换后再清理配置和会话记录。只删除 MCP Server、撤销本地 settings 或关闭终端，不等于外部 token 已经失效。

现在怎么设使用边界

更稳的做法是把 Agent 当成能执行动作的初级工程师，而不是只会补全代码的编辑器插件。

日常开发可以采用这套边界：

能自动做需要确认不交给 Agent
读当前仓库、查文档、看 diff安装依赖、联网、改 lockfile读 secret、发布、部署、删数据
跑 lint、typecheck、测试改 CI、改权限、接 MCP改生产库、轮换真实凭据
修改明确任务文件推送、开 PR、调用外部 API扫描第三方目标、上传日志

成功标准也要写清楚：Agent 完成任务后，必须能给出改了哪些文件、跑了哪些命令、哪些命令被拒绝、哪些地方需要人工复核。看不到这些记录，就不要把它的结果直接合并或部署。

AI Agent 参与攻击链这件事，不意味着开发者不能用 Claude / Codex。更现实的结论是：Agent 的能力越接近真实工程师，权限管理越不能停留在“我相信它”。先限制命令、网络、凭据和外部工具，再让它进入项目，才是可持续的用法。

参考来源

Threat Actors Misusing AI Agents For Offensive Cyber OperationsOALABS ResearchAI agents open new front in offensive cyber operationsHelp Net SecurityA newbie hacker used vague, low-skill prompts in Claude and Codex to breach 14 companiesTechRadarConfigure permissionsAnthropic 官方文档Claude Code securityAnthropic 官方文档Agent approvals and securityOpenAI Codex Docs

相关文章

AI Agent 权限怎么设：哪些命令能自动跑，哪些必须人工确认智能编程 / 约 13 分钟AI Agent 让你安装依赖时，哪些包不能直接允许智能编程 / 约 12 分钟MCP Server 安装前怎么检查 tool poisoning 风险智能编程 / 约 12 分钟装过 codexui-android 后，Codex 登录凭据可能泄露怎么办错误日志 / 约 8 分钟Claude Code 每次都要确认 Bash 命令怎么办开发环境 / 约 12 分钟Codex CLI 一直要确认怎么办：approval_policy 和 sandbox_mode 排查错误日志 / 约 11 分钟当 AI Agent 开始替人动手，企业最先缺的不是更强模型智能编程 / 约 9 分钟7 个关键洞察：AI Coding 工具真正改变的不是写代码，而是验证代码智能编程 / 约 18 分钟

作者信息

luowj

关注 AI Coding 工具链、开发环境排障、工程发布和安全边界。文章优先基于官方文档、 真实报错、公开事件和可复现的检查步骤整理。

luowj1998@gmail.com提交文章反馈