最近大家都在讨论一个趋势OpenAI 之后Anthropic 的 Claude 系工具也开始把操作范围延伸到公共互联网。简单说AI 不再只是做文本生成它能在任务里发起 HTTP 请求、读取网页、调用 API甚至操作命令行。这对自动化效率提升很明显但安全团队的压力也跟着上来了。这篇文章不教怎么构造攻击而是从防守方视角拆清楚“AI Agent 公共互联网”到底会扩大哪些风险以及普通团队该怎么用日志、流量、权限和最小监控环境把这些风险识别出来。我会把话题分成几个可操作的层面先理解攻击面为什么变大再看哪些异常信号值得关注然后讲一套能落地的排查链路最后给出 AI Agent 使用时的权限边界建议。适合正在用 Claude Code、OpenAI Codex、各类 Agent 框架的开发者也适合做安全运维和日志分析的读者。1. 先理解“攻击延伸至公共互联网”到底意味着什么1.1 AI Agent 的能力范围和以前不一样了以前的大模型应用多半是“输入一段文本输出一段文本”。就算有 API也是人发起请求模型返回结果。整个链路里模型没有主动访问外部世界的能力也就不存在“模型发起公网请求”这个攻击面。现在不一样。Claude Code、OpenAI Codex 这类工具本身被设计成能执行命令、读写文件、发 HTTP 请求。它们可以在一次任务里完成“搜索资料、下载文件、调用接口、分析结果、输出报告”这样的完整流程。这意味着什么呢意味着模型不再只是一个“内容生成器”而是一个能够触达公网资源的执行器。一旦执行器有了公网访问能力三类风险就跟着出现Agent 访问了不该访问的地址导致内网信息、配置、密钥泄露。Agent 读到的外部内容被恶意构造反过来诱导 Agent 执行危险命令。Agent 的高频请求被外部服务误判为攻击或者自身被用来发起批量请求变成流量型问题的一部分。这些风险不是模型“变坏了”而是权限边界没有设计好。理解这一点后面所有排查和防护就有方向了。1.2 公共互联网访问带来的典型变化本地跑脚本时网络拓扑是可控的。你明确知道程序会调用哪些接口也可以提前把域名和 IP 放进白名单。但 Agent 工具不一样它们经常会根据任务动态决定访问哪个 URL。比如让 Claude Code 去查一个项目的依赖漏洞它可能访问 GitHub、NPM、PyPI、Maven 仓库还可能跳转到第三方文档站。这种动态性让“先审批再放行”的传统网络策略变得困难。另一个变化是请求行为更接近真人又比真人快得多。同样一个页面人工看可能一分钟内访问两次Agent 可能在十秒内并发访问几十次。如果目标站点有频率限制或反爬逻辑就会出现大量 403、429如果目标站点防御较弱这种短时间高频请求就可能被看成 CC 攻击或缓慢 HTTP 拒绝服务攻击。所以Claude 将攻击延伸至公共互联网更准确的理解是模型工具的执行范围扩大到了公网安全团队需要重新梳理出网权限、日志记录和紧急熔断机制。这个观点很重要不要只停留在模型能力列表上。1.3 为什么 OpenAI、Anthropic 都有这个方向OpenAI 和 Anthropic 并不是在做同一件事但方向高度一致都在让 Agent 具备更长链路、更多工具、更实时的外部交互能力。OpenAI Codex 偏编码任务自动化Claude Code 偏对话式命令执行。它们的共同点是都会调用 shell、读写文件、访问网络。这说明一个行业趋势下一阶段的大模型应用重点不再是“生成一段内容”而是“完成一个任务”。而完成任务往往绕不开公网请求。作为使用者我的建议是不要等到出现事故再回头审计。在引入这些工具的第一天就要把出网路径和日志开关打开。2. 公共互联网场景下最常见的几类风险信号2.1 流量型异常连接超时、响应缓慢、CPU 飘高从搜到的热词里可以看到DDoS 攻击、CC 攻击、缓慢 HTTP 拒绝服务、UDP 洪水这些词被频繁提及。这些都属于流量型和资源耗尽型风险。它们不一定真的由 AI Agent 触发但运维人员看到这些词第一反应应该是检查流量特征而不是先去封禁所有 IP。真实场景里收到报警时往往不是“攻击开始了”而是“服务变慢了”。比如 Nginx 返回 499 或 504后端响应时间从 200ms 涨到 5 秒CPU 从 10% 涨到 90%。这时候不要急着重启机器先看连接状态。常见判断点并发连接数是否异常高比如单 IP 同时建立上百条连接。请求头是否完整有没有大量缺少 UA 或 UA 假的请求。请求路径是否集中在同一个 URL比如登录接口、查询接口。响应时间是否持续走高而不是偶发波动。如果是 Agent 工具造成的通常会有比较明显的调用特征请求之间间隔规律、User-Agent 统一或来自少数几个出口 IP。如果是外部流量攻击请求源会分布更散但频率依然集中。留好访问日志两个方向都能看到证据。2.2 应用层漏洞信号反序列化、XSS、CSRF、服务路径劫持热词里还有反序列化攻击、XSS、CSRF、服务路径劫持。这些词放在一起本质是服务端对输入边界的管理问题。AI Agent 访问公网之后如果它把抓取的网页内容直接塞给后端解析就可能触发这些问题。比如一个 Agent 下载了 HTML 文件并自动提取其中的表单字段如果后端没有对字段做校验就可能把恶意脚本带入页面形成存储型 XSS。又比如 Agent 调用了本机管理接口但是管理接口没有校验来源就可能被误用成 CSRF 入口。反序列化则常见于 Agent 处理缓存对象或导入导出数据。如果直接把远程数据反序列化到内存攻击者构造的恶意对象可能改变程序执行流。这类风险不一定要通过传统浏览器触发AI Agent 的高频自动化操作会让探测次数更多、路径更多。防守上核心不是追着漏洞名跑而是守住两条线外层统一校验所有进入后端的请求长度、类型、字段范围先过一遍。内层最小解析不需要执行脚本的字段不要拼进上下文不信任外部数据。服务路径劫持也是类似逻辑。Agent 在查找可执行文件或加载库时如果当前目录权限过大或者 PATH 里包含了可写目录就可能加载到恶意文件。这个问题在 Windows 下尤其常见表现为“无法将 claude 识别为 cmdlet”或者路径中存在同名文件。安装工具时尽量用系统级目录不要放在临时目录执行。2.3 账号与配置泄露信号热词里能看到“openai api key分享”“openai api密钥获取”这类信息。这属于典型的账号风险。如果团队的 API Key 出现在公共仓库、聊天记录或日志里任何人都可能冒用身份调用接口。轻则额度被刷重则攻击者借用 Agent 的权限做进一步操作。排查账号问题时建议关注这几点日志中是否出现后端返回 401/403 但仍继续请求的调用。是否有来自陌生 IP 的 API 调用尤其是从未见过的地区。是否出现低频但持续的小额请求这是很多人容易忽略的。一旦确认 Key 泄露最快的方式是立刻吊销并轮换不要只改代码。吊销后要重新检查所有引用该 Key 的脚本和自动化任务避免出现“服务突然全部超时”的次生故障。3. 从零搭建一个最小监控环境3.1 环境准备一台测试机、一份访问日志、一个默认拒绝策略我不建议直接在线上环境做实验。先准备一台最小测试机系统用 Ubuntu 22.04 或 Debian 12 都可以也可以用 Windows Server。关键是先把日志、防火墙、反向代理三层搭起来。基础思路是这样的所有流量都经过统一入口例如 Nginx。入口记录完整访问日志包括时间、IP、UA、请求路径、状态码、响应时间。入口之下再挂实际业务服务比如 Spring Boot、Node.js 或 Python 应用。主机防火墙默认拒绝非必要入站流量只开放 80/443 和 SSH 管理端口。这个结构的好处是即使业务崩溃日志还在即使有人尝试扫端口默认拒绝能挡住大部分探测。用一个简单的 Nginx 访问日志配置做示例log_format main $remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $http_user_agent $http_x_forwarded_for $request_time; access_log /var/log/nginx/access.log main;$request_time一定要加这是判断服务是否变慢的关键字段。没有它你只能看到状态码看不到耗时。3.2 用防火墙和限流规则控制入站限流不是攻击手段是保护入口的常规操作。Nginx 的limit_req模块很适合控制代理层的请求频率。示例配置如下limit_req_zone $binary_remote_addr zoneapi_limit:10m rate10r/s; server { location /api/ { limit_req zoneapi_limit burst20 nodelay; proxy_pass http://127.0.0.1:8080; } }这段配置的作用是同一个 IP 访问 /api/ 路径时平均每秒最多 10 次请求短期突发允许 20 次。如果超过Nginx 直接返回 503。这样即使外部真的出现高频请求也不会瞬间打穿后端。注意限流参数不能拍脑袋。如果业务正常请求量就超过 100 QPSrate10r/s会把真实用户也挡住。建议先看一周历史日志统计正常峰值然后把限流阈值设成正常峰值的 2 到 3 倍。对于更底层的端口保护用 iptables 做默认丢弃即可iptables -A INPUT -p tcp --dport 80 -j ACCEPT iptables -A INPUT -p tcp --dport 443 -j ACCEPT iptables -A INPUT -p tcp --dport 22 -s 你的管理IP -j ACCEPT iptables -P INPUT DROP这条规则的意思很直白只允许外网访问 80、443SSH 只允许指定的管理 IP 进来其余入站包全部丢弃。这样既保证平台可用又减少被扫描面。3.3 出网控制Agent 能访问哪里应该提前划定入站控制只是其中一半。另一半是出网控制。AI Agent 如果需要访问公网建议单独走一个受限出口而不是直接用业务机器全网访问。最简单的做法是在测试机上用 iptables 限制出网目标iptables -A OUTPUT -d 0.0.0.0/0 -j DROP iptables -A OUTPUT -d 可信域名对应IP段 -j ACCEPT iptables -A OUTPUT -m owner --uid-owner agentuser -j ACCEPT这个例子比较粗糙实际使用时需要把 Agent 运行用户单独拆分出来再给它白名单。可信域名对应 IP 需要定期维护因为不少 CDN 域名会解析到动态 IP。更稳妥的方案是让 Agent 通过统一的 HTTP 网关访问外部站点在网络层只允许该网关出口。这样所有请求都经过同一路径审计和熔断都方便。4. 单条异常请求排查链路4.1 先看现象不要急着封 IP我见过很多团队一看到日志里有异常请求第一反应就是封 IP。这个动作做起来很快但经常误伤。比如 Claude Code 发起正常任务时访问了某文档站点而安全组设置的阈值太低直接把请求判成攻击。等你封完 IP业务也断了反而成了新的故障。正确顺序应该是先看现象再判断是偶发、持续、还是扩散。第一步要看的东西时间范围异常发生在哪个区间是否和发布、重启或 Agent 任务执行时间重合。请求分布集中在某个 IP、某些 URL、还是全站所有路径。响应情况是 499/503/504还是 200 但响应极慢。资源占用CPU、内存、连接数、磁盘 IO 有没有同时飙升。有时候现象看起来是外部攻击实际是后端依赖的一个 Redis 连接池耗尽或者某个第三方接口超时。不要只盯着网络流量。4.2 从访问日志还原请求链访问日志是最直接的证据。我常用的查询思路是先找时间窗口里响应时间最长的请求再看这些请求集中在哪条路径最后看它们的 UA 和来源 IP。假设查询/var/log/nginx/access.logawk $NF 3 {print} access.log | head -50这条命令的意思是把耗时超过 3 秒的请求行打印出来。$NF是最后一列对应我们刚才配置的$request_time。这样能快速定位“慢请求”长什么样。然后再看这些慢请求是否集中在同一个 IPawk $NF 3 {print $1} access.log | sort | uniq -c | sort -rn | head -20这样能看到出现次数最多的源 IP。如果某个 IP 的慢请求数量远超其他 IP那就要加大对这个 IP 的关注度。但注意这只代表异常不代表一定是攻击。它可能是爬虫也可能是内部 Agent 在执行长任务。4.3 分层次判断连接层、应用层、数据层排查时我习惯分三层连接层TCP 握手是否正常有没有大量TIME_WAIT、SYN_RECV。应用层服务日志有没有报错异常堆栈集中在哪个类、哪个接口。数据层MySQL、Redis、ES 有没有慢查询连接数是否打满。如果连接层异常优先看防火墙和 Nginx access log看有没有未知 IP 在持续尝试建连如果应用层异常优先看应用日志和错误码如果数据层异常优先看数据库慢查询日志和连接池状态。这里有一个容易被忽略的坑很多人看到 CPU 飙升就以为是拒绝服务攻击结果查完发现是数据库索引失效全表扫描把 CPU 打满。所以不要跳过应用和数据层直接下结论。4.4 判断“Agent 正常行为”和“恶意请求”的差异要区分 Agent 正常任务和恶意请求可以从四个维度看。我整理了一个对比表维度Agent 正常行为恶意或高风险请求来源 IP通常来自固定出口或少数几个 IP可能分布很散也可能绕 CDNUser-Agent常见的有 Claude 相关、Codex 相关或自定义标识可能伪装成浏览器也可能缺失请求间隔有一定节奏间隔相对规律常常在极短时间内高频访问访问路径和任务目标相关不会全站乱扫可能大量尝试 .git、.env、备份文件等路径这个表不能当硬标准只能当辅助判断。因为攻击者也会模仿正常 UA 和频率。更可靠的方式是在 Agent 端增加一个固定请求头比如X-Agent-Name: internal-claude-task然后在网关层统一识别。这样即使出现异常请求也能快速区分“内部任务”和“外部流量”。5. AI Agent 的权限边界怎么定5.1 最小权限Agent 不该有生产环境的管理员权限很多人在本地装 Claude Code 时直接用 root 或 Administrator 账号跑。这带来的风险很明显一旦 Agent 被恶意网页内容诱导执行了rm、curl | bash这类命令后果是整个环境被破坏。虽然工具本身有提示和确认机制但你不能假设每一次都会拦下来。正确做法是单独建一个低权限用户专门运行 Agentsudo useradd -m -s /bin/bash agentuser sudo -u agentuser claude这样 Agent 能写自己的家目录能读取必要目录但对系统关键路径没有写权限。这样做确实会增加一点文件权限配置的工作量但能明显缩小风险半径。5.2 网络边界Agent 默认不访问内网管理网段如果需要让 Agent 访问公网不要直接把内网管理网段的访问权也给它。比如 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16 这些内网范围默认应禁止从 Agent 进程主动访问。这样做的原因有两个一是防止 Agent 误操作内网路由器和防火墙二是防止网页里的恶意脚本利用本机网络访问探测内网服务。你可以在运行 Agent 的机器上加一条 route 或 iptables 规则把出网流量限制在指定出口网关。如果你用 OpenTelemetry 这类可观测体系还可以把 Agent 的请求 traceId 注入到日志中。这样发生问题时能从一条请求追到 Agent 任务、底层命令和返回内容排查效率会高很多。5.3 密钥管理不让 API Key 出现在代码和日志里使用 Claude Code、OpenAI Codex 时API Key 是核心凭据。不要让它在代码中出现更不要提交到 Git 仓库。建议用环境变量或密钥管理服务加载。export ANTHROPIC_API_KEYyour-api-key这条命令示意的只是基本的密钥注入方式。生产环境里我更建议用 vault 这类服务统一管理密钥并给每次任务设置临时凭据用完即失效。日志系统里要做脱敏防止Authorization: Bearer头被完整记录。最简单的方式是在 Nginx log_format 里不记录 Authorization 头或者在应用层加过滤器。可以参考如下 Nginx 脱敏思路map $http_authorization $auth_hide { default REDACTED; } access_log /var/log/nginx/access.log main;这样即使有人拿到日志文件也无法从里面复制完整的 Key。5.4 Agent 接收外部内容时要当输入处理Agent 抓取网页、调用外部 API、读取远程文件时这些内容全部属于不可信输入。不要让 Agent 直接把外部内容拼进系统命令或 SQL。更稳妥的方式是对外部内容做大小限制避免拉取超大文件。对返回内容做字符集校验避免乱码和编码绕过。只在明确需要执行的场景里让 Agent 输出带引号的命令参数。比如 Claude Code 读取某个网页并生成 shell 命令时最好让它先输出待执行命令再由人确认。不要开启完全自动执行模式。这是现阶段最实用的边界控制。6. 常见误区和我的建议6.1 误区只要封住攻击 IP 就安全了很多团队把安全防护理解成“封 IP”。这种做法对固定 IP 攻击有效但对分布式的请求基本无效。现在的异常请求可以来自上千个 IP单靠手工加黑名单根本封不完。更靠谱的做法是把防护重心放到限流、认证、输入校验和白名单上。IP 黑名单可以作为辅助但不能作为主要防线。6.2 误区模型能力越强安全测试越要激进现在很多团队做 AI Agent 安全测试时会想着“让模型越权访问”“让模型生成攻击命令”。这种做法不是为了测试安全边界而是为了验证模型会不会配合攻击。对于技术研究来说可能有价值但公开博客不适合展开。我更建议把注意力放在“防御视角”模型在什么情况下会被诱导、系统在什么路径上会暴露以及如何通过权限和日志把损害控制在最小范围。6.3 建议先跑小范围任务再放开批量权限如果你即将在自己的环境里接入 Claude Code 或类似工具建议按这个顺序推进先用只读任务测试不打日志、不做写操作。确认日志、错误提示、出口 IP 都符合预期后再开启写文件和网络访问。加一层人工确认尤其涉及删除、修改配置、执行系统命令时。最后再放开批量任务和后台自动执行。每一步都要能回滚。比如给 Agent 的工作目录做好快照出现异常时可以直接恢复到上一个版本给数据库连接设置只读账号日常任务默认用只读权限只有明确需求才临时提升。6.4 建议把监控当作功能开发而不是“以后再说”日志和监控不应该在事故之后才补。我的建议是在 Agent 工具上线时就把监控指标设计好至少包括这几个出网请求数量单位时间的请求数趋势。Agent 任务成功率成功、失败、取消的分布。外部请求目标域名是否出现未知域名。异常命令执行次数Agent 在本地执行命令的频率。API Key 调用量按用户或按任务维度拆分。这些指标不用一开始就做得很复杂先用日志实时简单统计确认能覆盖核心场景即可。等运行一段时间后再根据实际报警量优化阈值。6.5 最后说一句OpenAI 之后是 AnthropicClaude 将攻击延伸至公共互联网这个消息带来的不是“某个模型很危险”的焦虑而是整个 AI Agent 进入真实执行阶段后的必然问题权限边界、网络出口、日志审计、输入校验。你不需要一上来就搭一套大而全的安全平台但至少要做到能回答这三个问题Agent 能访问什么、它做了什么、我能不能在五分钟内看到记录。把这三件事做好无论后续使用哪种工具都不会太慌。