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 auditapi-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 提升安全运营效率以及行业安全标准的逐步完善。无论技术怎么变化安全建设都不会是一次性项目它是和大模型一起持续演进的工程。