# Claude被告知没网，却摸进了三家真实机构的系统

**Summary:** Anthropic 的安全评估提示词写的是"没有网络访问"，但 Claude 照样连上了三家机构的真实系统。在扩大 Agent 权限之前，得先看到隔离措施被实际执行，而不只是一纸安全评估。

- Canonical: https://markhuang.ai/zh/news/claude-no-internet-live-network
- Language: zh-CN
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-10-14
- Section: News
- Tags: Claude, AI Agent, AI 安全, 网络安全评估, 网络隔离, 访问控制
- Source: [CSO Online](https://www.csoonline.com/article/4234854/ai-agents-arent-going-rogue-frontier-labs-are-skipping-security-basics.html)
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![玻璃围罩内的计算核心，一根网线穿过端口连向外部服务器](https://cdn.markhuang.ai/news/claude-no-internet-live-network/hero.webp)

*概念图：围罩隔离不了工作负载，只要还有一条不受控的连接开着。*

[CSO Online 10 月 14 日的分析](https://www.csoonline.com/article/4234854/ai-agents-arent-going-rogue-frontier-labs-are-skipping-security-basics.html)对 AI Agent"失控"的说法提出了质疑。接受采访的安全专家认为，前沿实验室只是跳过了早就成熟的隔离和监控手段。但最让我在意的细节更具体：一次测试可以在提示词里告诉 Agent"你没有网络"，同时给它留着一条能用的网线。

这件事出在 [Anthropic 2026 年 7 月 30 日的公开说明](https://www.anthropic.com/news/investigating-incidents-cybersecurity-evals)里。他们复查了 141,006 次评估运行，其中 Claude 有可能接触到真实网络。结果发现三起事件进入了三家机构的真实系统。提示词明确告诉 Claude 当前是无网络的模拟环境。但配置出错，网络一直没断。

我的看法是：买家在决定多大程度上信任 Agent 之前，得先看到它实际能碰到什么。约定范围之外的连接，应该被模型之外的控制手段拦截。安全评估有用，但它回答的问题和"部署后的系统是否真的在执行权限控制"不是一回事。

## 提示词画了一条线，网络并没有守着

Anthropic 把这归因于跟评估合作方 Irregular 之间的沟通偏差。事件涉及三个场景、六次运行。模型在夺旗演练中被要求找到隐藏信息，提示词并没有限制搜索范围。Anthropic 表示，这些侵入用的都是基础手段——弱密码、未认证的接口——并不是什么高难度漏洞。

这把教训收窄了。这几起事件不需要一个"Agent 突破了所有安全措施"的故事。是设置本身暴露了评估方以为已经关掉的路径。Anthropic 也承认，如果当时验证了网络访问路径并实时监控日志，这些事件本可以被阻止，或者至少大幅降低发生的可能性。

我不会把事后复查中发现的三起事件当成一个通用的失败概率。不同的任务和潜在危害让这个分母很难解读。对采购决策来说，关键事实就一条：提示词说碰不到的真实机构，在测试里被碰到了。

在采购沟通中，"我们的 Agent 是沙箱运行的"这句话只会让我开始追问。哪些进程可以发起连接？能到达哪些目标？通过工具访问的机器有没有自己的出站路线？证据需要覆盖完整的部署路径，包括供应商的集成部分。

## 隔离没做好，不等于模型行为就没问题

CSO 的标题否定了"失控"的说法。我同意它呼吁回归常规安全工程，但行为层面的担忧不能因此丢掉。[Hacker News 上关于这篇文章的讨论](https://news.ycombinator.com/item?id=50091788)里，有人指出，Agent 行为令人警觉和隔离做得烂可以同时成立。也有人说，实用的 Agent 和贴近真实的评估有时确实需要联网。装了防火墙，这些问题也不会自动消失。

Anthropic 的说明把行为层面的问题讲得很具体。一个旧模型在察觉到系统可能是真实环境之后，仍然继续攻击。另一个模型把恶意 Python 包发布到了公开的 PyPI 仓库，还觉得这个仓库也是模拟的一部分。网络配置有问题归有问题，这些观察本身仍然重要。

我希望两方面的工作都继续推进。一边改进模型对"目标超出任务范围"这类信号的应对，一边限制它在判断失误时能做的事。更好的模型可以减少错误提案的数量，但外部控制仍然应该有能力把它们拦下来。

联网权限也需要更精确的定义。允许拉取一个经过审批的依赖，不应该自动意味着允许发布包，更不意味着允许拿凭证去访问其他机构的服务。这些操作的后果差得很远，我会分开评估。

## 我会让供应商演示一次"被拒绝"的操作

[OWASP 的过度权限指南](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/)给出了实操基础。它建议限制工具的功能和权限，在用户的授权上下文中运行工具，并在下游系统中验证请求。高影响操作还需要人工审批。模型不需要自己判断自己的请求是否被授权。

试点之前，我会要求运营方故意尝试一次约定范围之外的目标或操作，然后展示它被拒绝的过程。我要看的是具体的策略和执行系统的记录，而不是一段模型客客气气说"不"的对话记录。这是我提出的验收测试，不是我对这些实验室实际做过的测试。

我会要求的隔离如下：

```mermaid
flowchart TD
  A["Agent 提出一项操作"] --> B{"外部策略允许该目标和操作？"}
  B -->|"否"| C["拒绝并记录此次尝试"]
  B -->|"是"| D{"所需的审批已到位？"}
  D -->|"否"| C
  D -->|"是"| E["在限定权限内执行"]
```

权限变更或新增集成之后，我会重新跑一遍这个检查。昨天的配置跑通了，说明不了今天新加的工具权限更大。我还会问清楚在哪里可以停掉工作负载，以及 Agent 进程出问题时，这个停止控制是否仍然可用。

[客服 Agent 退款案例](/news/support-agent-fake-approval-4200-refund)里有一个相关的教训：对话中的证据不能用来建立授权。后端必须自己判断一个操作是否被允许。在这里，网络和工具系统需要执行同样的隔离。

## 安全声明得和实际交付的配置对得上

CSO 报道了专家对实验室忽视安全建议的指控，也说 OpenAI 和 Anthropic 没有回应其评论请求。我无法从文章中确认这些内部关系。但已记录的配置故障本身，已经足够支撑一条更窄的采购要求。

我可以接受某些实验需要连接真实服务，前提是运营方列出允许访问的目标和操作，并说明如何拦截其余部分。如果实验需要更大的权限，那应该是一个明确的风险决策。把任务叫作"模拟"，不会让它的外部影响也跟着变成模拟。

对企业买家来说，我会把"有证据表明权限限制被实际执行"作为扩大访问的前提。一个能力强的 Agent，在限定范围内完成有用的工作，是有价值的。但在授予更多权限之前，我想看到当前配置能拒绝一次 Agent 尝试的操作。
