1. 项目概述：为什么模型部署是AI应用安全的“阿喀琉斯之踵”？

最近在跟几个做AI应用落地的团队交流，发现一个挺普遍的现象：大家把绝大部分精力都放在了模型训练和调优上，数据清洗、特征工程、炼丹调参，一轮又一轮，追求那零点几个百分点的精度提升。可一旦模型训练“完成”，要部署上线了，很多团队却像完成了一项重大任务一样，直接一个docker run或者kubectl apply就把模型服务推了出去，对后续的安全问题考虑得相当简单，甚至有些“草率”。这让我想起了那个著名的“阿喀琉斯之踵”的故事——再强大的英雄，也有一个致命的弱点。对于AI原生应用而言，这个弱点往往就藏在部署环节。

“AI原生应用安全防护：模型部署阶段的安全检查清单”这个标题，精准地戳中了当前AI工程化实践中的一个关键痛点。它不是一个泛泛而谈的“AI安全”，而是聚焦在“部署”这个承上启下的具体阶段。训练好的模型，本质上是一个封装了复杂逻辑和数据的“黑盒”或“灰盒”资产。部署，就是把这个资产从实验室的沙箱环境，暴露到真实、复杂且充满敌意的网络和生产环境中。这个过程，引入了大量全新的攻击面和风险点，而这些风险，是传统的Web应用安全或网络安全 checklist 所无法完全覆盖的。

从网络热词也能看出这种趋势的紧迫性。大家不再只关心“哪个模型效果最好”，而是急切地想知道“怎么把模型安全地跑起来”。无论是想在树莓派5这样的边缘设备上部署YOLOv5，还是用vLLM、Ollama、MNN等框架在本地或云端部署大语言模型、语音识别模型，亦或是将训练好的深度学习模型塞进嵌入式设备，核心诉求都是一样的：让模型在目标环境中可靠、高效且安全地提供服务。安全，是“可靠”的基石，没有安全，一切性能和功能都如同沙上筑塔。

所以，这份安全检查清单的目的，就是为AI工程师、算法工程师和运维工程师提供一个系统性的、可操作的行动指南。它要回答的问题是：当我们把一个训练好的模型（无论是开源的、闭源的还是自研的）推向生产环境时，除了考虑延迟、吞吐量和资源消耗，我们还需要从哪些维度审视其安全性，并采取哪些具体措施来加固它？这不仅仅是防御外部黑客的攻击，也包括防范因配置不当、依赖漏洞或模型本身缺陷导致的内部故障和数据泄露。接下来，我将结合常见的部署场景和踩过的坑，把这个清单拆解成几个核心模块，逐一说明其必要性和实操要点。

2. 清单核心维度：构建模型部署的“安全结界”

一份有效的安全检查清单，不能是零散要点的堆砌，而应该基于一个清晰的安全模型或框架。对于模型部署阶段，我们可以从四个相互关联的维度来构建这个“安全结界”：模型资产安全、运行环境安全、接口与服务安全以及数据与隐私安全。这四个维度基本覆盖了从模型文件落地到对外提供服务的完整链条。

2.1 模型资产安全：守护你的“智慧结晶”

模型文件（如.pt，.pth，.onnx，.gguf等）是AI应用的核心资产。它的安全，是整个系统安全的第一道门。

1. 完整性校验与防篡改模型文件在传输和存储过程中可能被恶意篡改，植入后门或恶意逻辑。部署前，必须进行完整性验证。

• 操作要点：
  • 发布阶段：模型提供方（无论是内部团队还是第三方）应在发布模型时，同时提供该模型文件的密码学哈希值（如SHA-256）。这应作为模型元数据的一部分。
  • 部署阶段：在将模型文件加载到部署环境前，计算其哈希值，并与官方提供的哈希值进行比对。任何不一致都应立即中止部署并报警。
  • 工具示例：对于从Hugging Face下载的模型，可以利用其提供的snapshot_download功能及校验机制。对于自定义流程，可以使用sha256sum命令或编程语言对应的哈希库（如Python的hashlib）进行校验。

  注意：哈希校验应集成到CI/CD流水线中，作为模型部署流水线的一个强制关卡。手动校验容易遗漏。

2. 来源可信与供应链安全模型的依赖库（如PyTorch, TensorFlow, CUDA驱动，以及各种Python包）构成了复杂的供应链。任何一个环节出现漏洞，都会危及模型服务。

• 操作要点：
  • 固定依赖版本：在requirements.txt或Dockerfile中，严格固定所有依赖库的版本号，避免自动升级引入不可控变化或漏洞。
  • 使用可信源：从官方源或经过内部审计的私有镜像仓库拉取基础镜像和依赖包。避免使用来路不明的pip源或docker镜像。
  • 漏洞扫描：定期使用软件成分分析（SCA）工具（如Trivy, Grype, Snyk）对部署镜像进行扫描，识别已知的公共漏洞披露（CVE）。
  • 最小化镜像：使用Alpine Linux等轻量级基础镜像，并仅安装运行模型所必需的最少包，减少攻击面。

3. 模型固化与格式安全训练框架的模型文件可能包含冗余信息或执行动态逻辑，在部署时最好转换为更稳定、更高效的格式。

• 操作要点：
  • 序列化格式检查：避免使用pickle等不安全的序列化格式保存和加载模型，因为它可能执行任意代码。优先使用torch.jit.script/trace、tf.saved_model或转换为ONNX格式。
  • 模型编译与优化：利用TensorRT、OpenVINO、MNN等推理引擎对模型进行编译和优化。这个过程不仅能提升性能，有时也能消除原始模型文件中一些不安全的动态特性，使其行为更确定。
  • 权重加密（可选）：对于高敏感模型，可以考虑对模型权重文件进行加密存储，仅在运行时于内存中解密。但这会带来一定的性能开销和密钥管理复杂度，需权衡利弊。

2.2 运行环境安全：打造坚固的“托管家园”

模型需要在一个计算环境中运行，这个环境本身必须是安全、隔离且资源受控的。

1. 容器化与隔离容器是目前模型部署的事实标准，它提供了良好的隔离性和可重复性。

• 操作要点：
  • 非Root用户运行：在Dockerfile中明确使用USER指令，让容器内的进程以非root用户身份运行。这遵循了最小权限原则，即使容器被突破，攻击者获得的权限也有限。
  • 只读文件系统：将容器内除了必要的临时目录（如/tmp）和日志目录外的其他文件系统挂载为只读（read-only）。这可以防止攻击者在容器内植入持久化后门或篡改应用代码。
  • 资源限制：通过docker run的--memory，--cpus等参数或Kubernetes的resources.limits，严格限制容器可使用的CPU、内存资源。这不仅能防止单个服务耗尽主机资源，也能在一定程度上缓解资源耗尽型攻击。
  • 安全上下文与能力剥离：在Kubernetes中，为Pod配置安全上下文（Security Context），丢弃所有不必要的Linux Capabilities（如SYS_ADMIN，NET_RAW）。

2. 网络安全策略严格控制模型服务的网络访问权限，遵循“最小必要”原则。

• 操作要点：
  • 服务网格或网络策略：在K8s环境中，使用Network Policies明确定义：哪些Pod/Namespace可以访问模型服务，模型服务又可以访问哪些外部服务（如数据库、监控系统）。默认情况下，应拒绝所有入站和出站流量，再按需开放。
  • 内部服务不直接对外：模型推理服务通常不应直接暴露在公网。应通过API网关、负载均衡器或专门的业务后端服务来代理访问。API网关还可以集成认证、限流、审计等功能。
  • 出站流量控制：模型服务在推理时原则上不应需要主动发起出站网络连接。如果确实需要（例如调用外部API进行后处理），必须在网络策略中明确放行并监控该连接。

3. 主机与运行时安全容器运行在主机上，主机的安全同样重要。

• 操作要点：
  • 主机硬化：确保宿主机操作系统已进行安全硬化，及时打补丁，禁用不必要的服务。
  • 容器运行时安全：选择经过安全审计的容器运行时（如containerd），并保持其更新。
  • 运行时行为监控：可以考虑使用Falco或类似工具，监控容器内是否有异常进程、文件访问或网络活动。

2.3 接口与服务安全：把好对外的“城门”

模型通过API对外提供服务，这个API端点是最直接的攻击面。

1. 输入验证与净化这是防御对抗性攻击（Adversarial Attacks）和提示注入（Prompt Injection）的第一道，也是最重要的一道防线。攻击者会精心构造输入数据，试图让模型产生错误输出、泄露训练数据或执行非预期操作。

• 操作要点：
  • 强类型与格式校验：对API的输入参数进行严格的类型、范围、长度和格式校验。例如，对于图像输入，校验其文件头、尺寸、通道数；对于文本输入，检查长度、字符集。
  • 业务逻辑校验：结合业务场景进行校验。例如，一个信用卡欺诈检测模型，其输入的交易金额不应为负数或异常巨大。
  • 针对性的净化：
    • 对于视觉模型：可以考虑加入输入预处理，如随机裁剪、加噪等，增加模型对对抗样本的鲁棒性（但这可能会影响正常样本的精度，需测试）。
    • 对于LLM：建立“提示词防火墙”。对用户输入进行扫描，过滤或转义可能包含指令注入的特殊字符和模式串。将系统提示词（System Prompt）和用户输入进行清晰、安全的拼接，避免指令混淆。
  • 设置超时与大小限制：防止攻击者发送超大或构造特殊数据导致服务长时间阻塞或内存溢出。

2. 认证、授权与审计不是所有人都可以调用你的模型服务，也不是所有人都可以调用所有功能。

• 操作要点：
  • 认证：为模型服务API配置认证。可以是简单的API Key，也可以是更复杂的JWT（JSON Web Token）或OAuth 2.0。密钥不应硬编码在代码中，而应从环境变量或密钥管理系统（如HashiCorp Vault， AWS Secrets Manager）动态获取。
  • 授权：在认证基础上，实现基于角色的访问控制（RBAC）。例如，内部数据分析师可能只有查询权限，而模型管理員可以有更新模型版本的权限。
  • 审计日志：记录所有对模型服务的访问，包括请求时间、来源IP、用户身份、请求内容（可脱敏）、响应状态和耗时。这些日志对于事后追溯、异常检测和模型效果分析都至关重要。

3. 输出过滤与后处理模型的输出也可能包含敏感信息或有害内容，需要进行过滤。

• 操作要点：
  • 内容安全过滤：对于文本生成类模型（LLM），必须在返回给用户前，对输出内容进行过滤，防止生成暴力、仇恨、歧视性言论或泄露个人隐私信息。可以使用关键词过滤、正则表达式或专门的内容安全API。
  • 置信度阈值：对于分类或检测模型，设置合理的置信度阈值。低于此阈值的结果，应视为“不确定”或“拒绝判断”，而不是强行返回一个可能错误的答案。这可以降低模型在不确定情况下的误判风险。
  • 输出标准化与脱敏：确保输出格式固定，避免因模型输出不稳定导致下游系统解析错误。对输出中可能包含的敏感信息（如身份证号、电话号码）进行脱敏处理。

2.4 数据与隐私安全：贯穿生命周期的“红线”

数据在推理过程中流动，必须保证其机密性和完整性。

1. 推理数据不落地与加密

• 操作要点：
  • 内存处理：尽可能让推理数据仅在内存中流转，避免将用户原始数据（尤其是图片、音频、文档）持久化到磁盘。如果必须缓存（如用于性能优化或调试），应使用加密的临时存储，并设置短期的自动清理策略。
  • 传输加密：确保客户端到API网关、API网关到模型服务之间的所有网络传输都使用TLS/SSL加密（HTTPS）。
  • 内存加密（高级）：对于处理极高敏感数据（如医疗影像、金融交易）的场景，可以考虑使用支持内存加密的硬件或可信执行环境（TEE），如Intel SGX， AMD SEV。但这会带来显著的复杂性和性能成本。

2. 隐私保护技术集成在某些场景下，需要防止模型从输入数据中“记忆”并泄露隐私信息。

• 操作要点：
  • 差分隐私：在模型的训练阶段或推理阶段加入差分隐私噪声，可以严格量化并控制模型泄露训练集中任何单个样本信息的风险。部署时，需要确保推理服务与满足差分隐私的模型兼容。
  • 联邦学习：如果模型更新涉及从边缘设备收集数据，应考虑联邦学习范式，让数据留在本地，只上传模型参数的更新，从源头避免原始数据汇集。

  注意：隐私保护技术通常会影响模型性能（精度或效率），需要在安全、隐私和效用之间做出权衡，并在产品需求定义阶段就明确。

3. 数据残留清理模型服务在运行过程中，可能会在日志、缓存或异常堆栈信息中意外记录用户数据。

• 操作要点：
  • 日志脱敏：确保审计日志中的请求和响应内容不包含完整的个人可识别信息（PII）。在记录前进行脱敏处理。
  • 异常处理：确保全局异常处理器不会将包含用户数据的错误信息（如整个请求体）直接返回给客户端或记录到日志中。
  • 临时文件清理：定期清理/tmp等临时目录，并确保容器重启或销毁后，所有临时数据都被清除。

3. 清单落地：从理论到实践的三个关键场景

安全清单不能只停留在纸上，必须融入到具体的部署流程和工具链中。下面我结合三个典型的热门部署场景，看看如何将上述检查点落地。

3.1 场景一：使用Ollama或vLLM本地部署开源大语言模型

这个场景非常普遍，个人开发者或小团队希望快速在本地或内网部署一个ChatGLM、Llama之类的模型进行测试或内部使用。关键词“ollma部署本地模型教程”、“vllm 可以部署哪些 语音识别 模型”就反映了这种需求。

核心风险点：

1. 模型来源风险：从非官方渠道下载的模型文件可能被篡改。
2. 依赖漏洞风险：Ollama/vLLM及其依赖的PyTorch等库可能存在未及时修复的漏洞。
3. 服务暴露风险：默认配置可能将服务暴露在所有网络接口上，导致内网甚至公网可访问。
4. 提示注入与滥用风险：缺乏对输入输出的过滤，模型可能被用于生成有害内容。

安全检查与加固实操：

1. 模型验证：

   # 假设从Hugging Face下载模型，利用其内置校验 # 使用官方推荐的下载方式，而非直接wget一个不明链接 ollama pull llama2:7b # Ollama会处理验证 # 或者使用 huggingface-cli，它也会进行完整性检查 huggingface-cli download meta-llama/Llama-2-7b-chat-hf --local-dir ./llama2-7b

   对于手动下载的文件，务必比对提供的SHA256值。

2. 安全配置：

   • Ollama：修改Ollama服务配置（通常位于~/.ollama/config.json或系统服务文件），将其绑定到本地回环地址，并考虑设置基本的API密钥。

   // 示例：限制监听地址 { "host": "127.0.0.1" }

   启动时：OLLAMA_HOST=127.0.0.1 ollama serve

   • vLLM：启动vLLM服务时，使用--host和--port参数控制监听地址，并利用--api-key参数启用简单的令牌认证。

   python -m vllm.entrypoints.openai.api_server \ --model meta-llama/Llama-2-7b-chat-hf \ --host 0.0.0.0 \ # 谨慎使用，最好指定内网IP --port 8000 \ --api-key “your-secret-token-here” \ --max-model-len 4096 # 限制输入长度，也是一种防护

3. 网络隔离：如果必须在局域网内提供访问，务必通过防火墙规则（如iptables或ufw）限制只有特定的客户端IP可以访问服务端口。更好的做法是前面加一个Nginx反向代理，在Nginx层面配置IP白名单和HTTPS。

4. 输入输出过滤：这是本地部署最易忽略的一环。你需要编写一个轻量级的代理服务（可以用FastAPI简单实现），放在客户端和Ollama/vLLM之间。这个代理负责：

   • 验证客户端API Key。
   • 对用户输入进行关键词过滤和提示词注入检查（例如，检测是否包含“忽略之前指令”等模式）。
   • 对模型输出进行内容安全过滤。
   • 记录审计日志。

3.2 场景二：将训练好的YOLOv5模型部署到树莓派5等嵌入式设备

关键词“树莓派5上部署自己训练的yolov5模型”、“深度学习训练好模型部署到嵌入式设备的方法”指向了边缘AI部署。这个场景资源受限，安全挑战独特。

核心风险点：

1. 物理安全风险：设备可能被物理接触、窃取或调试接口被利用。
2. 软件更新困难：嵌入式设备系统更新频率低，已知漏洞可能长期存在。
3. 模型泄露风险：模型文件存储在设备闪存上，容易被提取。
4. 数据泄露风险：摄像头等传感器数据若传输未加密，可能被窃听。

安全检查与加固实操：

1. 系统与环境硬化：

   • 禁用不需要的服务：关闭树莓派上不必要的服务（如蓝牙、AVAHI等），使用最小化的操作系统镜像。
   • 只读根文件系统：将系统根分区挂载为只读，防止恶意软件持久化。将需要写的目录（如日志、临时数据）挂载到单独的可写分区或tmpfs。
   • 更新与漏洞管理：建立流程，定期为边缘设备上的操作系统、Python解释器、推理框架（如PyTorch Mobile, ONNX Runtime）打安全补丁。这通常需要OTA升级机制的支持。

2. 模型保护：

   • 模型转换与优化：将PyTorch训练的YOLOv5模型转换为更高效、更封闭的格式，如TensorRT（针对NVIDIA Jetson）、OpenVINO IR（针对Intel硬件）或TFLite。转换过程本身可以对模型结构进行一定程度的混淆和优化。
   • 文件系统加密：对存储模型文件的分区进行加密。树莓派本身没有TPM，但可以使用LUKS等工具配合启动密码或密钥文件（密钥文件存储在安全模块或由服务器下发）来实现。
   • 代码混淆与加固：对部署的推理脚本和应用代码进行混淆，增加逆向工程难度。

3. 通信安全：

   • 启用TLS：如果设备需要将推理结果或状态上报到中心服务器，必须使用TLS（如MQTTS， HTTPS）加密通信通道。
   • 设备身份认证：为每个边缘设备分配唯一的证书或令牌，用于与服务器通信时的双向认证，防止设备被仿冒。

4. 访问控制：

   • 禁用默认的pi用户密码，使用强密码或SSH密钥登录。
   • 关闭不必要的物理接口（如HDMI， USB）的驱动，如果可能的话。

3.3 场景三：在云上使用Kubernetes部署多模型推理服务

这是企业级生产环境的标准场景，涉及微服务、弹性伸缩和复杂的网络。

核心风险点：

1. 配置复杂性风险：K8s配置（如NetworkPolicy， SecurityContext， ServiceAccount）复杂，配置错误会导致安全漏洞。
2. 镜像安全风险：自定义的模型推理镜像可能包含漏洞或敏感信息。
3. 密钥管理风险：模型文件访问密钥、API令牌等硬编码或管理不当。
4. 横向移动风险：一个Pod被攻破后，攻击者可能利用宽松的网络策略在集群内横向移动。

安全检查与加固实操（集成到CI/CD）：

1. 镜像安全流水线：

   • 基础镜像扫描：在Dockerfile构建前，扫描所选基础镜像（如python:3.9-slim）的CVE。
   • 构建时扫描：在CI阶段，使用docker build并配合--secret参数安全地传入构建密钥，避免密钥留在镜像层历史中。
   • 镜像扫描：构建完成后，使用Trivy等工具对生成的镜像进行漏洞扫描，只有通过扫描的镜像才能被推送到镜像仓库。
   • 镜像签名：对最终的生产镜像进行数字签名（使用Cosign），确保部署时拉取的是未经篡改的镜像。

2. Kubernetes清单安全配置：

   # deployment.yaml 部分安全配置示例 apiVersion: apps/v1 kind: Deployment spec: template: spec: securityContext: # Pod安全上下文 runAsNonRoot: true runAsUser: 1000 seccompProfile: type: RuntimeDefault containers: - name: model-server image: your-registry/model:v1 securityContext: # 容器安全上下文 allowPrivilegeEscalation: false capabilities: drop: - ALL # 丢弃所有Linux capabilities readOnlyRootFilesystem: true # 只读根文件系统 volumeMounts: - name: tmp-volume mountPath: /tmp - name: model-volume mountPath: /models readOnly: true # 模型文件只读挂载 resources: limits: memory: “2Gi” cpu: “1” env: - name: API_KEY valueFrom: secretKeyRef: # 从Secret读取密钥，而非环境变量明文 name: model-secret key: api-key volumes: - name: model-volume persistentVolumeClaim: claimName: model-pvc - name: tmp-volume emptyDir: {}

3. 网络策略：

   # network-policy.yaml 示例：只允许来自特定命名空间内API网关的流量访问模型服务 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-api-gateway spec: podSelector: matchLabels: app: model-inference policyTypes: - Ingress ingress: - from: - namespaceSelector: matchLabels: name: api-gateway-ns ports: - protocol: TCP port: 8000

4. 密钥管理：使用K8s的Secret对象存储敏感信息，并通过卷挂载或环境变量注入到Pod中。对于更高级的需求，集成外部的密钥管理系统（如HashiCorp Vault），让Pod动态获取短期有效的凭据。

4. 常见陷阱与排查指南：那些年我们踩过的坑

即使有了清单，在实际操作中还是会遇到各种问题。下面是一些典型的“坑”和排查思路。

问题1：模型服务突然返回异常结果，但日志没有报错。

• 可能原因：
  1. 模型文件被篡改：存储模型文件的磁盘或网络存储出现位翻转，或被人为替换。
  2. 依赖库版本漂移：容器基础镜像或依赖包被意外升级，导致与模型训练时环境不一致。
  3. 输入数据预处理不一致：线上服务的预处理逻辑（如图像归一化、文本分词）与训练时出现细微差异。
• 排查步骤：
  1. 立即检查模型哈希：计算生产环境模型文件的哈希值，与发布时的基准值对比。这是最快能确认模型资产完整性的方法。
  2. 固化并比对环境：检查当前运行容器的镜像ID和层信息，与已知稳定的版本进行比对。使用pip list或conda list导出当前环境所有包及其版本。
  3. 数据一致性测试：准备一组固定的测试用例（黄金数据集），定期用生产服务进行推理，比对结果是否与预期一致。任何偏差都应触发告警。
  4. 启用模型监控：监控模型输出的分布变化（如分类得分分布、检测框数量），使用Evidently AI或WhyLabs等工具检测数据漂移和概念漂移。

问题2：模型服务响应变慢，甚至超时，CPU/内存使用率并不高。

• 可能原因：
  1. 对抗性攻击试探：攻击者可能正在发送大量精心构造的、需要模型进行极端复杂计算的输入进行试探，导致推理时间激增。
  2. 依赖的外部服务延迟：如果模型服务在推理前后需要调用数据库、特征服务或外部API，这些服务的延迟会导致整体变慢。
  3. 资源竞争：虽然容器本身资源未耗尽，但宿主机级别可能发生资源竞争（如IO等待、网络拥堵）。
• 排查步骤：
  1. 分析请求日志：检查慢请求的输入数据是否有共同特征，是否异常大或结构特殊。针对LLM，检查输入token长度是否异常。
  2. 实施请求限流：在API网关层对单个用户/IP的请求频率和并发数进行限制，防止资源被耗尽。
  3. 设置推理超时：在模型服务框架层面（如Triton Inference Server的model configuration）设置每个请求的最大执行时间，超时则主动中断并返回错误，避免请求堆积。
  4. 链路追踪：集成OpenTelemetry等分布式追踪工具，可视化推理请求的完整调用链，精准定位耗时环节。

问题3：收到安全扫描报告，显示模型服务依赖的某个库有高危漏洞。

• 标准处理流程：
  1. 评估影响：确认该漏洞是否在模型服务的运行环境中实际可被利用。有些漏洞可能需要特定的网络权限或本地访问权限，在严格的容器隔离策略下可能无法利用。
  2. 寻找修复版本：查看该依赖库的官方发布说明，找到修复了该漏洞的最小版本。
  3. 测试升级：在测试环境中，将依赖升级到修复版本，运行完整的测试套件（包括功能测试、性能测试和黄金数据集测试），确保模型行为没有回归。
  4. 制定并执行更新计划：如果测试通过，安排生产环境镜像的重新构建和滚动更新。更新后，再次进行安全扫描确认。
• 预防措施：
  • 订阅CVE通知：关注使用的关键框架（如PyTorch， TensorFlow， CUDA）和安全扫描工具（如Trivy）的安全公告。
  • 使用最小化基础镜像：像python:3.9-slim这样的镜像比python:3.9包含更少的软件包，潜在漏洞也更少。
  • 定期重建镜像：即使代码未变，也应定期（如每月）用最新的安全补丁重建基础镜像，刷新所有依赖。

问题4：如何验证部署的模型服务是否真的具备了清单中的安全能力？

• 建议的验证活动：
  1. 渗透测试：聘请专业的安全团队或使用自动化工具，模拟攻击者对模型服务的API端点进行测试，尝试注入攻击、越权访问、拒绝服务等。
  2. 混沌工程实验：在可控的测试环境中，模拟故障场景，如：随机杀死模型服务Pod、模拟网络延迟、填充磁盘空间等，观察系统的自愈能力和是否出现预期外的行为（如泄露内存中的敏感数据）。
  3. 红蓝对抗演练：组织内部的红队（攻击方）和蓝队（防御方）进行对抗演练，红队尝试突破模型部署的安全防护，蓝队负责监测和响应。这是检验安全清单有效性的最佳实践之一。

模型部署的安全是一个持续的过程，而非一次性的任务。这份清单是一个起点，它需要随着威胁态势的变化、新技术的出现以及自身业务的发展而不断迭代和丰富。最关键的，是将安全思维融入到AI工程化的每一个环节，让安全成为模型生命周期中自然而然的一部分，而不是事后补救的负担。在实际操作中，最深刻的体会是，很多安全问题都源于“默认配置”和“图方便”，主动去收紧每一个环节的权限，验证每一个环节的假设，才能构建起真正可信的AI服务。