企业 Agent Control Plane 完整项目：Identity + Policy + Approval + Audit + Kill Switch

摘要： 企业 Agent Control Plane 不是一个展示 Agent 列表的后台，而是一条位于模型、工具与生产系统之间的强制控制路径。完整方案应把用户身份、Agent 工作负载身份、策略决策、人工审批、审计证据和 Kill Switch 统一到每一次工具调用中。本文给出 Identity + Policy + Approval + Audit + Kill Switch 的可部署参考架构、数据模型、OPA 策略、FastAPI 执行流程、Docker Compose、测试矩阵、成本与迁移方案，适合企业 AI 团队、Agent 平台开发者、DevSecOps、安全团队和系统集成商直接规划 PoC 或生产项目。

核心结论

企业 Agent Control Plane 值得建设，尤其当 Agent 已能读写企业文件、调用 MCP 工具、执行代码、发送消息或修改生产数据时。它的价值不是让 Agent “更聪明”，而是保证每个动作都能回答：谁在操作、以哪个 Agent 身份操作、为什么允许、谁批准、发生了什么，以及出事后如何立即停止。

• 身份必须包含两类主体。 用户身份回答“谁委托”，工作负载身份回答“哪个 Agent 实例在执行”；不能只记录一个可伪造的 agent_name。
• 策略必须位于执行路径。 Policy Decision Point 可以外置，但 Policy Enforcement Point 必须挡在工具、凭据和生产资源之前；日志告警不能替代强制拦截。
• 审批必须是可信原生界面。 付款、删除、发信、发布、权限修改和生产写入要展示规范化后的最终参数，审批令牌短时、单次并与请求摘要绑定。
• 审计必须可关联、可验证、可最小化。 每次动作关联 user、agent、tool、resource、policy、approval 与 trace，同时避免把提示词、密钥和隐私数据整包写入日志。
• Kill Switch 必须独立于 Agent。 至少支持全局、租户、Agent、工具和凭据五级熔断，并在执行前检查；只在控制台里放一个按钮不算真正的停止机制。

为什么企业需要 Agent Control Plane

普通 SaaS 的请求路径相对清晰：用户登录、应用后端鉴权、调用数据库。Agent 系统增加了模型决策、工具发现、动态参数、长任务、重试和多 Agent 委派。一次自然语言请求可能在几分钟内触发文件读取、网页访问、代码执行、工单写入和邮件发送。如果每个 Agent 自己管理 Token、权限、审批和日志，企业会得到多个互不一致的安全孤岛。

Control Plane 的目标是把治理能力平台化，但不要把它误解为所有业务流量都必须经过一个巨型单点。更合理的做法是“集中定义、分布执行”：身份与策略在中央管理，策略包和熔断状态可下发到靠近工具的 Enforcement Gateway；审批与审计集中关联；高可用场景允许只读策略缓存，并针对失联情况明确 fail-open 或 fail-closed。

NIST AI RMF 把 AI 风险管理组织为 Govern、Map、Measure、Manage 四类功能，并强调责任、监督和持续管理。本文的 Control Plane 是一套工程实现建议，不是 NIST 官方产品。企业可以将 Identity 与 Policy 对应治理和风险映射，将 Audit 对应测量，将 Approval 与 Kill Switch 对应风险管理和响应。

AI Stack Nav 站内可配合阅读 企业 AI Agent 治理教程 与 MCP Gateway 安全实践，把本项目与 Sandbox、Network Egress、Secrets 和预算控制组合成完整治理平台。

五大模块与责任边界

模块	必须解决的问题	关键输入	关键输出	不能替代的能力
Identity	谁委托、哪个实例执行、凭据属于谁	用户 Token、工作负载证明、委派链	Auth Context	不替代授权策略
Policy	当前动作在当前环境是否允许	主体、工具、资源、参数、风险、环境	allow/deny/require_approval	不替代后端权限校验
Approval	高风险动作是否得到明确授权	规范化请求、风险说明、影响范围	单次短时 Approval Grant	不替代身份认证
Audit	能否还原与证明完整调用链	决策、审批、执行结果、trace	可查询证据与告警	不应保存全部敏感内容
Kill Switch	能否在异常时立即阻断	状态、范围、原因、版本	强制拒绝与撤销动作	不替代根因修复

Identity：用户身份与工作负载身份分开

用户通过企业 IdP 使用 OIDC/OAuth 获得身份，Agent Runtime 则应拥有独立、短期、可轮换的工作负载身份。SPIFFE 标准定义了 SPIFFE ID、可验证身份文档 SVID 和 Workload API；SPIRE 可通过节点与工作负载证明，根据注册条件为工作负载签发身份。这适合 Kubernetes、虚拟机和混合环境中的 Agent Runtime，但不是唯一选项。

建议把一次调用的身份上下文标准化为：

{
  "tenant_id": "tenant_demo",
  "user": {"sub": "user_123", "roles": ["developer"]},
  "agent": {
    "id": "code-review-agent",
    "instance_id": "run_01J...",
    "workload_id": "spiffe://example.com/ns/agents/sa/code-review"
  },
  "delegation": {"parent_agent": null, "depth": 0},
  "session": {"id": "sess_01J...", "auth_time": 178...}
}

agent.id 只用于展示和策略匹配，不能作为密码。Control Plane 必须验证用户 Token 的 issuer、audience、过期时间和授权范围，并验证工作负载凭据的信任域、证书链或签名。用户 Token 不应直接转发给第三方工具；工具凭据由 Broker 按主体、工具和任务范围临时兑换。

Policy：把模型建议变成确定性决策

策略输入不应只有工具名。相同的 database.update，写测试库与生产库风险不同；更新一条草稿和批量删除风险不同。至少纳入主体、Agent、工具、资源、环境、数据分类、参数摘要、时间、网络目标、委派深度和预算状态。

Open Policy Agent 提供 Rego 声明式策略语言和 API，可把策略决策从业务代码中分离。OPA 是可选实现；企业也可以使用 Cedar、云厂商策略服务或自研 PDP。无论选什么，必须保证执行点消费的是结构化决策，而不是让模型解释自然语言规则。

package agent.authz

default decision := {"effect": "deny", "reason": "default_deny"}

decision := {"effect": "allow", "reason": "read_only_non_prod"} if {
  input.action.risk == "low"
  input.action.mode == "read"
  input.resource.environment != "prod"
  not input.kill_switch.active
}

decision := {"effect": "require_approval", "reason": "prod_write"} if {
  input.action.mode == "write"
  input.resource.environment == "prod"
  input.user.mfa == true
  not input.kill_switch.active
}

策略决策应返回 effect、reason、policy_version、obligations 和 decision_id。Obligation 可以要求脱敏、限流、二次认证、指定审批组、限制最大行数或使用沙箱执行。Policy 版本必须进入审计，便于回答“当时依据哪一版规则放行”。

Approval：把人类确认做成可验证协议

“Agent 在聊天里问一句是否继续”不等于安全审批。Prompt Injection 可以伪造解释，用户也可能在没看到最终参数时同意。可信审批应由 Control Plane 生成规范化操作摘要，在独立于 Agent 输出的界面中展示：主体、Agent、工具、目标资源、关键参数、风险、预计影响、有效期和回滚方法。

审批记录至少包含：

{
  "approval_id": "apr_01J...",
  "request_hash": "sha256:...",
  "decision_id": "dec_01J...",
  "approver_sub": "manager_456",
  "scope": {"tool": "crm.bulk_update", "resource": "segment_2026Q3"},
  "expires_at": "2026-09-23T20:10:00Z",
  "max_uses": 1,
  "status": "approved"
}

执行网关收到 Approval Grant 后重新计算请求哈希，并检查未过期、未使用、审批者满足职责分离以及当前 Kill Switch 未激活。参数发生任何实质变化都必须重新审批。审批不能授予模糊的“未来一小时所有操作”，除非策略明确限定工具、资源、次数和额度。

审批矩阵示例

风险级别	操作示例	默认处理	建议审批者	附加控制
低	查询公开状态、读取非敏感测试数据	自动允许	无	限流、字段过滤
中	创建草稿、写测试环境	条件允许	任务发起人	幂等、超时、回滚
高	发邮件、公开发布、生产写入	必须审批	资源负责人	MFA、短时授权
严重	批量删除、付款、改权限	双人审批或禁止	业务与安全负责人	四眼原则、额度、延迟执行

Audit：从普通日志升级为调用证据链

OpenTelemetry 提供 vendor-neutral 的 trace、metric 和 log 采集模型，可用共享上下文关联分布式请求。它适合构建 Agent 调用链的技术可观测性，但“使用 OTel”不会自动满足审计合规；企业仍需定义审计事件 schema、保留期限、访问控制、完整性保护和隐私最小化。

每次工具动作建议生成一个根 trace，并在关键阶段创建 span：agent.plan、identity.verify、policy.evaluate、approval.wait、credential.issue、tool.execute、result.filter。审计事件至少记录：

• trace_id、request_id、task_id 与父级委派链；
• 用户主体、Agent 工作负载身份、租户与环境；
• 工具稳定 ID、资源范围、参数摘要和风险等级；
• Policy Decision、策略版本、匹配规则与 obligation；
• Approval ID、审批者、请求哈希、时间和使用次数；
• Kill Switch 快照、执行结果、错误类型、重试次数和延迟；
• 凭据只记录引用、scope、issuer 和到期时间，绝不记录秘密值。

提示词和工具结果可能包含商业机密、个人信息或攻击载荷，不应默认完整落盘。可以存储内容哈希、字段级摘要、分类标签和经授权的加密证据副本。调试日志与合规审计分开授权和保留，避免开发者为排错获得全部敏感数据。

Kill Switch：真正能停下来的五级熔断

Kill Switch 应当是执行路径中的同步检查，而不是仪表盘上的告警按钮。推荐五级范围：

1. Global： 全平台高风险工具停止，只保留健康检查与只读管理接口。
2. Tenant： 阻断单个租户，防止配置错误或攻击扩散。
3. Agent： 停止特定 Agent 类型、版本或运行实例。
4. Tool： 禁用单个工具、MCP Server 或风险动作。
5. Credential： 撤销具体 Token、密钥租约或凭据 Broker 路径。

状态模型至少包含 scope_type、scope_id、mode、reason、created_by、created_at、expires_at 与单调递增版本。Gateway 在每次执行前读取本地缓存，并通过推送快速更新；缓存过期或控制面失联时，高风险写操作应 fail-closed。只读低风险动作是否 fail-open 由业务连续性策略决定。

Kill Switch 激活后还要执行补偿动作：拒绝新调用、取消排队任务、通知 Runtime 停止、撤销短时凭据、标记已批准但未执行的 Grant 失效，并调查已经进入第三方系统的异步任务。对于无法撤销的外部动作，Kill Switch 只能阻止后续调用，不能“倒带”。

可部署参考架构与技术选型

推荐最小技术栈：FastAPI 或 Go 构建 Control API 与 Enforcement Gateway；PostgreSQL 保存注册、策略版本、审批和审计索引；Redis 保存短时状态、幂等键与熔断缓存；OPA 作为 PDP；企业 OIDC 作为用户 IdP；SPIRE 或云工作负载身份负责 Runtime；OpenTelemetry Collector 汇聚遥测；对象存储保存加密证据；Kafka/NATS 在规模扩大后承载审计事件。

组件	PoC 方案	生产建议	关键风险
用户身份	本地 OIDC 测试 IdP	企业 IdP、MFA、条件访问	Token audience 错配
工作负载身份	签名短时 JWT	SPIFFE/SPIRE 或云工作负载身份	长期静态密钥
Policy	OPA 单实例	多副本 PDP + 策略签名与缓存	策略漂移、默认放行
Approval	Web 管理页	独立可信 UI + 企业 IM 通知	UI 被仿冒、参数变化
Audit	PostgreSQL	OTel + 日志平台 + 不可变存储	敏感数据过量采集
Kill Switch	Redis 状态	多区域状态 + 推送 + 本地强制缓存	控制面失联仍放行

services:
  control-api:
    image: YOUR_REGISTRY/agent-control-api:1.0.0
    environment:
      DATABASE_URL: postgresql://control:YOUR_DB_PASSWORD@postgres/control
      REDIS_URL: redis://redis:6379/0
      OPA_URL: http://opa:8181
      OTEL_EXPORTER_OTLP_ENDPOINT: http://otel-collector:4317
      OIDC_ISSUER: https://YOUR_IDP_DOMAIN/
    depends_on: [postgres, redis, opa]

  enforcement-gateway:
    image: YOUR_REGISTRY/agent-gateway:1.0.0
    environment:
      CONTROL_API_URL: http://control-api:8080
      OPA_URL: http://opa:8181
      FAIL_CLOSED_RISK_LEVELS: high,critical

  opa:
    image: openpolicyagent/opa:latest
    command: ["run", "--server", "--set=decision_logs.console=true", "/policies"]
    volumes:
      - ./policies:/policies:ro

  postgres:
    image: postgres:17
    environment:
      POSTGRES_USER: control
      POSTGRES_PASSWORD: YOUR_DB_PASSWORD
      POSTGRES_DB: control

  redis:
    image: redis:7

  otel-collector:
    image: otel/opentelemetry-collector-contrib:latest
    volumes:
      - ./otel-collector.yaml:/etc/otelcol-contrib/config.yaml:ro

示例为了可读性使用了镜像标签和占位符；生产环境应固定 digest、使用 Secrets Manager，不把数据库密码写进 Compose，并为数据库、Redis、OPA 与 Collector 设置认证、TLS、网络策略、资源限制和高可用。

一次工具调用的完整执行流程

下面的顺序必须由网关强制执行，不能交给模型自觉遵守：

1. 接收调用。 Gateway 生成 request_id，限制载荷大小，验证 schema、工具版本与幂等键。
2. 验证双重身份。 校验用户 Token 与工作负载身份，构建不可由 Agent 修改的 Auth Context。
3. 规范化请求。 解析工具参数、资源、环境、网络目标和数据分类，计算稳定的 request_hash。
4. 检查 Kill Switch。 按 global → tenant → agent → tool → credential 顺序合并状态；命中即拒绝并审计。
5. 策略决策。 将结构化输入发送给 PDP，得到 allow、deny 或 require_approval 及 obligations。
6. 处理审批。 如果需要审批，创建 Pending Request；收到 Grant 后重新校验哈希、有效期、次数和职责分离。
7. 兑换最小凭据。 Credential Broker 根据本次资源和动作签发短期、窄 scope 凭据，不暴露长期密钥给模型。
8. 执行工具。 设置超时、并发限制、网络白名单和资源限额；写操作携带幂等键。
9. 过滤结果。 对返回内容进行数据分类、脱敏、大小限制和 Prompt Injection 标记，再交给 Agent。
10. 完成审计。 关联策略、审批、熔断快照、执行结果与 trace；异常触发告警和自动熔断规则。

FastAPI 执行网关核心示例

下面展示控制顺序，省略具体 JWT、SPIFFE 和数据库实现。生产代码必须使用经过审查的库，并把关键检查放到独立服务或中间件中。

from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
from typing import Any

app = FastAPI()

class ToolRequest(BaseModel):
    tool: str
    resource: str
    environment: str
    arguments: dict[str, Any]
    idempotency_key: str

@app.post("/v1/tool-calls")
async def call_tool(req: ToolRequest):
    auth = await verify_user_and_workload_identity()
    normalized = normalize_and_classify(req, auth)

    kill = await kill_switch.snapshot(normalized)
    if kill.active:
        await audit.denied(normalized, reason="kill_switch", snapshot=kill)
        raise HTTPException(423, "Execution disabled by control plane")

    decision = await policy.evaluate(normalized, kill)
    if decision.effect == "deny":
        await audit.denied(normalized, reason=decision.reason)
        raise HTTPException(403, "Policy denied")

    if decision.effect == "require_approval":
        grant = await approvals.require_valid_grant(normalized, decision)
        if not grant:
            return {"status": "pending_approval", "request_id": normalized.id}

    lease = await credentials.issue_scoped_lease(normalized, decision)
    try:
        result = await executor.run(normalized, lease, timeout_seconds=30)
        safe_result = filter_tool_result(result)
        await audit.completed(normalized, decision, safe_result.metadata)
        return {"status": "completed", "result": safe_result.content}
    finally:
        await credentials.revoke(lease.id)

异常处理要区分“未执行”“执行成功但响应超时”“部分执行”和“未知状态”。对写操作，客户端重试前先用幂等键查询状态；不能因为 HTTP 超时就直接重放。长任务需要独立 Task ID、每次轮询鉴权、取消权限和终态审计。

策略、审批与熔断的数据模型

最小数据库可以包含：principals、agents、workload_identities、tools、resources、policy_bundles、policy_decisions、approval_requests、approval_grants、kill_switches、credential_leases、tool_executions 与 audit_events。

关键约束包括：Approval Grant 的 request_hash 唯一绑定，uses 不得超过 max_uses；Tool Execution 必须引用 Decision；Decision 必须记录 policy digest；Kill Switch 使用乐观锁版本；审计事件只追加不覆盖。删除个人数据时，可使用分离的加密内容仓与密钥销毁实现合规删除，同时保留最小事件证据。

多租户系统必须把 tenant_id 作为所有主键或行级安全条件的一部分，不能只靠前端过滤。任何跨租户支持操作都需要专用角色、工单引用、时间限制和额外审计。

安全测试与验收矩阵

测试类型	场景	预期结果
身份	用户 Token audience 错误、工作负载凭据过期	调用在策略前被拒绝
委派	子 Agent 超过最大深度或提升 scope	拒绝并记录完整委派链
策略	PDP 超时、策略包签名错误	高风险 fail-closed
审批	参数在审批后变化、Grant 重放	请求哈希不匹配或次数耗尽而拒绝
Kill Switch	执行前与排队中激活工具级熔断	新调用拒绝，队列取消，凭据撤销
审计	日志后端暂时不可用	按风险缓冲或拒绝，不静默丢失
重试	工具已成功但网关超时	幂等查询返回原结果，不重复写入
Prompt Injection	工具结果要求绕过策略	内容被标记，执行路径仍需策略决策
隐私	提示词包含密钥和个人信息	审计只保存脱敏摘要与引用
越权	Agent 直接访问目标系统绕过 Gateway	网络策略与资源端鉴权阻断

真正的验收重点是“是否存在绕行路径”。如果 Agent Pod 能直接访问数据库、云 API 或 MCP Server，Control Plane 即使决策正确也只是旁路观察。应通过网络策略、服务网格、私有 DNS、凭据 Broker 和资源端 audience 校验，确保受管工具只能接受 Gateway 身份。

成本、性能与高可用设计

成本主要来自三部分：控制服务与数据库基础设施、遥测与审计存储、人工审批带来的等待时间。模型 Token 往往不是 Control Plane 的主要成本，但策略输入、工具结果和审计若无大小限制，会同时推高 Token 与日志费用。

低延迟路径可把签名策略包和 Kill Switch 状态缓存在 Gateway 本地，将只读低风险决策控制在一次本地评估；高风险动作可以接受额外网络请求和审批等待。策略缓存必须携带版本和过期时间，紧急熔断使用推送通道更新。不要无限缓存 allow 结果，因为主体、资源和风险状态会变化。

Control API、PDP、审批服务和审计管道应独立扩容。PostgreSQL 使用高可用与定期恢复演练；Redis 不作为唯一事实源；审计事件先写耐久队列再异步索引。Kill Switch 状态需要多副本和明确冲突规则，通常以更严格状态优先。

上线前定义 SLO：策略决策延迟、审批通知延迟、审计完整率、熔断传播时间、凭据撤销时间和未知状态任务比例。本文不提供虚构的通用毫秒指标，企业应根据区域、工具风险和业务连续性要求压测确定。

迁移路径与回滚方案

建议分四阶段迁移：

1. Observe： 只接入身份映射和审计，不阻断，但识别所有工具、凭据和绕行路径。
2. Recommend： Policy 产生影子决策，与现有结果对比，修正误报和缺失上下文。
3. Enforce High Risk： 先强制高风险写操作、生产环境和敏感数据，接入审批与 Kill Switch。
4. Default Deny： 所有工具通过 Gateway，采用显式 allow，逐步关闭直连凭据和旧网络路径。

每阶段都要保留回滚：策略包可回退到上一个签名版本；Gateway 可切换到经过批准的保守策略；审批服务异常时高风险操作暂停；审计后端故障时使用本地加密缓冲；Control Plane 故障不能导致 Agent 获得更大权限。

不要用“临时关闭鉴权”作为恢复手段。业务连续性模式也应是预先定义、范围有限、自动过期并可审计的 break-glass 策略，且通常需要双人授权。

局限、隐私与运维注意事项

Control Plane 无法修复模型幻觉，也不能保证第三方工具可回滚。它能做的是在模型输出与真实影响之间建立确定性边界。工具自身仍要校验输入、执行资源级授权，并对重复调用保持幂等。

策略系统也会出错。过于复杂的规则可能互相冲突，外部属性可能过期，OPA 或其他 PDP 自身也需要认证、授权、TLS 和运维。策略即代码要经过代码审查、单元测试、静态检查、签名和分阶段发布。

审批过多会让用户形成“无脑点同意”。应通过风险分级、批次摘要和可撤销草稿减少低价值确认，把注意力保留给真正高风险动作。审批记录属于敏感数据，需要限制查询权限和保留期限。

Kill Switch 也可能被滥用或误触，因此需要强身份、最小管理权限、双人控制、原因字段、自动过期、变更通知和定期演练。演练应验证 Agent 是否真的停止、凭据是否撤销、排队任务是否取消，而不只是控制台状态变红。

事实依据与来源

• 官方事实： NIST AI RMF Core 使用 Govern、Map、Measure、Manage 组织 AI 风险管理；GenAI Profile 是跨行业配套资源。
• 官方事实： SPIFFE 定义工作负载身份框架与 SVID，SPIRE 通过节点和工作负载证明为运行中的工作负载签发身份。
• 官方事实： OPA 是通用策略引擎，使用声明式 Rego 与 API 把策略决策从应用中分离；OPA 自身也需要认证授权。
• 官方事实： OpenTelemetry 是 vendor-neutral 的可观测性框架，可关联 traces、metrics 与 logs，但其本身不等于合规审计系统。
• MCP 相关事实： MCP 架构由宿主执行安全策略和用户授权；最新授权方向继续强调 OAuth、issuer/audience/凭据隔离与逐请求鉴权。
• 实施建议： 五模块架构、五级 Kill Switch、三级/四级风险矩阵、数据模型和迁移路径由本文整理，不是上述项目的统一官方规范。
• 待项目验证： 策略延迟、熔断传播时间、日志成本、审批吞吐和 fail-open 范围必须在目标基础设施中压测与演练。

内容核验日期：2026 年 09 月 23 日。 产品版本、MCP 规范和云身份能力可能变化，部署前应核对目标环境的最新官方文档。

FAQ

Agent Control Plane 与普通 API Gateway 有什么区别？

API Gateway 主要处理路由、认证、限流和协议治理；Agent Control Plane 还理解用户委托、Agent 工作负载、工具风险、模型发起的动态参数、人工审批、委派链和 Kill Switch。二者可以组合，Control Plane 不必替换现有网关。

是否必须使用 OPA？

不是。OPA 是成熟的通用策略引擎，适合本文参考架构，但企业也可选择 Cedar、云原生策略服务或自研 PDP。关键是策略结构化、版本化、可测试，并在工具执行前由 PEP 强制实施。

是否必须部署 SPIRE？

不是。如果云平台已提供可证明、短时、自动轮换的工作负载身份，可以直接使用。SPIFFE/SPIRE 的价值在于跨 Kubernetes、虚拟机和多云提供可移植身份；小型 PoC 可先用签名短时 JWT，但不能退化为共享静态密钥。

Kill Switch 与策略 deny 有什么区别？

策略 deny 是常规业务规则的决策；Kill Switch 是事件响应和紧急隔离机制，优先级更高、传播更快、范围可分级，并会触发取消任务和撤销凭据等补偿动作。实现上可以共用执行点，但管理与审计应分开。

人工审批会不会让 Agent 失去自动化价值？

合理分级不会。低风险只读动作可以自动执行，中风险动作附加约束，高风险不可逆操作才要求审批。目标不是每步都弹窗，而是把人的注意力放在影响大、难回滚和权限敏感的动作上。

审计日志需要保存完整 Prompt 吗？

通常不应默认保存。完整 Prompt 和工具结果可能包含密钥、个人信息或商业数据。优先保存哈希、结构化摘要、分类标签、决策与引用；只有明确合规依据和严格访问控制时才保存加密内容副本。

Control Plane 断网时 Agent 应继续运行吗？

按风险决定。高风险写操作应 fail-closed；经过预先批准的低风险只读动作可以使用短时本地策略缓存。失联策略必须提前定义、自动过期并记录，不能临时由业务代码决定。

如何防止 Agent 绕过 Control Plane 直连工具？

通过网络策略、服务网格、资源端身份校验和凭据 Broker 共同实现。目标系统只接受 Gateway 的工作负载身份或短时 audience 限定凭据，Agent Runtime 不持有可直连生产系统的长期密钥。

最小可行版本应该先做什么？

先建立 Tool Registry、双重身份上下文、Gateway 强制入口、默认拒绝策略、审计事件和工具级 Kill Switch；随后加入高风险审批与凭据 Broker。没有强制入口时，优先不要开发漂亮的治理仪表盘。

参考来源

1. NIST AI Risk Management Framework 资源中心
2. NIST AI RMF Core
3. NIST AI RMF Generative AI Profile
4. Open Policy Agent 官方文档
5. OPA Policy Language
6. OpenTelemetry 官方文档
7. OpenTelemetry Traces
8. SPIFFE 标准概览
9. SPIRE 架构与工作负载证明
10. MCP Architecture
11. MCP 2026-07-28 Specification Release

内容核验日期：2026 年 09 月 23 日

会员充值教程

会员充值与订阅排查资料

适合阅读会员充值、订阅购买、权益对比和支付问题类文章后继续转化。

AI 订阅充值失败排查包 整理常见支付失败、地区限制、订单未到账和账号异常处理步骤。 查看资料包 会员权益对比表 对比不同 AI 工具会员权益、价格、适用人群和购买建议。 查看资料包