AI Agent接入公共互联网的安全风险与日志排查实践

最近大家都在讨论一个趋势：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 zone=api_limit:10m rate=10r/s; server { location /api/ { limit_req zone=api_limit burst=20 nodelay; proxy_pass http://127.0.0.1:8080; } }

这段配置的作用是：同一个 IP 访问 /api/ 路径时，平均每秒最多 10 次请求，短期突发允许 20 次。如果超过，Nginx 直接返回 503。这样即使外部真的出现高频请求，也不会瞬间打穿后端。

注意：限流参数不能拍脑袋。如果业务正常请求量就超过 100 QPS，rate=10r/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、443，SSH 只允许指定的管理 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.log：

awk '$NF > 3 {print}' access.log | head -50

这条命令的意思是：把耗时超过 3 秒的请求行打印出来。$NF是最后一列，对应我们刚才配置的$request_time。这样能快速定位“慢请求”长什么样。

然后再看这些慢请求是否集中在同一个 IP：

awk '$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 正常任务和恶意请求，可以从四个维度看。我整理了一个对比表：

这个表不能当硬标准，只能当辅助判断。因为攻击者也会模仿正常 UA 和频率。更可靠的方式是，在 Agent 端增加一个固定请求头，比如X-Agent-Name: internal-claude-task，然后在网关层统一识别。这样即使出现异常请求，也能快速区分“内部任务”和“外部流量”。

5. AI Agent 的权限边界怎么定

5.1 最小权限：Agent 不该有生产环境的管理员权限

很多人在本地装 Claude Code 时，直接用 root 或 Administrator 账号跑。这带来的风险很明显：一旦 Agent 被恶意网页内容诱导，执行了rm、curl | bash这类命令，后果是整个环境被破坏。虽然工具本身有提示和确认机制，但你不能假设每一次都会拦下来。

正确做法是单独建一个低权限用户，专门运行 Agent：

sudo 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_KEY="your-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 或类似工具，建议按这个顺序推进：

1. 先用只读任务测试，不打日志、不做写操作。
2. 确认日志、错误提示、出口 IP 都符合预期后，再开启写文件和网络访问。
3. 加一层人工确认，尤其涉及删除、修改配置、执行系统命令时。
4. 最后再放开批量任务和后台自动执行。

每一步都要能回滚。比如给 Agent 的工作目录做好快照，出现异常时可以直接恢复到上一个版本；给数据库连接设置只读账号，日常任务默认用只读权限，只有明确需求才临时提升。

6.4 建议：把监控当作功能开发，而不是“以后再说”

日志和监控不应该在事故之后才补。我的建议是，在 Agent 工具上线时就把监控指标设计好，至少包括这几个：

• 出网请求数量：单位时间的请求数趋势。
• Agent 任务成功率：成功、失败、取消的分布。
• 外部请求目标域名：是否出现未知域名。
• 异常命令执行次数：Agent 在本地执行命令的频率。
• API Key 调用量：按用户或按任务维度拆分。

这些指标不用一开始就做得很复杂，先用日志实时简单统计，确认能覆盖核心场景即可。等运行一段时间后，再根据实际报警量优化阈值。

6.5 最后说一句

OpenAI 之后是 Anthropic，Claude 将攻击延伸至公共互联网，这个消息带来的不是“某个模型很危险”的焦虑，而是整个 AI Agent 进入真实执行阶段后的必然问题：权限边界、网络出口、日志审计、输入校验。你不需要一上来就搭一套大而全的安全平台，但至少要做到能回答这三个问题：Agent 能访问什么、它做了什么、我能不能在五分钟内看到记录。

把这三件事做好，无论后续使用哪种工具，都不会太慌。