Kubernetes AI Agent 访问控制层：标签+Sidecar 自动拦截越权调用

Kubernetes AI Agent 访问控制层：标签+Sidecar 自动拦截越权调用 | 前端进阶之旅

Full translation

完整中文译文

你的 AI Agent 已经在调用模型、查询数据库、在生产环境请求 API 了。你可能列不出都有哪些。没有人在检查它们是否应该这样做。

我们构建了 AgentPass Mesh 来解决这个问题。一个 namespace 标签。每个 AI pod 自动注入一个 sidecar。每一次调用在发生前都经过检查。

这是真实运行的，你现在就可以试用。

它实际做了什么

AgentPass Mesh 是一个 Kubernetes mutating admission webhook。当你给一个 namespace 打上标签后，在其中创建的每个 pod 都会自动注入一个 2.8MB 的 enforcement sidecar。不需要 SDK。不需要改代码。不需要 init container。只有一个 sidecar 坐在你的 agent 和它要访问的一切之间。

三个门检查每一个出站调用：

LLM Gate —— 这个 agent 可以调用哪些模型？L1 的营销 bot 无法访问需要 L4 的临床笔记模型。请求在离开 pod 之前就被拒绝。

Database Gate —— 按破坏性潜力对 SQL 进行分级。SELECT 是 L0。INSERT 是 L1。UPDATE 是 L2。DELETE 是 L3。DROP 是 L4。你的数据分析 agent 可以读取客户表，但它不能 drop 它。

API Gate —— HTTP 方法映射到信任级别。GET 是 L0。POST 是 L1。PUT/PATCH 是 L2。DELETE 是 L3。监控 agent 不能对你的管理 API 执行 DELETE 操作。

默认拒绝。无法识别的操作？拒绝。

helm install agentmesh oci://ghcr.io/razashariff/agentmesh --set certManager.enabled=true
kubectl label namespace prod agentmesh.io/inject=enabled

就这样。prod namespace 中的每个 AI pod 现在都有了 enforcement。

信任级别如何工作

五个级别，通过 ConfigMap 绑定到 Kubernetes service account：

L0 read-only —— 监控、非敏感查询
L1 standard —— 通用操作
L2 specialist —— 多步骤工作流、数据修改
L3 compliance —— 金融、医疗、法律操作
L4 critical —— 破坏性操作、需要人工审批

你通过 service account 分配级别：

apiVersion: v1
kind: ConfigMap
metadata:
  name: agentmesh-policy
data:
  policy.json: |
    {
      "default_level": 1,
      "agent_bindings": {
        "system:serviceaccount:prod:marketing-sa": 1,
        "system:serviceaccount:prod:analyst-sa": 2,
        "system:serviceaccount:prod:finance-sa": 3,
        "system:serviceaccount:prod:deploy-sa": 4
      },
      "model_policies": {
        "gpt-4": 2,
        "claude-opus-4": 3,
        "clinical-notes-v2": 4
      }
    }

不同的 service account，不同的信任级别，同一个 namespace。不需要修改应用代码。

每个决策都被签名

每一个 enforcement 决策 —— 允许或拒绝 —— 都会用 ECDSA P-256 进行签名，并哈希链入一条防篡改的证据账本。每条记录密码学地链接到前一条记录。篡改一条记录，整条链就会断裂。

这不是日志。这是密码学证明。你获得：

记录编号、时间戳、agent ID
Gate 类型（llm/db/api）、目标、所需级别
决策（ADMITTED/REFUSED）、原因
SHA-256 哈希链接到上一条记录
ECDSA 签名，你可以离线验证

Enforcer 的公钥是公开的。无需触碰集群即可验证任何收据。

带自定义 OID 扩展的 X.509 证书

每个 agent 获得一张 X.509v3 证书，包含五个在 IANA Private Enterprise Number 66339 下的 OID 扩展：

1.3.6.1.4.1.66339.1 -- trust level (L0-L4)
1.3.6.1.4.1.66339.2.1 -- jurisdiction
1.3.6.1.4.1.66339.3 -- capabilities
1.3.6.1.4.1.66339.4 -- protocol binding
1.3.6.1.4.1.66339.5 -- agent ID

OpenSSL 原生读取它们：

openssl x509 -in agent.crt -text -noout | grep -A1 "1.3.6.1.4.1.66339"

包含 SPIFFE URI SAN。如果你已经运行 SPIRE，mesh 接受你现有的 SVID 并将它们映射到信任级别。

攻击来袭时是什么样子

Hugging Face，2026 年 7 月。 一个 AI agent 用有效的 Kubernetes service account token 逃逸出容器。17,600 次未授权操作。凭证窃取。横向移动。身份全程都是有效的。

使用 AgentPass Mesh，我们模拟了同样的攻击。七次操作。全部在 L0 被拒绝。

这个 agent 有有效的身份。它有真实的凭证。mesh 不关心凭证。它根据操作检查信任级别。L0 不能调用 gpt-4（需要 L2）。L0 不能执行 UPDATE（需要 L2）。L0 不能 DELETE（需要 L3）。L0 不能 DROP（需要 L4）。

每一次拒绝都被签名、链化、可审计。

2025 年 7 月。 一个合法认证的 agent 删除了生产数据库。它有完全的连接权限。它有凭证。没有人问一个营销工具是否应该运行 DELETE FROM production_db。

使用 AgentPass Mesh：DELETE 需要 L3。L1 的营销 bot 在 SQL 语句发送之前就被拒绝。DROP TABLE 需要 L4。没有人可以不经过明确分配就获得 L4。

技术规格

用 Go 编写。零外部依赖。纯 stdlib。整个 sidecar 编译成 2.8MB 的 distroless 镜像。

Mutating admission webhook（自动注入 sidecar）
三个 enforcement gate（LLM、DB、API）
每个决策的 ECDSA P-256 签名
带 journal 持久化的哈希链证据账本
带 OID 扩展的 X.509 证书颁发
Prometheus metrics（agentmesh_decisions_total、agentmesh_evidence_records、agentmesh_chain_verified）
Sidecar 上的内置仪表盘（/dashboard）
双向 kill switch（全局撤销一个 agent 或模型）
cert-manager 集成用于 webhook TLS
默认两个副本、PDB、拓扑分布、零停机滚动更新
NetworkPolicy、securityContext、readOnlyRootFilesystem、drop ALL capabilities

在 AWS EKS（1.32）、Google GKE（1.35）、kind（1.36）上验证。Enforcement 延迟：p50 1.1ms，p99 3.1ms。

拉取前验证镜像：

cosign verify --key cosign.pub ghcr.io/razashariff/agentmesh-webhook
cosign verify --key cosign.pub ghcr.io/razashariff/agentmesh-sidecar

为什么不用 OPA/Kyverno/Network Policy

OPA 和 Kyverno 执行 admission policy —— 什么 pod 可以被创建、什么镜像可以运行。它们不评估运行中 pod 内部的单个操作。你的 agent 已经被准入了。OPA 的工作结束了。然后 agent 调用 DROP TABLE。没人检查。

Network policy 控制哪些服务可以与哪些通信。你的 agent 可以到达数据库。Network policy 的工作结束了。然后 agent 执行 DELETE FROM production。没人检查。

AgentPass Mesh 检查操作，而不是连接。它坐在 pod 内部，根据 agent 的信任级别评估每一次调用。OPA 决定 pod 是否可以存在。Network policy 决定 pod 是否可以连接。AgentPass Mesh 决定 agent 是否可以执行它正要做的事。

它们是互补的，不是竞争的。

这是构建在什么之上的

专利 GB2619955.4（Kubernetes inference mesh）和 GB2619899.4（inference trust enforcement）。CyberSecAI 在 AI agent 信任和 enforcement 领域持有 32 项专利。

信任模型和证据格式记录在 IETF Internet-Draft 中，包括 draft-sharif-agent-trust-enforcement 和 draft-sharif-agent-audit-trail。OWASP Agentic Security Top 10 v1.0 引用了这项工作。

在线演示（真实的 Go 引擎、真实的 ECDSA 签名）：https://agentmesh-demo.fly.dev

安装：

helm install agentmesh oci://ghcr.io/razashariff/agentmesh --set certManager.enabled=true
kubectl label namespace prod agentmesh.io/inject=enabled

产品站点：https://agentpassmesh.co.uk IANA PEN：66339

由 CyberSecAI Ltd 构建。问题、反馈、企业许可：contact@cybersecai.co.uk