<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>AI 与技术 on 红旗下的蛋</title><link>https://blog.fallleaf.net/tags/ai-%E4%B8%8E%E6%8A%80%E6%9C%AF/</link><description>Recent content in AI 与技术 on 红旗下的蛋</description><generator>Hugo -- gohugo.io</generator><language>zh-cn</language><copyright>fallleaf</copyright><lastBuildDate>Sun, 13 Sep 2026 07:40:00 +0000</lastBuildDate><atom:link href="https://blog.fallleaf.net/tags/ai-%E4%B8%8E%E6%8A%80%E6%9C%AF/index.xml" rel="self" type="application/rss+xml"/><item><title>从 Anthropic 报告谈起，一个不容忽视的安全问题</title><link>https://blog.fallleaf.net/p/anthropic/</link><pubDate>Sun, 13 Sep 2026 07:40:00 +0000</pubDate><guid>https://blog.fallleaf.net/p/anthropic/</guid><description>&lt;img src="https://blog.fallleaf.net/p/anthropic/cover.webp" alt="Featured image of post 从 Anthropic 报告谈起，一个不容忽视的安全问题" /&gt;&lt;h2 id="云端-ai-服务的可见性"&gt;云端 AI 服务的可见性
&lt;/h2&gt;&lt;p&gt;近日，Anthropic 发布了关于模型输入风险、凭据滥用、供应链攻击、越权访问以及 AI 应用安全的研究和威胁情报报告，再次引发了业界对大模型安全问题的关注。&lt;/p&gt;
&lt;p&gt;报告本身当然值得关注。但从另一个视角看，更值得关注的其实是报告背后的一个问题：为什么 AI 服务商能够发现、分析和还原这些攻击行为？&lt;/p&gt;
&lt;p&gt;一个重要原因是，在现有主流云端 AI 服务架构中，用户与 AI 的交互发生在服务商控制的计算和服务环境中。用户请求最终需要进入服务端的计算链路，由模型完成 Tokenization、推理以及必要的工具调用；与此同时，服务侧还可能产生与请求相关的安全检测、会话信息、调用记录和其他遥测数据。具体哪些数据会被记录、保留多久、是否用于模型改进，取决于各服务商的产品策略、企业协议和合规要求；但从架构上看，服务侧至少需要获得足够的明文或明文派生数据，才能完成推理和基础的安全检测。&lt;/p&gt;
&lt;p&gt;这些信息使服务商具备了对 AI 交互过程进行观测、关联和分析的能力，从而能够在一定条件下识别异常行为、分析攻击链条，甚至还原部分攻击过程。&lt;/p&gt;
&lt;p&gt;当然，这并不意味着服务商可以任意查看所有用户数据，也不意味着所有请求都会被完整保存。具体能够看到什么、记录什么、保存多久，取决于具体服务的架构、产品策略和安全机制。&lt;/p&gt;
&lt;p&gt;但从架构层面看，一个基本事实是明确的：只要 AI 推理发生在服务商控制的计算环境中，用户数据就必须进入一种能够被该计算环境处理和理解的状态。对于文本、代码、文档等数据而言，这通常意味着数据本身以人类可理解的形式进入服务端，或者经过 Tokenization 等处理后，仍然保留能够被模型解析和推理的信息，而不是像端到端加密那样始终保持为服务端无法理解的密文。&lt;/p&gt;
&lt;p&gt;这与传统意义上的端到端加密通信存在一个根本区别。&lt;/p&gt;
&lt;p&gt;在端到端加密场景中，服务提供者可以负责传输和转发数据，但通常无法获得应用层的明文内容；而在云端 AI 推理场景中，模型本身必须对用户输入进行计算，因此服务端计算环境必须能够获得并处理相应的数据。&lt;/p&gt;
&lt;p&gt;这就带来了一个过去并不那么突出的安全问题：当数据进入计算环境之后，如何保护它？&lt;/p&gt;
&lt;p&gt;这个问题对于企业用户尤其重要。&lt;/p&gt;
&lt;p&gt;当企业把源代码、内部文档、客户资料、业务数据甚至核心知识交给 AI 进行分析时，安全边界已经不再只是“数据在网络上传输时是否被窃取”，而进一步涉及：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;数据进入 AI 服务后的处理过程；&lt;/li&gt;
&lt;li&gt;模型推理过程中的数据保护；&lt;/li&gt;
&lt;li&gt;上下文、缓存和中间数据的安全；&lt;/li&gt;
&lt;li&gt;AI Gateway、日志和监控等服务环节；&lt;/li&gt;
&lt;li&gt;第三方代理、插件以及工具调用形成的新数据链路。&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;因此，AI 时代的数据安全边界正在发生一个重要变化：传统网络安全关注数据如何安全地传输和存储，而 AI 进一步提出了一个问题，数据如何在计算过程中保持安全。&lt;/p&gt;
&lt;p&gt;这也是为什么 Confidential AI、可信执行环境、Confidential GPU、私有化 AI 以及安全 AI Gateway 等技术开始受到关注。&lt;/p&gt;
&lt;p&gt;对于运营商而言，这意味着需要重新审视 AI 基础设施的安全边界，以及自己在这一新的安全边界中能够承担什么样的角色。&lt;/p&gt;
&lt;h2 id="ai时代的数据安全边界正在发生结构性变化"&gt;AI时代的数据安全边界正在发生结构性变化
&lt;/h2&gt;&lt;p&gt;在传统互联网体系中，数据安全的核心边界相对明确：&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;确保数据在网络传输过程中不被第三方获取。&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;因此形成了 HTTPS、TLS、VPN、IPSec 等成熟的网络安全体系。用户发送数据之前进行加密，数据通过网络传输，服务器收到以后再解密处理。对于中间网络而言，看到的主要是一段不可理解的密文。这种安全模型在过去几十年中非常有效。&lt;/p&gt;
&lt;p&gt;但生成式 AI 改变了数据的使用方式。&lt;/p&gt;
&lt;p&gt;企业今天交给 AI 的，往往已经不是普通的互联网信息，而是越来越有价值的生产数据：&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;源代码、内部文档、客户信息、网络配置、业务流程、生产数据以及企业知识库。&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;这些数据进入 AI 服务以后，不再只是“经过网络”。它们还要被：&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;理解、转换、计算、缓存和生成。&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;一次典型的 AI 请求，大致会经历：&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;用户 → API 网关 → 应用服务 → Token 化 → 模型推理 → GPU 计算 → 返回结果&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;用户请求通过 HTTPS 加密（TLS）传输到云端后，需要在服务端完成解密、解析和后续计算。文本经过 Tokenization 等处理后，进一步转换为模型可以计算的数值表示，进入推理引擎和 GPU 完成计算。&lt;/p&gt;
&lt;p&gt;当企业应用的信息通过加密进入AI服务的入口后，转换成可被大模型计算的数据，之后的每一个环节都可能形成新的数据安全隐患。因此，AI 时代安全与传统网络的主要变化就在于：过去主要关注 &lt;strong&gt;数据在网络中是否安全&lt;/strong&gt; ，而现在还必须关注： &lt;strong&gt;数据在计算过程中是否安全。&lt;/strong&gt;&lt;/p&gt;
&lt;h2 id="为什么数据到了-ai-服务端必须被看见"&gt;为什么数据到了 AI 服务端必须被“看见”？
&lt;/h2&gt;&lt;h3 id="llm-的数据处理流程决定了这一点"&gt;LLM 的数据处理流程决定了这一点
&lt;/h3&gt;&lt;p&gt;大模型推理并不是简单地把一段文本送进一个“黑盒”。&lt;/p&gt;
&lt;p&gt;一次典型的文本LLM 交互大致经历以下环节：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;用户客户端通过 HTTPS（TLS）将文本请求发送到云端 API 网关；&lt;/li&gt;
&lt;li&gt;TLS 在网关或负载均衡处终止，被解密为明文数据（包含 Prompt、上下文、参数等）；&lt;/li&gt;
&lt;li&gt;服务将文本送入分词器（Tokenizer）转换为 Token ID 序列，再映射为高维向量（Embedding）；&lt;/li&gt;
&lt;li&gt;这些向量以浮点数矩阵形式进入 GPU 显存，参与大模型计算。&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;在这个过程中： &lt;strong&gt;TLS 只保护“网络传输阶段”&lt;/strong&gt; ，一旦到达云端网关就被解密，后续在应用层、推理引擎和显存中均以明文或明文派生形式（Token ID，向量等）存在；拥有服务器权限的运维人员、被攻破的服务进程、以及拿到日志/追踪数据的攻击者，都有能力读取这些内容。&lt;/p&gt;
&lt;p&gt;这就是传统传输加密与 AI 计算之间的边界。&lt;/p&gt;
&lt;h3 id="澄清误区token-化与向量不是加密"&gt;澄清误区：Token 化与向量不是加密
&lt;/h3&gt;&lt;p&gt;部分人存在一个误解：认为文本进入大模型前被分词并转成 Token ID（如把 &amp;ldquo;Hello&amp;rdquo; 转成 &lt;/p&gt;
\[9906\]&lt;p&gt;），或者转成高维向量（Embedding），就相当于完成了“加密”，这种认识是错误的。&lt;/p&gt;
&lt;p&gt;Token化（分词）是公开编码，而非加密，原因是分词只是基于公开词表（如 BPE 算法）进行的确切语义映射与离散化编码，类似将英文字母转为 ASCII 码。任何人拿着公开词表调用 decode() 函数，都能无损还原原始文本。&lt;/p&gt;
&lt;p&gt;而向量则是保留明文语义，Embedding 是为模型计算设计的语义表示，保留了高精度的空间与语义关联。研究显示，在特定攻击模型和假设条件下，攻击者有可能从这些向量中部分反推原始文本或推断敏感属性，因此不能把向量化理解为“安全转换”。&lt;/p&gt;
&lt;p&gt;所以Token化和向量依然属于“明文数据（plaintext）”的派生表示。只要数据以这种形式在服务侧流转或在显存中计算，数据泄露风险就依然存在。&lt;/p&gt;
&lt;h3 id="为什么不能即时通信那样做端到端加密"&gt;为什么不能即时通信那样做“端到端加密”？
&lt;/h3&gt;&lt;p&gt;传统即时通讯的端到端加密（E2EE）要求服务器只做中转，不理解内容：客户端 A 加密，客户端 B 解密，中间服务器看到的只是一堆无意义的密文。&lt;/p&gt;
&lt;p&gt;但大模型推理的基本条件就是“ &lt;strong&gt;服务商的大模型必须深度理解文本&lt;/strong&gt; ”，总结下来，主要有两点制约了采用加密数据进行大模型计算。&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;• &lt;strong&gt;语义破坏&lt;/strong&gt; ：现代加密算法（如 AES-256）的目标之一，是让不知道密钥的观察者无法从密文中识别原始数据的结构和规律，理想情况下，密文在统计上应呈现接近随机的特征。对于没有密钥的大模型而言，加密后的文本表现为近似随机的序列，其中原有的词汇、句法、语义和上下文关系都不可直接获得。将这样的密文直接用于普通大模型训练，模型无法从中学习原始数据所包含的语言和知识规律，因此无法训练出具有相应语义能力的模型。&lt;/li&gt;
&lt;li&gt;• &lt;strong&gt;计算局限&lt;/strong&gt; ：普通大模型的推理需要将输入转换为 Token，并进一步形成模型可以进行数值计算的表示，再通过 Transformer 的矩阵运算完成推理。AES 等传统加密产生的密文不能直接作为具有原始语义的输入参与这一过程；在没有专门隐私计算机制的情况下，数据需要先在受信任的计算环境中解密，再转换为模型可以处理的表示。&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;&lt;strong&gt;大模型要能工作，就必须“看懂”原始内容，这本身就决定了它在服务侧不可能处于传统意义上的加密保护状态&lt;/strong&gt; 。问题也由此发生了变化，过去需要解决的是“ &lt;strong&gt;传输过程中的数据保密&lt;/strong&gt; ” ， 现在需要进一步解决&amp;quot; &lt;strong&gt;计算过程中的数据保密&lt;/strong&gt; ”。这就是所谓的 &lt;strong&gt;计算安全&lt;/strong&gt; 。&lt;/p&gt;
&lt;h2 id="从传输安全走向计算安全两条技术路线"&gt;从传输安全走向计算安全：两条技术路线
&lt;/h2&gt;&lt;p&gt;如果希望 AI 在处理数据的同时，又尽可能减少计算环境对数据的暴露，目前大致存在两条技术路线。&lt;/p&gt;
&lt;h3 id="全同态加密密码学上的长期方向"&gt;全同态加密：密码学上的长期方向
&lt;/h3&gt;&lt;p&gt;全同态加密（FHE）的核心思想非常直接：允许直接在密文上进行加减乘除等运算，解密后的结果与在明文中计算完全一致。这是一个非常理想的方案。但问题在于计算效率。&lt;/p&gt;
&lt;p&gt;现代大模型涉及巨量矩阵运算，同时还包含注意力机制和各种非线性计算。在这些复杂计算场景下，FHE 仍然面临较大的性能和工程成本。在当下，用 FHE 运行大模型生成一个词可能需要数十分钟，暂不具备商业实用性。因此现阶段更适合把它看成： &lt;strong&gt;值得长期关注的密码学技术方向，而不是当前大规模通用 LLM 推理的主流工程方案&lt;/strong&gt; 。&lt;/p&gt;
&lt;h3 id="硬件机密计算tee--confidential-ai工程上的最佳现实解法"&gt;硬件机密计算（TEE / Confidential AI）：工程上的最佳现实解法
&lt;/h3&gt;&lt;p&gt;另一种思路完全不同。利用现代芯片（如 Intel TDX、AMD SEV-SNP、NVIDIA H100/B200、远程证明 + 密钥管理）在 GPU 和 CPU 内部搭建硬件级物理隔离的“黑盒飞地（Enclave）”。它并不试图让 AI 永远看不到数据。而是基于一个现实： &lt;strong&gt;AI 必须看到数据才能计算。&lt;/strong&gt; 那么需要解决的就是： &lt;strong&gt;能不能让只有可信计算环境看到这些数据？&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;这就是 Confidential Computing 和 Confidential AI 的核心思想。其原理就是：数据在用户端通过密钥加密；密文通过加密通道（如 attested TLS）进入芯片内部的硬件安全区；仅在飞地内部解密并计算，计算结果加密后再输出。这种方式的优势在于： &lt;strong&gt;在 TEE 实现本身未被攻破、远程证明可信的前提下&lt;/strong&gt; ，哪怕云服务商的运维人员或操作系统被彻底攻破，也无法读取 TEE 内部的内存明文。其性能损耗通常仅在 &lt;strong&gt;2%–7%&lt;/strong&gt; ，多数场景低于 5%，是目前较为可行的“硬件级安全计算端到端保护”方案。&lt;/p&gt;
&lt;p&gt;需要强调的是，真正的“机密推理”不是简单打开某个 GPU 的安全功能，而是要把 CPU、GPU 和两者之间的数据传输一起保护起来，并在计算开始前确认整个环境是可信的。&lt;/p&gt;
&lt;h2 id="防患于未然应用部署层面的安全防护措施"&gt;防患于未然：应用部署层面的安全防护措施
&lt;/h2&gt;&lt;p&gt;在计算安全技术没有大规模应用普及之前，企业在部署 LLM 应用时，可以根据数据敏感程度采取分层防护措施。&lt;/p&gt;
&lt;h3 id="客户端与网关侧动态数据脱敏masking--redaction"&gt;客户端与网关侧：动态数据脱敏（Masking &amp;amp; Redaction）
&lt;/h3&gt;&lt;p&gt;在数据离开企业内网之前部署 AI 网关或脱敏中间件，利用规则和模型识别 API Key、身份证号、客户信息、财务数据等敏感内容，并用占位符（如 &lt;code&gt;[USER_1]&lt;/code&gt; ）替换后再发送给公网大模型，返回结果后在企业内部完成还原。&lt;/p&gt;
&lt;p&gt;这种方式对结构化敏感信息比较有效，但对于上下文中隐含的敏感信息，以及通过多轮对话逐步暴露的信息，仍然存在识别遗漏的风险。&lt;/p&gt;
&lt;h3 id="云端服务侧严格控制数据留存zero-data-retention"&gt;云端服务侧：严格控制数据留存（Zero Data Retention）
&lt;/h3&gt;&lt;p&gt;对于需要使用公网大模型、但又不希望数据长期留存在服务商侧的场景，应优先选择具有明确数据留存和训练使用策略的企业级 API 服务，并通过合同、配置和审计等方式进行约束。&lt;/p&gt;
&lt;p&gt;需要注意， &lt;strong&gt;ZDR 的核心是“不留存”或尽量减少留存，并不意味着数据在 GPU 中推理时就自动处于不可见状态&lt;/strong&gt; 。如果对计算过程本身也有较高的安全要求，则需要进一步采用机密计算等技术。&lt;/p&gt;
&lt;h3 id="部署形态侧敏感场景采用本地私有化部署local-llm"&gt;部署形态侧：敏感场景采用本地私有化部署（Local LLM）
&lt;/h3&gt;&lt;p&gt;对于核心代码、重要内部资料以及高度敏感的业务数据，可以将模型直接部署在企业私有云或内部计算节点中，使用 Ollama、vLLM 等推理框架运行开源模型。&lt;/p&gt;
&lt;p&gt;这种方式的核心优势是 &lt;strong&gt;数据不需要离开企业控制范围&lt;/strong&gt; 。但本地部署并不意味着“天然安全”，企业仍需负责模型更新、系统安全、访问控制、数据管理以及 GPU 资源和运行成本。&lt;/p&gt;
&lt;p&gt;因此，实际部署中可以根据数据敏感程度形成简单的选择：&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;一般数据 → 云端 AI&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;敏感数据 → 脱敏后使用云端 AI&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;核心数据 → 企业私有化部署&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;这比试图用一种技术解决所有 AI 数据安全问题，更符合目前的实际情况。&lt;/p&gt;
&lt;h2 id="对电信运营商的深刻启示"&gt;对电信运营商的深刻启示
&lt;/h2&gt;&lt;p&gt;作为拥有庞大网络基础设施、海量高价值用户数据以及承接大量政企信息化建设的运营商（如中国联通、中国移动、中国电信）来说，Anthropic 的报告提供了极具战略价值的启示。AI 时代，运营商参与 AI 安全，不能理解为增加一个新的安全产品，而应充分发挥自身在 &lt;strong&gt;网络、云、算力和边缘资源&lt;/strong&gt; 方面的优势，逐步从“提供连接”向“提供可信的 AI 基础设施”延伸。AI 数据安全将成为运营商进入这一领域的重要切入点。过去运营商解决的是 &lt;strong&gt;“企业如何连接云”&lt;/strong&gt; ，AI 时代可以解决 &lt;strong&gt;“企业如何安全地连接 AI”&lt;/strong&gt; ，再进一步则是 &lt;strong&gt;“企业如何获得可信的 AI 计算环境”&lt;/strong&gt; 。&lt;/p&gt;
&lt;h3 id="从连接安全向-ai-使用安全延伸"&gt;从连接安全向 AI 使用安全延伸
&lt;/h3&gt;&lt;p&gt;通过增强AI智能网关能力，将 AI 访问纳入运营商现有的政企网络和安全服务体系。&lt;/p&gt;
&lt;p&gt;重点不是运营商自己去做一个大模型，而是帮助企业解决AI 可以访问什么、数据能不能出去、应该使用什么模型，以及整个使用过程如何管理。将 AI 安全与政企专线、云联网、SD-WAN 等现有业务结合，逐步形成面向企业的 AI 安全接入能力。&lt;/p&gt;
&lt;h3 id="从提供算力向提供可信-ai-计算环境发展"&gt;从提供算力向提供可信 AI 计算环境发展
&lt;/h3&gt;&lt;p&gt;随着 GPU 算力逐步成为基础资源，单纯提供 GPU 的差异化空间将大大压缩。&lt;/p&gt;
&lt;p&gt;运营商可以进一步强化 AIDC 的 &lt;strong&gt;可信计算和安全保障能力&lt;/strong&gt; ，面向金融、政务、能源、工业以及大型企业等高敏感客户，提供从网络连接到 AI 计算的一体化可信环境。&lt;/p&gt;
&lt;p&gt;发展方向可以概括为： &lt;strong&gt;从“卖算力”向“提供可信的 AI 计算服务”转变&lt;/strong&gt; 。&lt;/p&gt;
&lt;h3 id="发挥网络和边缘资源优势发展分布式-ai"&gt;发挥网络和边缘资源优势，发展分布式 AI
&lt;/h3&gt;&lt;p&gt;AI 的计算位置将不再全部集中于少数大型数据中心。&lt;/p&gt;
&lt;p&gt;运营商应利用现有的省、市、县、园区和企业节点资源，根据业务对时延、数据安全和算力的不同要求，推动 AI 能力向网络边缘延伸。形成 &lt;strong&gt;中心算力负责通用 AI，边缘算力支撑低时延场景，本地算力承载高敏感业务&lt;/strong&gt; 。通过云边协同，使运营商广泛分布的网络和机房资源转化为 AI 基础设施优势。&lt;/p&gt;
&lt;h3 id="从单点能力建设走向云网边算一体化"&gt;从单点能力建设走向云—网—边—算一体化
&lt;/h3&gt;&lt;p&gt;运营商最大的优势并不是掌握某一项 AI 安全技术，而是能同时掌握 &lt;strong&gt;网络连接、数据传输、计算资源和分布式节点&lt;/strong&gt; ，形成系统级的可信 AI 基础设施解决方案。 通过逐步打通 AI 接入、网络连接、算力部署和安全管理，形成统一的 AI 基础设施服务体系，最终实现： &lt;strong&gt;让数据去合适的地方、让 AI 在合适的位置计算，并让整个过程可控、可管、可信。&lt;/strong&gt;&lt;/p&gt;
&lt;h2 id="结语ai时代的安全边界正在进入计算内部"&gt;结语：AI时代的安全边界正在进入“计算内部”
&lt;/h2&gt;&lt;p&gt;AI 的发展正在改变数据安全的边界。&lt;/p&gt;
&lt;p&gt;过去，重点是保护数据在网络传输和存储过程中的安全；现在，企业越来越多地将代码、文档、客户信息和业务数据交给 AI 处理，安全问题进一步延伸到了 &lt;strong&gt;数据进入计算环境之后&lt;/strong&gt; 。因此，AI 时代的数据安全正在从： &lt;strong&gt;传输安全 → 计算安全 → 全生命周期安全。&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;对运营商而言，在 AI 安全领域的演进可以归纳为一条主线： &lt;strong&gt;从“保障网络连接安全”，向“保障 AI 使用安全”，进一步向“提供可信 AI 基础设施”演进。&lt;/strong&gt; 其核心不是与专业 AI 厂商竞争模型和算法，而是发挥运营商 &lt;strong&gt;网络、云、算力和边缘资源的综合优势&lt;/strong&gt; ，成为企业 AI 应用与算力基础设施之间可信赖的连接者、服务者和安全保障者。&lt;/p&gt;
&lt;p&gt;最终需要解决的核心问题其实也很简单： &lt;strong&gt;让数据安全地到达 AI，让 AI 在可信的环境中计算。&lt;/strong&gt;&lt;/p&gt;</description></item></channel></rss>