OpenAI、微软、谷歌等 116 家企业联合签署公开信，呼吁高度重视 AI 时代网络安全——这条消息在技术社区里并不只是新闻，它背后是一个工程判断：当大模型从演示工具进入生产系统，网络安全的边界、责任和风险模型都在发生变化。这封信不是要否定 AI，而是提醒整个产业链，安全必须成为 AI 系统上线的前置条件，而不是事后补救项。
这篇文章不打算复述新闻，而是从工程视角拆解联名信背后的安全趋势：AI 系统到底新增了哪些攻击面，企业应该如何分层应对，开发者和安全团队各自该承担什么职责，以及遇到问题时按什么链路排查。文章会给出可执行的架构示例、基线清单、排查表格和落地建议。适合开发者、安全工程师、架构师，以及需要做技术决策的管理者阅读。
1. 联名信背后的工程判断：AI 让攻击面扩大，也让防御方式改变
1.1 多家企业联合发声的技术背景
公开信的核心诉求并不难理解：AI 的发展速度越快，网络安全建设越不能滞后。OpenAI、微软、谷歌这类企业既在推进大模型应用，也在维护大规模云服务和身份体系，它们对安全风险的感知比普通技术团队更早。
真正值得关注的是，为什么这次是 116 家企业联合发声，而不是某一家厂商单独表态。这说明 AI 安全问题已经跨越了单一产品的边界：模型厂商、云厂商、应用开发商、行业客户都在同一张网络里，任何一方的安全短板都可能被攻击者利用，进而影响整条供应链。公开信本质上是产业链对“共同安全底座”的表态。
对普通技术团队来说，这个信号的意义在于：AI 应用的安全不再只是模型厂商的责任。业务系统接入大模型 API、私有化部署开源模型、用 RAG 架构做知识库问答，都需要自己负责边界防护、权限控制和数据保护。
1.2 AI 时代新增的攻击面
传统网络安全关注的是 Web 应用、操作系统、网络边界、数据库和账号体系。AI 应用在这些基础之上，又叠加了模型、提示词、训练数据、向量数据库、Agent 工具等新组件。
| 资产与组件 | 传统安全关注点 | AI 时代新增风险 |
|---|---|---|
| 应用接口 | 鉴权、参数校验、限流 | 提示词注入、模型输出滥用 |
| 数据管道 | 数据库权限、文件权限 | 训练数据投毒、敏感数据通过问答泄露 |
| 内部工具 | 账号、网络准入 | Agent/插件越权、自动化工具被恶意利用 |
| 模型资产 | 代码仓库、模型文件权限 | 模型权重泄露、模型被反向窃取 |
| 第三方服务 | API 密钥、依赖供应链 | 开源模型/组件供应链风险、第三方模型接口被滥用 |
可以看到，AI 不是取代原有的安全建设，而是在原有安全体系上叠加了一个更复杂的输入输出链路。传统漏洞往往有明确的代码位置和修复补丁，而大模型的问题常常表现为“行为异常”，需要从输入、模型上下文、权限链路、输出渲染多个环节一起排查。
1.3 为什么“先上线再补安全”在 AI 场景行不通
传统业务中，团队习惯先把功能上线，再根据漏洞扫描结果逐步加固。AI 场景这样做风险更高，原因有三点。
第一，大模型系统的行为边界不清晰。同样的用户输入，换一个上下文、换一个温度参数，模型输出就可能不同。上线之后才发现提示词注入可以绕过限制，此时影响已经扩散到真实用户。
第二，安全策略变更会影响模型效果。比如在输出层增加过滤规则，可能误伤正常业务文案；调整 RAG 的检索权限，可能改变回答准确率。这类变更需要反复回归测试，越晚调整，成本越高。
第三，监管和客户审查变得更严格。越来越多行业要求 AI 服务具备数据合规说明、安全评估记录和日志审计能力。没有提前建设，商务合作阶段很容易被卡住。
因此，AI 场景更适合走“安全左移”路线：在项目设计阶段就明确数据边界、权限模型、输入输出过滤和审计要求，而不是等系统被攻击或出现合规问题后再补救。
2. 从 AI 系统的技术链路拆解，安全要落在哪些层
2.1 典型 AI 应用的分层结构
落地 AI 安全之前，先要看清系统由哪些层组成。以常见的知识库问答或企业助手为例，通常包含接入层、模型层、数据层、平台层和基础设施层。
- 接入层：负责接收用户请求，包括 Web 前端、移动端、办公软件入口和第三方业务系统。
- 模型层：包含模型推理服务、提示词模板、RAG 检索流程、向量数据库和模型网关。
- 数据层：包括业务数据库、文档库、用户会话记录、模型微调数据集和日志存储。
- 平台层：包括容器编排、CI/CD 流水线、配置中心、服务网格和消息队列。
- 基础设施层：包括云主机、内网网络、身份认证系统、密钥管理和对象存储。
这五层里的每一层都可能成为攻击目标。安全设计不能只盯着模型层的提示词问题，还要看下层数据是否被越权访问，上层接入是否缺少认证。
2.2 每层的关键风险与控制点
接入层的核心工作是身份认证、访问控制和限流。所有模型 API 请求都应该经过 API 网关，网关负责校验 Token、记录调用方、限制请求频率，并在入口完成基础参数校验。
模型层的核心工作是输入输出治理。用户输入进入模型之前，要做长度限制、敏感内容过滤和提示词注入检测；模型输出返回用户之前，要再次做内容过滤和输出格式校验。这个“双向过滤”是 AI 安全中容易被遗漏的点。
数据层的核心工作是数据分级与权限控制。向量数据库和文档库不能对所有用户一视同仁。企业知识库场景中，不同部门、不同职级的用户能检索的数据范围必须不同，否则会出现普通用户通过问答获取越权信息的问题。
平台层的核心工作是供应链安全和部署安全。模型镜像、Python 依赖、开源组件都要做漏洞扫描。CI/CD 流水线中不允许使用硬编码密钥，模型文件传输要加密，部署环境要与普通业务环境做隔离。
基础设施层的核心工作是零信任和最小权限。无论是开发人员还是模型服务，访问数据库、对象存储和密钥管理时都要按“最小够用”原则授权，并对关键操作做审计。
2.3 一套基础的安全架构示例
下面用简化架构图表示一个企业 AI 助手的请求链路，以及每个节点应该承担的安全职责。
client -> api-gateway -> ai-gateway -> model-service -> vector-db / business-api auth/rate-limit prompt filter sandboxing data access control token validate output filter model policy row-level permission audit log sensitive detect context trace access audit- api-gateway 负责认证、限流、审计日志，任何未携带合法身份信息的请求在这里被拒绝。
- ai-gateway 是新增的安全节点，负责提示词过滤、模型输出过滤、敏感信息检测，以及记录完整的模型调用链路。
- model-service 只负责模型推理，不直接访问业务数据库。模型需要的上下文数据由上层通过受控接口传入。
- vector-db 和业务 API 必须校验请求中的用户上下文，不能只依赖模型层传递的检索结果。
这套架构的核心思想是：模型不被当作信任源头。即使模型被绕过或输出异常，下游数据层仍然有独立的权限校验，上游接入层也保留了完整的调用记录。
3. 企业落地 AI 安全能力的工程步骤
3.1 第一步：资产盘点与风险分级
安全建设不能从零散的工具采购开始，先要明确自己有哪些资产、暴露面有多大、影响范围有多广。
建议按三个维度给资产分级：
- 敏感度：资产中包含的数据是否涉及个人隐私、商业机密或高价值业务数据。
- 暴露面：资产是否对公网开放，是否会被未授权用户访问。
- 影响范围：资产被攻击后，会影响单用户、单个业务系统，还是整个企业。
| 资产示例 | 敏感度 | 暴露面 | 影响范围 | 建议保护等级 |
|---|---|---|---|---|
| 客服问答 API | 中 | 公网 | 业务会话 | 高 |
| 内部代码助手 | 高 | 内网 | 研发效率与代码资产 | 高 |
| 公网概念验证 Demo | 低 | 公网 | 品牌与体验 | 中 |
| 模型微调数据集 | 高 | 内网 | 合规与模型安全 | 高 |
做完盘点后，把保护等级为“高”的资产列入第一批建设范围。不要试图一次性保护所有资产，优先覆盖风险最高、影响最大的链路。
3.2 第二步：建立最小安全基线
资产盘点之后，需要把安全要求固化成可执行的基线。以下基线适合大多数中小企业 AI 项目直接参考：
- 所有模型 API 请求必须经过网关，携带可追踪的请求 ID 和调用方身份。
- 模型管理端口、模型权重存储、微调数据目录默认不对公网开放。
- 用户输入进入模型前，做长度限制和基础内容过滤。
- 模型输出在返回给用户前，做内容转义和敏感信息检测。
- 用户会话日志与业务数据分离存储，日志中不记录完整身份凭证。
- API 密钥、模型密钥统一存储在密钥管理服务中，禁止写入代码仓库和日志。
- 模型服务所在网络与核心数据库网络隔离，通过防火墙或云安全组控制访问。
基线不追求一步到位，但必须覆盖“认证、限流、输入过滤、输出过滤、日志审计、密钥管理”这几项基础能力。
{ "request_id": "a7f2c9e1-8d3b-4f6a-9b0c-1e2d3f4a5b6c", "caller": "internal_hr_system", "model": "gpt-4o-mini", "prompt_tokens": 128, "completion_tokens": 256, "input_filter_result": "pass", "output_filter_result": "pass", "latency_ms": 842 }上面是一段关键调用日志的示例。日志中记录请求 ID、调用方、模型名称、输入输出过滤结果和耗时，但不记录用户输入的完整内容和身份凭证。这样的日志既能支撑问题追溯，又不会因为日志本身泄露敏感信息。
3.3 第三步：在模型上线前完成安全评估
模型上线流程中，安全评估应该和功能测试并行，而不是全部做完后再单独补一次安全检查。
推荐流程：
- 需求评审时确认数据来源和用户权限模型。
- 数据接入前检查文档和数据库权限。
- 模型选型时记录模型版本、训练数据和供应商信息。
- 上线前完成提示词注入测试、敏感数据泄露测试和权限边界测试。
- 灰度发布时观察安全过滤规则的误杀率。
- 全量上线后持续监控异常调用和日志告警。
其中，提示词注入测试和权限边界测试建议由安全团队和开发团队共同完成，测试要在隔离环境中进行，不要针对真实用户发起测试。
4. 实际项目中常见的坑和排查路径
4.1 坑一：只验证功能，不验证安全边界
现象：模型在正常问答场景下回答很好，但用户构造特殊提示词之后，模型输出了系统提示词或内部知识边界以外的内容。
可能原因：安全过滤只放在模型内部 prompt 层，没有在网关出口做二次校验；或者过滤规则只匹配了少量已知样本，没有覆盖变体。
检查方式：构造一批包含指令冲突、角色扮演、越权请求的测试样本，观察网关日志中过滤规则的命中情况。如果输入侧过滤规则没有命中记录，说明规则没有生效或没有部署在正确位置。
处理建议：在 API 网关和 AI 网关两层都部署输入输出过滤；过滤规则要有日志，方便判断是规则未生效还是模型输出了异常内容。
4.2 坑二：API 密钥硬编码或日志泄露
现象：代码仓库扫描发现模型 API 密钥，或者日志系统打印了带 Authorization 头的请求记录。
可能原因：开发阶段为了调试方便把密钥写在代码里；日志框架记录了请求头或请求体全量内容。
检查方式：用代码扫描工具检查仓库中的密钥特征；检查日志采集配置，看是否包含敏感字段。
处理建议：密钥统一放到密钥管理服务中，应用启动时通过环境变量或配置中心读取；日志采集前做字段脱敏，禁止记录 Authorization、密码和完整身份证号。
4.3 坑三：RAG 场景数据访问控制失效
现象：普通用户通过知识库问答检索到了其他部门甚至其他租户的数据。
可能原因：向量数据库没有实现文档级或行级权限过滤；检索接口只传了问题文本，没有传用户身份和权限上下文。
检查方式：查看检索接口的入参是否包含用户身份；检查向量库查询语句是否带权限过滤条件；用两个不同权限的测试账号查询同一问题，对比返回结果。
处理建议：检索请求必须携带用户上下文，业务层在返回文档内容前做二次权限校验。不能把权限过滤完全交给模型，模型不可靠时权限保护必须仍然有效。
4.4 坑四：安全配置变更无人负责，也没有告警
现象：有人修改了网关限流阈值或关闭了输出过滤规则，几周后安全团队才发现。
可能原因：安全配置通过控制台手工修改，未纳入变更管理；缺少配置漂移检测和告警。
检查方式：查看配置中心或网关管理台的变更记录；对比当前配置与基线配置是否一致。
处理建议：安全配置建议采用配置即代码方式管理，变更必须走审批流；对关键配置项设置漂移检测和告警。
4.5 从现象倒推原因的排查链路
遇到 AI 安全相关故障时，按以下顺序排查：
- 确认输入是否正常：请求是否带了合法身份，是否被限流拦截。
- 确认过滤是否命中：查看网关中输入过滤和输出过滤的命中日志。
- 确认权限是否传递：用户身份信息是否从接入层一路传递到数据层。
- 确认日志是否完整：是否有关键请求 ID，能否串联完整调用链路。
- 确认依赖是否安全：模型版本、第三方依赖、镜像是否存在已知漏洞。
| 问题现象 | 常见原因 | 检查方式 | 处理建议 |
|---|---|---|---|
| 模型输出越权信息 | 数据层缺少权限过滤 | 检查检索接口入参和查询条件 | 增加用户上下文与行级权限 |
| 正常请求被安全策略拦截 | 过滤规则过于宽松或误配 | 查看命中规则和返回码 | 调整规则粒度，设置灰度 |
| 密钥疑似泄露 | 密钥写入配置或日志 | 扫描仓库与日志 | 轮换密钥并纳入密钥管理 |
| 安全配置不生效 | 命中错误环境或未发布 | 对比配置与运行环境 | 确认环境、发布状态和告警 |
5. 企业视角：把网络安全从成本项变成能力项
5.1 安全投入的优先级排序
资源有限时，安全投入应该按“保护数据资产、控制身份访问、补齐日志审计、再做智能检测”的顺序推进。
先保护数据资产，因为 AI 系统的价值高度依赖数据。训练数据、业务数据和用户会话数据一旦泄露，影响是直接且不可逆的。
再控制身份访问，因为绝大多数安全事件都与身份滥用有关。模型接口、管理后台、数据存储都必须使用统一的身份认证和授权模型。
然后补齐日志审计，没有日志就无法做事件回溯，也无法定位安全问题的根因。
最后再考虑用 AI 辅助安全运营。如果前几项基础没有做好，引入再多的检测模型也无法解决数据泄露和越权访问问题。
5.2 安全团队、开发团队和模型团队的协作方式
AI 安全不能只靠安全团队。安全团队缺少业务上下文，开发团队缺少威胁建模经验，模型团队对部署链路可能不熟悉。比较有效的做法是建立三方联动的评审机制。
- 安全团队负责输出安全基线和威胁模型。
- 开发团队负责在代码和部署链路中落实控制点。
- 模型团队负责提供模型行为评估结果和提示词测试样本。
每个 AI 项目都应指定一名安全接口人，参加需求评审和上线评审。事件响应流程也需要覆盖“模型输出异常”这类新场景，不能只按传统 Web 故障处理。
5.3 用指标度量安全建设效果
安全的投入效果可以通过指标来跟踪，避免建设变成“买设备、写报告”的形式。
- 覆盖率：有多少个模型 API 接入了统一网关。
- 拦截率：输入输出过滤规则命中了多少异常请求。
- 误杀率：安全过滤对正常业务请求的误伤比例。
- 闭环时间：安全事件从发现到处置完成的时间。
- 配置漂移：生产环境安全配置与基线配置的差异数量。
这些指标不需要很复杂，关键是持续记录并定期复盘。没有指标的安全建设，很难判断投入是否有效。
6. AI 时代网络安全和传统安全的差异速查
6.1 差异对比表
| 维度 | 传统网络安全 | AI 时代安全 |
|---|---|---|
| 主要攻击面 | Web 应用、操作系统、网络边界 | 模型 API、提示词、数据管道、Agent 工具 |
| 漏洞形态 | 代码漏洞、逻辑漏洞、配置错误 | 行为不可控、提示词注入、越权检索 |
| 防御重点 | 边界防护、补丁管理、漏洞扫描 | 输入输出治理、权限与数据隔离、模型行为监控 |
| 责任主体 | 安全团队为主 | 开发、数据、模型、安全多方协同 |
| 验证方式 | 漏洞扫描、渗透测试 | 红队测试、提示词注入测试、模型评估 |
| 修复方式 | 打补丁、改配置 | 调整过滤规则、修改权限链路、重建上下文 |
6.2 对技术选型的影响
传统 API 网关、WAF 和日志系统仍然需要保留，因为大模型应用也是 Web 应用，同样面临认证绕过、爬虫、DDoS 等问题。
在此之上，企业需要考虑增加模型网关或 AI 防火墙，专门处理提示词过滤、模型输出校验、敏感数据识别和模型调用审计。选择这类产品时，重点看三件事：是否支持常见模型的接入协议、过滤规则是否可自定义、是否提供完整调用日志。
日志分析平台也建议做升级。模型调用日志量比普通 API 大，而且需要串联 prompt、检索结果和模型输出。如果现有日志系统无法低成本存储和分析这类数据，可以在模型网关层做采样记录或摘要记录。
7. 给不同角色的落地建议
7.1 开发者的安全检查清单
- 密钥不写入代码、配置文件和日志，统一通过密钥管理服务获取。
- 请求模型之前校验用户身份与业务权限，不信任上游传来的用户标识。
- 对模型输出做转义、长度限制和敏感内容过滤，不能把模型输出直接拼接进页面。
- 记录请求 ID、调用方、模型版本和过滤结果，方便问题回溯。
- 生产环境不使用来源不明的公开模型或数据集，使用前确认授权与安全情况。
- 依赖和镜像上线前通过漏洞扫描，不跳过安全扫描强制发布。
7.2 安全团队的运营清单
- 定期扫描模型 API、管理后台和数据存储的暴露情况。
- 建立提示词注入测试用例库，每次模型更新后回归测试。
- 为模型调用链路配置日志告警和异常流量告警。
- 参与新模型和新 AI 项目的上线评审。
- 对高危数据访问、模型配置文件变更设置审计和告警。
7.3 技术管理者的决策清单
- 是否已经完成模型、数据、API 三类资产的盘点与分级。
- 是否明确每个 AI 项目的安全责任人。
- 是否部署了统一网关、日志审计和密钥管理。
- 新 AI 项目是否设置了安全评审节点。
- 安全事件响应流程是否覆盖模型异常行为和数据泄露场景。
8. 结语：把 AI 安全当作持续工程
116 家企业联合签署公开信，说明 AI 时代网络安全已经从“某个团队的技术问题”上升为“整个产业链的共同议题”。对于一线技术团队，真正值得做的是把这份共识落到自己的系统和流程里。
AI 时代网络安全的核心可以概括为三句话：身份可信、数据可控、行为可审计。模型可以更换，框架可以演进，但安全基线应该稳定地嵌入技术链路。建议每个团队从最小安全基线开始，先覆盖最高风险路径，再逐步补齐监控、告警和自动化能力。
下一步值得关注的方向是：安全能力与 AI 基础设施的深度融合、用 AI 提升安全运营效率，以及行业安全标准的逐步完善。无论技术怎么变化，安全建设都不会是一次性项目，它是和大模型一起持续演进的工程。
