AI 应用从原型进入生产的速度，已经超过许多企业安全体系的调整速度。传统容器安全可以检查镜像漏洞、限制网络访问，却无法完整回答这些新问题：模型权重是否在硬件层受到保护？提示词注入能否在进入模型前被识别？Agent 执行生成代码时，怎样避免影响宿主节点？
GKE 的 AI 工作负载安全蓝图给出的答案不是单一产品，而是一套纵深防御体系：基础设施层保护计算环境和身份，模型层验证制品来源与完整性，应用层防守真实的推理流量。平台团队可以据此建立一条默认安全、能够逐步增强的 AI 交付路径。
三层防线分别解决什么问题
基础设施层：保护运行环境、身份与数据边界
安全的 AI 服务必须建立在可信集群之上。对于处理敏感提示词、企业知识库和专有模型的推理任务，普通节点隔离并不总是足够。
Confidential GKE Nodes 将内存加密和硬件证明能力扩展到高性能加速器，包括机密 GPU 和 TPU。以 NVIDIA H100 等加速器为例，这类能力用于降低虚拟机监控器遭到入侵或基础设施操作人员越权读取内存时的模型与数据暴露风险。需要注意的是，机密计算保护的是特定运行边界，并不能替代应用鉴权、漏洞修复和输出审查。
身份侧应避免把长期 Google Cloud 服务账号密钥写进 Secret 或镜像。Workload Identity Federation for GKE 可以把 Kubernetes ServiceAccount 映射到 Google Cloud 身份，使推理 Pod 以短期凭据读取 Cloud Storage 中的模型权重。VPC Service Controls 则在服务边界上限制数据流出，适合为受监管项目建立额外的外泄防线。
模型层：记录来源，并保证训练制品就是部署制品
软件物料清单通常记录操作系统包和应用依赖，却不理解模型、数据集、微调产物与推理框架之间的关系。对于自行训练、微调或引入开源权重的团队，这会留下明显盲区。
蓝图提出使用 k8s-aibom 生成面向 Kubernetes 的 AI 物料清单，盘点模型、数据集和框架。它带来的价值不只是合规报表，还包括几个实际问题的可追踪答案：
- 当前线上服务加载的是哪个模型版本？
- 该模型使用了哪些数据集和基础框架？
- 出现高风险依赖或模型污染事件时，哪些工作负载需要下线？
- 镜像、模型权重和部署清单能否关联到同一次发布？
在生产阶段，还应通过 Binary Authorization 强制镜像签名策略。AI BOM 解决“里面有什么”，签名和准入策略解决“是否允许它运行”，两者不能互相替代。
应用层：检查每一次推理，而不只检查容器
提示词注入、敏感信息泄露和有害输出发生在 HTTP 请求与模型响应之间，镜像扫描对此无能为力。Model Armor 被放置在应用与推理端点之间，对提示词和响应进行检查，覆盖提示词注入、PII 暴露及有害内容等风险。
GKE Inference Gateway 则补充会话级可观测性和配额控制。平台可以按用户限制请求速率，识别会话操纵或推理成本滥用，而不必让每个模型团队重复实现同一套网关逻辑。
Agent 场景需要更严格的运行时边界。只要模型能够执行生成代码、调用外部工具或处理不可信文件，就应把这些动作视为不可信代码执行。GKE Sandbox 使用 gVisor 在容器和宿主内核之间增加隔离层，降低容器逃逸和异常系统调用影响节点的风险。代价是一定的性能与兼容性开销，因此更适合工具执行器、代码沙箱等高风险组件，而不一定适合所有 GPU 推理进程。
可以这样实践：无长期密钥的模型读取与 Agent 隔离
下面是一个可改造的最小示例。假设条件是：集群已启用 Workload Identity Federation for GKE，并已启用支持 gvisor RuntimeClass 的 GKE Sandbox。请把项目 ID、Google Cloud 服务账号和镜像地址替换为自己的值。
先为推理工作负载建立 Google Cloud 服务账号，并只授予指定模型存储桶的读取权限：
export PROJECT_ID="my-ai-project"
export BUCKET="my-private-models"
export GSA_NAME="inference-model-reader"
export KSA_NAME="inference-api"
export NAMESPACE="ai-prod"
gcloud iam service-accounts create "${GSA_NAME}" \
--project "${PROJECT_ID}"
gcloud storage buckets add-iam-policy-binding "gs://${BUCKET}" \
--member "serviceAccount:${GSA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com" \
--role "roles/storage.objectViewer"
kubectl create namespace "${NAMESPACE}"
kubectl create serviceaccount "${KSA_NAME}" \
--namespace "${NAMESPACE}"
gcloud iam service-accounts add-iam-policy-binding \
"${GSA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com" \
--role "roles/iam.workloadIdentityUser" \
--member "serviceAccount:${PROJECT_ID}.svc.id.goog[${NAMESPACE}/${KSA_NAME}]"
kubectl annotate serviceaccount "${KSA_NAME}" \
--namespace "${NAMESPACE}" \
iam.gke.io/gcp-service-account="${GSA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com"
接着部署一个使用该身份的工作负载。这里用 Cloud SDK 镜像演示访问存储桶；实际部署时，应替换为经过扫描和签名的推理镜像。
apiVersion: apps/v1
kind: Deployment
metadata:
name: model-reader
namespace: ai-prod
spec:
replicas: 1
selector:
matchLabels:
app: model-reader
template:
metadata:
labels:
app: model-reader
spec:
serviceAccountName: inference-api
containers:
- name: reader
image: google/cloud-sdk:slim
command: ["/bin/sh", "-c"]
args:
- while true; do gcloud storage ls gs://my-private-models; sleep 300; done
securityContext:
allowPrivilegeEscalation: false
runAsNonRoot: true
capabilities:
drop: ["ALL"]
应用后检查 Pod 是否能够在没有静态密钥的情况下访问存储桶：
kubectl apply -f model-reader.yaml
kubectl logs -n ai-prod deployment/model-reader --follow
对于执行生成代码的 Agent，可以在独立 Deployment 中增加 runtimeClassName: gvisor。不要直接给普通推理 Pod 全局启用，先验证系统调用兼容性和性能。
apiVersion: apps/v1
kind: Deployment
metadata:
name: agent-tool-runner
namespace: ai-prod
spec:
replicas: 2
selector:
matchLabels:
app: agent-tool-runner
template:
metadata:
labels:
app: agent-tool-runner
spec:
runtimeClassName: gvisor
automountServiceAccountToken: false
containers:
- name: runner
image: us-docker.pkg.dev/my-ai-project/ai/agent-runner:1.0.0
ports:
- containerPort: 8080
resources:
requests:
cpu: "250m"
memory: "256Mi"
limits:
cpu: "1"
memory: "1Gi"
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
runAsNonRoot: true
capabilities:
drop: ["ALL"]
这个示例只建立身份和运行时隔离。生产系统还需要在推理入口接入内容检查与会话配额，并通过 NetworkPolicy、VPC Service Controls 或出口代理限制 Agent 可以访问的外部地址。
按阶段推进，避免一次性改造失控
蓝图将落地过程划分为三个阶段，这种顺序适合已经有 AI 原型、但尚未建立统一平台规范的团队。
部署阶段建立最低基线：启用 Workload Identity，避免长期密钥；在推理端点前部署 Model Armor；让敏感工作负载运行在 Confidential GKE Nodes 上。此时目标是消除高影响、容易被利用的缺口。
运营阶段把原型加固为生产系统：使用 Binary Authorization 强制签名镜像；根据实际误报和漏报调整 Model Armor 策略；汇总 Kubernetes、身份、网络和推理层审计日志，在 SIEM 中关联分析。内容检查策略不能配置后就长期不动，它需要随模型版本、业务语言和攻击方式持续校准。
治理阶段把人工约定变成组织级控制：通过 Organization Policy Service 设置护栏，使用 Kubernetes 准入 Webhook 拒绝不合规部署，并针对高置信度检测自动执行隔离、吊销权限或暂停端点等响应。自动化处置必须设置回滚机制，避免误报直接造成大面积服务中断。
上线前检查清单
- 推理 Pod 是否完全摆脱长期云凭据，并只获得读取指定模型对象所需的权限？
- 敏感模型和数据是否运行在符合威胁模型的机密节点或加速器上？
- 镜像是否经过签名和准入验证，模型、数据集与框架是否进入 AI BOM？
- 提示词和响应是否都经过内容层检查，而不是只过滤用户输入？
- 网关是否能够按租户或用户执行配额，并记录会话级异常？
- Agent 工具执行器是否使用 gVisor 等隔离机制，并限制网络出口、文件系统和服务账号？
- 基础设施、模型发布和推理安全事件是否能在统一审计系统中关联？
- 自动阻断策略是否经过演练，并具备人工接管与快速回滚路径？
GKE 蓝图的关键价值，在于把 AI 安全拆成可组合的控制层。企业不必等到所有能力一次到位再上线，但应先定义清晰的最低基线，再逐步增加供应链验证、推理路径防护和组织级治理。这样，开发团队获得的是一条可重复使用的安全交付路径，而不是每个项目临时拼装的一组防护措施。