P12 · 如何管理平台权限、资源配额与治理策略？ - Platform Governance
所属知识库：Agent 全栈技术地图
所属领域：04 · Agent Platform
所属章节：02 · Agent Platform 是如何构建和运行的？ - Technical Architecture
文档类型：专题研究 / 技术架构 / 参考设计
版本：v1.3
更新日期：2026 年 11 月 1 日
核心问题：如何在多租户 Agent Platform 中建立统一、可执行、可审计的权限、配额、预算、审批和策略治理体系，并将治理决策贯穿 Agent、Workflow、工具调用及产物交付的完整生命周期？
专题导读
本篇属 Technical Architecture。Agent Platform 的治理（Governance）不是一个管理员设置页面，而是贯穿身份、资源、任务、模型、工具、数据和交付的控制机制。Agent 可长期运行、调用外部工具并产生实际副作用，因此仅在任务启动时检查权限不足以保证安全。本文将治理拆解为策略定义、决策、执行、计量、审计与反馈六个环节，讨论 P1 Control Plane、P2 Execution Plane、P7 Resource & Integration、P8 API & SDK、P10 Data & Assets、P11 Multi-tenancy & Isolation 之间的职责分配。
本文提供可落地的参考架构、对象模型、策略示例、数据库模型、接口契约与验证计划。所有 SQL、代码、性能指标和测试用例均为设计建议，未经真实部署验证。具体法律合规要求应结合适用司法辖区和实际数据处理活动单独评估。
研究结论
- 治理应以策略为中心、以执行点为边界。 统一策略定义不意味着只有一个集中式同步检查服务；每个关键执行点必须具备拒绝不合规操作的能力。
- 权限、配额和预算是不同的决策维度。 权限回答“能不能做”，配额回答“最多能用多少”，预算回答“允许花费多少”，审批回答“是否必须经过人或组织的额外确认”。
- 身份、委托和资源归属必须可验证。 Agent 的工具调用应明确原始用户、运行主体、工作空间、授权范围与有效期，不得依赖模型生成的身份声明。
- 预检与运行时复检并存。 长任务可以固定策略版本用于追溯，但敏感资源访问、授权撤销和外部副作用必须依据有效的当前策略重新判断。
- 配额必须定义精确的计量口径。 请求次数、并发数、Token、CPU 时间、存储量和实际货币成本不能混为一个计数器；估算与结算需分开。
- 策略变更必须可审计、可回滚、可灰度。 应保留策略版本、审批者、变更原因、影响范围与评估记录。
- 治理故障默认应阻断高风险操作。 对只读低风险功能可在受限缓存策略下退化运行，但不可把“策略服务不可用”解释为允许执行。
- 治理有效性需要对抗性测试。 测试不仅覆盖正常授权，也要覆盖越权、配额竞争、审批重放、事件乱序、撤销延迟和故障切换。
01 · 定义、范围与职责边界
1.1 Platform Governance 的定义
Platform Governance 是平台针对主体、资源和行为，制定、实施并证明组织约束的能力集合。它包含身份与授权策略、配额与预算、风险分级、人工审批、审计证据、策略变更管理以及治理效果评估。
| 概念 | 主要问题 | 示例 | 关键区别 |
|---|---|---|---|
| Authentication 身份认证 | 谁在请求？ | 用户登录、服务令牌 | 不直接决定是否有权限 |
| Authorization 授权 | 可以执行什么？ | run:create、artifact:read | 按主体、对象、上下文判定 |
| Policy 策略 | 哪些条件下允许？ | 外发数据必须审批 | 策略可组合权限、风险与组织约束 |
| Quota 配额 | 使用量上限是多少？ | 每租户 20 个并发 Run | 多为数量或速率限制 |
| Budget 预算 | 成本容忍范围是多少？ | 项目月度预算 200 美元 | 需处理成本估算与最终结算 |
| Approval 审批 | 哪些操作需人工确认？ | 对外发送邮件 | 批准应绑定具体操作内容 |
| Audit 审计 | 谁在何时依据什么规则做了什么？ | 工具调用决策日志 | 与普通调试日志不同 |
1.2 与相邻专题的关系
- P1 Control Plane：Run 创建、调度准入、治理策略的协调入口；不是所有调用的唯一执行点。
- P2 Execution Plane：执行时隔离、资源限制和调用前强制校验；不应自行定义组织策略。
- P3 Registry / P4 Development：发布前校验定义、依赖、工具能力和构建来源。
- P5 Deployment：部署权限、环境准入、运行容量与版本升级治理。
- P6 Workflow：节点权限、人工审批、暂停恢复和循环上限。
- P7 Resource Gateway：模型、工具、知识资源调用的最后一道授权与限额执行点。
- P8 API & SDK：认证、对象级授权、速率限制和开发者可理解的错误契约。
- P9 Plugins：插件安装权限、扩展点权限、供应链审核。
- P10 Assets：产物读写、共享、保留与删除策略。
- P11 Multi-tenancy：定义租户隔离边界；P12 定义跨边界操作必须遵守的治理规则。
1.3 非目标
本篇不将模型输出审核等同于平台治理，也不将政策、合同或法律义务简化为单一技术开关。模型行为评估、数据保护影响评估、法务审查与组织制度仍需专门机制。
02 · 治理原则与威胁模型
治理设计采用最小权限、默认拒绝、职责分离、显式委托、可撤销授权、按对象检查、可观测与可追溯原则。重点威胁包括：越权调用工具、Agent 通过提示注入诱导外发数据、预算耗尽攻击、并发绕过限额、审批结果重放、管理员滥用、策略缓存过期、跨租户成本归属错误、审计记录被篡改以及失败重试造成重复扣费。
| 威胁 | 典型路径 | 核心防护 |
|---|---|---|
| BOLA / IDOR | 修改 artifact_id 读取他人文件 | 对象级授权、租户归属校验 |
| Prompt injection | 网页内容要求 Agent 发送私有资料 | 外部内容不具授权权威、网关二次校验 |
| Confused deputy | 低权限 Agent 借高权限连接器执行 | 显式委托与受众限定凭证 |
| 配额竞争 | 并发请求分别读到剩余额度 | 原子预留与唯一键 |
| 审批重放 | 旧批准复用于新收件人 | 审批绑定操作摘要、一次性消费 |
| 策略漂移 | Worker 使用过期规则 | 策略版本、撤销通道、TTL 和敏感操作实时复检 |
| 审计篡改 | 管理员删除不利事件 | 追加式存储、分离权限、完整性校验 |
03 · 治理参考架构
flowchart TB
U[User / Service / Agent] --> API[API Gateway]
API --> CP[Control Plane]
CP --> PDP[Policy Decision Service]
CP --> Q[Quota & Budget Service]
CP --> AP[Approval Service]
CP --> EP[Execution Plane]
EP --> RG[Resource Gateway / PEP]
RG --> PDP
RG --> Q
RG --> EXT[Models / Tools / Data]
CP --> AUD[Audit Event Pipeline]
PDP --> AUD
Q --> AUD
AP --> AUD
RG --> AUD
PDP --> PS[(Versioned Policy Store)]
Q --> LED[(Usage Ledger)]
AP --> APS[(Approval Store)]
AUD --> AS[(Tamper-evident Audit Storage)]这里的 PEP（Policy Enforcement Point）是实际阻断操作的组件；PDP（Policy Decision Point）计算策略决定；PAP（Policy Administration Point）负责策略维护；PIP（Policy Information Point）提供主体、资源和环境属性。该术语与经典访问控制架构一致，但本文的组件组合属于参考设计，而非某个标准强制规定的 Agent 平台形态。
推荐决策路径：入口验证身份 → 解析可信租户与资源归属 → 计算权限与策略 → 检查预算和容量 → 必要时生成审批 → 预留资源 → 启动执行 → 每次敏感调用重新授权 → 记录用量和审计 → 结算并释放预留。
3.1 集中管理与分布式执行
策略存储和管理界面可以统一；执行点应分布在 API、Run 调度器、资源调用网关、资产服务、插件执行器和导出服务。避免单一入口校验后所有下游服务默认信任。服务间调用需要可验证的主体上下文和权限收敛机制。
3.2 决策输出
策略决策不宜只有布尔值。推荐返回 allow/deny/require_approval、原因代码、策略版本、约束条件、有效期、审计关联 ID。高风险操作需要明确拒绝原因的内部记录，同时避免向低权限客户端泄露敏感策略细节。
04 · 核心治理对象模型
erDiagram
TENANT ||--o{ POLICY_BINDING : owns
POLICY ||--o{ POLICY_VERSION : versions
POLICY_VERSION ||--o{ POLICY_BINDING : applies
SUBJECT ||--o{ DELEGATION : grants
RESOURCE ||--o{ POLICY_BINDING : scoped
TENANT ||--o{ QUOTA_ACCOUNT : owns
QUOTA_ACCOUNT ||--o{ RESERVATION : reserves
QUOTA_ACCOUNT ||--o{ USAGE_EVENT : records
TENANT ||--o{ BUDGET_ACCOUNT : owns
BUDGET_ACCOUNT ||--o{ COST_ENTRY : posts
APPROVAL_REQUEST ||--o{ APPROVAL_DECISION : receives
POLICY_VERSION ||--o{ POLICY_DECISION : evaluates
POLICY_DECISION ||--o{ AUDIT_EVENT : emits| 对象 | 关键字段 | 不变量 |
|---|---|---|
| Policy | policy_id, tenant_id, name, owner | 稳定身份，不以显示名授权 |
| PolicyVersion | version_id, digest, rules, status | 发布后不可变 |
| PolicyBinding | subject_scope, resource_scope, environment, priority | 必须显式范围 |
| Delegation | issuer, actor, actions, resources, expires_at | 不得扩大委托者权限 |
| QuotaAccount | scope, metric, limit, window | 单位与窗口必须明确 |
| Reservation | request_id, reserved, expires_at, state | 原子占用、可释放 |
| UsageEvent | meter, quantity, unit, source_id | 幂等计量 |
| BudgetAccount | currency, period, soft_limit, hard_limit | 与配额独立核算 |
| ApprovalRequest | action_digest, requester, expires_at | 批准仅适用固定操作 |
| AuditEvent | event_id, actor, action, resource, decision | 不可被业务用户覆盖 |
05 · 身份、权限与委托
5.1 主体与上下文
用户、平台服务、Agent Runtime 和外部集成均可能成为请求主体。推荐安全上下文至少包含 actor_id、actor_type、tenant_id、workspace_id、run_id、delegation_id、audience、issued_at、expires_at 和 trace_id。字段只能来自可信认证链路或经服务端验证的关联对象，不能由 Agent 提示词决定。
5.2 RBAC、ABAC 与 ReBAC
RBAC 适合管理员、编辑者、观察者等角色；ABAC 适合结合环境、风险、数据分类、成本阈值等属性；ReBAC 适合成员关系、资产共享、项目协作等图状关系。实际系统可以组合使用，但必须定义冲突规则，推荐明确拒绝优先于允许，且默认拒绝。
5.3 授权检查示例
{
"subject": {"type": "agent_run", "id": "run_42", "on_behalf_of": "user_7"},
"tenant_id": "tenant_a",
"action": "tool.invoke",
"resource": {"id": "email_connection_3", "type": "connection"},
"context": {"workflow_id": "wf_2", "risk": "external_write", "data_class": "internal"}
}返回示例：
{
"decision": "require_approval",
"reason_code": "EXTERNAL_WRITE_APPROVAL_REQUIRED",
"policy_version": "pv_19",
"constraints": {"recipient_domains": ["partner.example"]},
"decision_id": "pd_811"
}授权通过只表示当前条件满足，不代表操作一定成功，也不代表审批已完成。对于工具调用，Resource Gateway 仍应根据实际参数执行二次校验。
06 · 策略模型、优先级与变更
6.1 策略层级
参考层级为平台全局底线 → 租户规则 → 组织/工作空间规则 → 项目规则 → Agent/Workflow 约束 → 单次 Run 上下文。下层可以收紧但不能突破上层不可覆盖的限制。并非所有规则都应使用同一种继承算法；例如强制合规拒绝、允许清单和预算约束应有不同组合语义。
6.2 参考策略 DSL
schema_version: governance.policy/v1
policy_id: policy_external_email
version: 3
scope:
tenant_id: tenant_a
workspace_id: research_studio
rules:
- id: require_approval_for_external_email
effect: require_approval
when:
action: tool.invoke
resource_type: email
operation: send
constraints:
approval_roles: [workspace_owner]
max_age_seconds: 1800
- id: deny_unapproved_sensitive_export
effect: deny
when:
action: artifact.export
data_classification: restricted
approval_present: false以上 YAML 是示意性的领域策略格式，不是 OPA/Rego 或 Cedar 的有效语法。正式实现必须规定完整 JSON Schema、操作符语义、规则冲突顺序、空值行为与测试样例。
6.3 发布机制
建议：编辑草稿 → 静态校验 → 策略单元测试 → 影响面模拟（dry-run）→ 双人审核（高风险）→ 发布不可变版本 → 小范围灰度 → 全量生效 → 持续监控。回滚是将生效指针切回旧版本，不应删除已经使用过的策略版本。
6.4 变更中的长任务
Run 启动时记录策略版本用于审计；如果管理员撤销连接器授权，后续调用应实时拒绝。策略变更是否中断已开始的纯计算节点，需要产品定义明确的迁移与终止规则，不能仅依赖“版本固定”推断安全。
07 · 配额、速率限制与容量准入
7.1 指标体系
| 维度 | 计量单位 | 典型范围 | 执行方式 |
|---|---|---|---|
| API 速率 | 请求/分钟 | 用户、API Key、租户 | Token Bucket / Sliding Window |
| 并发 Run | 活跃 Run 数 | 项目、租户 | 原子准入与释放 |
| 并发工具调用 | in-flight 次数 | 连接器、租户 | Semaphore / 租约 |
| Token 使用 | 输入/输出 Token | 模型、项目 | 预估与供应商回执结算 |
| 计算资源 | CPU 秒、内存上限 | Worker 池 | 容器/任务资源限制 |
| 存储 | 字节 | 租户、工作空间 | 上传预留、实际结算 |
| 工作流执行 | 节点数、循环次数、最长时间 | Workflow Run | 运行时守卫 |
| 外部 API | 调用次数、供应商配额 | Connection | 资源网关限流 |
7.2 原子预留与结算
不能采用“查询剩余额度 → 允许 → 异步增加计数”的非原子流程。推荐使用数据库事务、Redis 原子脚本或专用配额服务实现 reserve → commit/adjust → release/expire，并以幂等键避免重复扣减。分布式缓存和数据库之间的强一致性、可用性与吞吐量存在取舍，应按指标风险选择。
7.3 配额窗口与公平性
固定窗口可能出现边界突发；滑动窗口计算较复杂；令牌桶允许受控突发。任务队列应考虑租户权重、最大排队长度、优先级饥饿、超时和取消后的配额释放。配额耗尽时返回可操作的错误与合理重试时间，不承诺立即恢复。
08 · 成本、预算与计量账本
8.1 三类成本
估算成本：执行前依据输入大小、模型定价与历史数据推算；暂挂成本：运行中根据用量预留；实际成本：依据模型服务、云服务或外部供应商返回的可核验记录结算。三者不可互相替代。
8.2 预算控制
建议设置软阈值（提醒、降级或审批）与硬阈值（阻止新任务或高成本调用）。已运行任务的终止策略需明确，避免因预算耗尽留下不可恢复的外部副作用。供应商账单可能延迟，平台需记录成本估算误差和补记机制。
8.3 账本设计
每条费用记录应关联 tenant_id、project_id、run_id、step_id、provider_request_id、meter、quantity、unit_price、currency、pricing_version、timestamp、source 和 reconciliation_status。外部供应商请求 ID 若可获得，应优先用于去重。预算应处理跨币种汇率与计价版本，但不能将估算汇率伪装成真实结算汇率。
09 · 人工审批与高风险操作治理
9.1 审批触发
典型触发包括：对外发送邮件、支付、批量删除、发布公开内容、跨租户共享、敏感数据导出、安装高权限插件、提高预算上限和变更平台级策略。审批条件应结合数据分类、目标系统、操作影响和用户角色，而非仅靠工具名称。
9.2 审批状态机
stateDiagram-v2
[*] --> pending
pending --> approved: approve
pending --> rejected: reject
pending --> expired: timeout
pending --> cancelled: requester cancels
approved --> consumed: operation executed
approved --> expired: validity expires
consumed --> [*]
rejected --> [*]
expired --> [*]
cancelled --> [*]批准应绑定精确操作摘要，包括目标、关键参数、数据范围、请求者、租户、过期时间和一次性 nonce。执行前验证摘要未改变、审批者有权、审批未撤销且未消费。用户在 UI 看到的审批摘要应与执行参数一致。
9.3 Human-in-the-Loop 与权限系统
人工确认不是授权替代品：即使审批通过，执行时仍要验证连接器权限、对象归属、预算和当前策略。审批人不应凭审批动作获得自身原本没有的资源访问权。
10 · 运行时治理与外部副作用
10.1 分阶段检查
- Build/Publish：检查 Agent 声明、依赖与工具能力是否满足发布要求。
- Deploy：检查目标环境、部署权限和资源容量。
- Run admission：检查运行权限、配额、预算与任务风险。
- Step dispatch：检查节点级权限、循环次数、超时与状态。
- Tool invocation：检查实际参数、目标资源、敏感数据、委托和审批。
- Artifact delivery：检查下载者权限、数据分类、导出目的与保留策略。
10.2 只读与写入调用
只读查询通常可在严格约束下重试；外部写入可能产生重复邮件、重复支付或重复删除。对副作用调用应使用供应商支持的幂等键、业务去重记录或补偿流程。审批与幂等解决不同问题，不能互相替代。
10.3 失败关闭与受控退化
策略决策服务不可用时，高风险写操作必须拒绝或进入等待；低风险读操作是否使用短期已签名决策缓存，应有明确的风险接受与过期规则。审计管道故障时，对强审计要求操作应停止或进入受控缓冲，避免“先执行、日志以后再说”的不可追溯状态。
11 · 审计、监控与治理证据
11.1 审计事件
{
"event_id": "audit_1001",
"occurred_at": "2026-10-31T16:00:00Z",
"tenant_id": "tenant_a",
"actor": {"type": "agent_run", "id": "run_42", "on_behalf_of": "user_7"},
"action": "tool.invoke",
"resource_id": "email_connection_3",
"decision": "deny",
"reason_code": "APPROVAL_MISSING",
"policy_version": "pv_19",
"trace_id": "trace_77",
"request_digest": "sha256:example-placeholder"
}审计事件应记录决策事实而非不必要的原始敏感内容。高风险场景可采用追加式日志、独立审计存储、哈希链或签名机制提升篡改可检测性；这些机制本身不能保证操作者身份真实或日志绝对完整。
11.2 治理指标
建议监控拒绝率、审批等待时长、预算超支率、配额预留泄漏率、授权决策延迟、策略缓存过期比例、撤销生效延迟、工具越权阻断数、审计丢失率、账单对账差异和误拒绝反馈。指标应按租户与风险类别分层，并避免把用户敏感数据放入高基数标签。
11.3 证据链
对于一次高风险外发，建议关联：用户请求 → Run/Step → 工具参数摘要 → 策略版本 → 授权决定 → 审批记录 → 执行凭证 → 外部结果 → 成本记录 → 产物或交付引用。证据链用于事后核验，不意味着模型输出具有事实真实性。
12 · 数据模型与事务参考
以下为 PostgreSQL 风格的最小示例，省略身份、租户、RLS 和完整外键设计；正式部署需补齐迁移、索引、审计权限和一致性约束。
CREATE TABLE governance_policy_versions (
tenant_id UUID NOT NULL,
policy_id UUID NOT NULL,
version INTEGER NOT NULL CHECK (version > 0),
policy_digest TEXT NOT NULL,
body JSONB NOT NULL,
published_at TIMESTAMPTZ NOT NULL DEFAULT now(),
PRIMARY KEY (tenant_id, policy_id, version)
);
CREATE TABLE quota_accounts (
tenant_id UUID NOT NULL,
account_id UUID NOT NULL,
metric TEXT NOT NULL,
limit_value NUMERIC NOT NULL CHECK (limit_value >= 0),
used_value NUMERIC NOT NULL DEFAULT 0 CHECK (used_value >= 0),
reserved_value NUMERIC NOT NULL DEFAULT 0 CHECK (reserved_value >= 0),
window_start TIMESTAMPTZ NOT NULL,
window_end TIMESTAMPTZ NOT NULL,
PRIMARY KEY (tenant_id, account_id),
CHECK (window_end > window_start)
);
CREATE TABLE quota_reservations (
tenant_id UUID NOT NULL,
reservation_id UUID NOT NULL,
account_id UUID NOT NULL,
idempotency_key TEXT NOT NULL,
quantity NUMERIC NOT NULL CHECK (quantity > 0),
status TEXT NOT NULL CHECK (status IN ('reserved','committed','released','expired')),
expires_at TIMESTAMPTZ NOT NULL,
PRIMARY KEY (tenant_id, reservation_id),
UNIQUE (tenant_id, account_id, idempotency_key),
FOREIGN KEY (tenant_id, account_id)
REFERENCES quota_accounts (tenant_id, account_id)
);
CREATE TABLE approval_requests (
tenant_id UUID NOT NULL,
approval_id UUID NOT NULL,
action_digest TEXT NOT NULL,
requested_by UUID NOT NULL,
status TEXT NOT NULL CHECK (status IN ('pending','approved','rejected','expired','cancelled','consumed')),
expires_at TIMESTAMPTZ NOT NULL,
consumed_at TIMESTAMPTZ,
PRIMARY KEY (tenant_id, approval_id)
);配额预留需要在同一事务中检查 used + reserved + requested <= limit 并更新 reserved_value。可以使用行级锁或带条件的 UPDATE ... WHERE，检查影响行数后再插入唯一幂等预留记录。过期回收应在幂等事务中执行；不能只依赖后台定时任务及时运行。
13 · 平台 API 与错误契约
| API（示例） | 作用 | 权限要求 |
|---|---|---|
POST /v1/governance/decisions:evaluate | 评估策略 | 受信服务身份，禁止公开任意探测 |
GET /v1/policies | 查看可见策略 | policy:read |
POST /v1/policies/{id}/versions | 创建草稿版本 | policy:write |
POST /v1/policies/{id}/versions/{v}:publish | 发布策略 | policy:publish + 必要审批 |
GET /v1/quotas | 查询配额与使用量 | quota:read |
POST /v1/quotas/reservations | 原子预留 | 受信服务身份 |
POST /v1/approvals | 创建审批 | 业务动作授权 + 策略触发 |
POST /v1/approvals/{id}:decide | 审批决策 | approval:decide + 对象级校验 |
GET /v1/audit-events | 查询审计事件 | audit:read + 范围限制 |
典型错误：403 POLICY_DENIED、409 APPROVAL_REQUIRED（具体状态码可按 API 契约选用）、409 QUOTA_EXCEEDED、429 RATE_LIMITED、402/409 BUDGET_EXCEEDED（HTTP 402 的语义需谨慎，推荐稳定错误码优先）、503 POLICY_SERVICE_UNAVAILABLE。每个错误包含稳定 code、request_id、可选 retry_after 与对外安全的 message。不能用 429 代替所有预算或授权错误。
14 · 与 Studio 研究报告平台的完整案例
14.1 角色与边界
Studio 设定为一个租户内多个工作空间和研究项目：项目负责人可配置研究任务；研究 Agent 仅访问批准的检索资源；审核 Agent 可读取本项目产物并提交质量判断；报告导出服务仅在资产访问授权通过后生成下载链接；管理员负责预算和策略，但不能无条件读取所有项目的敏感内容。
14.2 典型流程
sequenceDiagram
participant U as User
participant CP as Control Plane
participant G as Governance
participant W as Workflow Engine
participant RG as Resource Gateway
participant H as Human Approver
U->>CP: 创建研究 Workflow Run
CP->>G: 校验运行权限/预算/配额
G-->>CP: allow + reservation
CP->>W: 启动固定版本工作流
W->>RG: 调研 Agent 请求公开搜索
RG->>G: 校验资源绑定与限额
G-->>RG: allow
RG-->>W: 检索结果与用量
W->>G: 请求向外部邮箱发送报告
G-->>W: require_approval
W->>H: 展示收件人/附件/内容摘要
H-->>W: 批准特定操作
W->>RG: 携带审批引用请求发送
RG->>G: 复检授权/审批摘要/预算
G-->>RG: allow
RG-->>W: 外部执行结果
W->>G: 结算成本与释放预留
W-->>U: 提交报告资产与审计引用14.3 研究任务的策略示例
- 单项目最多 3 个并发 Workflow Run；超出进入队列，不直接拒绝全部任务。
- 调研 Agent 只允许访问公开搜索和项目授权知识库；不能读取其他项目的私有附件。
- 单次任务可设置 Token 与费用软阈值；超过软阈值通知负责人，超过硬阈值暂停新增模型调用。
- 外部邮件、公开发布和跨工作空间共享必须按数据分类触发审批。
- 审核 Agent 对报告质量的通过决定不等于安全审批通过。
- 报告导出应记录 Asset Version、Run ID、下载者身份与交付时间。
这些阈值仅为示例，实际额度应依据模型价格、任务规模、供应商限额和用户体验实测确定。
14.4 初期 MVP 与演进
MVP：服务端身份与对象级授权、项目级并发限制、Run 成本记录、敏感工具审批、审计事件、管理员策略配置。第二阶段：不可变策略版本、预算预留、审批摘要、跨工作空间共享策略、指标看板。第三阶段：多租户策略继承、分布式 PDP/PEP、复杂计费、专属计算池、策略模拟与风险分级。优先复用成熟鉴权和队列组件，不建议初期自行实现完整通用策略语言。
15 · 常见失败模式与工程取舍
| 失败模式 | 后果 | 缓解措施 |
|---|---|---|
| 仅在 API Gateway 校验 | Worker 或内部服务绕过 | 下游对象级 PEP |
| 将 Agent 提示词当作权限规则 | 被提示注入影响 | 独立策略服务和可信身份 |
| 非原子配额计数 | 并发超限 | 原子预留、幂等键 |
| 仅按模型预估费用结算 | 预算不准确 | 用量回执、对账与补记 |
| 审批只绑定工具名 | 批准后替换参数 | 操作摘要、过期、一次性消费 |
| 策略缓存无限期有效 | 撤销不生效 | 短 TTL、事件失效、敏感操作复检 |
| 管理员拥有所有内容访问权 | 过度授权 | 管理权限与数据访问权限分离 |
| 审计日志记录完整密钥或正文 | 二次泄露 | 最小字段、脱敏、访问控制 |
| 失败时默认允许 | 高风险越权 | 高风险操作失败关闭 |
| 一律重试外部写入 | 重复副作用 | 幂等、补偿与人工处理 |
16 · 工程验证与验收矩阵
以下为待执行测试计划，不是已通过测试的记录。验收应保存测试环境、版本、输入、预期、实际结果与证据链接。
| ID | 验证场景 | 预期结果 |
|---|---|---|
| G01 | 未登录请求创建 Run | 拒绝且无执行副作用 |
| G02 | A 租户读取 B 租户策略 | 对象级拒绝 |
| G03 | 工作空间编辑者发布全局策略 | 拒绝 |
| G04 | Agent 自报管理员身份 | 不改变真实授权 |
| G05 | 委托凭证超出原用户权限 | 拒绝扩大权限 |
| G06 | Prompt 注入要求读取私有资料 | Resource Gateway 阻断 |
| G07 | 100 个并发请求争抢最后一个配额 | 仅允许符合剩余额度的预留 |
| G08 | 相同幂等键重复提交 | 不重复占用配额 |
| G09 | Worker 崩溃后配额租约过期 | 安全回收且不重复扣减 |
| G10 | 预算软阈值触发 | 通知或进入指定降级流程 |
| G11 | 预算硬阈值触发 | 阻止新增受控费用 |
| G12 | 供应商回执与估算费用不同 | 正确对账并记录差异 |
| G13 | 审批批准后修改收件人 | 摘要不匹配，拒绝 |
| G14 | 重放已消费审批 | 拒绝 |
| G15 | 审批超时后执行 | 拒绝 |
| G16 | 无权限者审批他人任务 | 拒绝 |
| G17 | 撤销工具连接器权限后继续调用 | 在约定时限内拒绝 |
| G18 | 运行中切换策略版本 | 保留历史记录且敏感操作按当前规则执行 |
| G19 | 策略服务不可用时执行外部写入 | 失败关闭或安全等待 |
| G20 | 审计管道不可用 | 高风险操作按预定策略阻断/缓冲 |
| G21 | 跨项目访问 Artifact | 拒绝或依共享授权允许 |
| G22 | 共享权限撤销后访问 | 新访问被阻断 |
| G23 | 插件请求未授权外部网络访问 | 沙箱与网关阻断 |
| G24 | 工作流无限循环 | 命中节点/时长预算并终止 |
| G25 | 任务取消时存在未结算预留 | 正确结算或释放 |
| G26 | 策略版本回滚 | 新决策使用目标版本且保留历史 |
| G27 | 低权限用户查询审计 | 不泄露他人或跨租户事件 |
| G28 | 同一工具写入超时后重试 | 不重复外部副作用或明确标记不确定 |
| G29 | API 429 / 配额耗尽 | 返回稳定错误码及适当重试提示 |
| G30 | 政策决策与工具调用追踪关联 | 能由 trace_id 重建证据链 |
| G31 | 高风险策略未经必要审核发布 | 阻止发布 |
| G32 | 缓存过期且撤销消息丢失 | 敏感调用不会永久使用旧授权 |
17 · 局限、开放问题与后续研究
本篇的主要局限是未结合具体云供应商、数据库隔离等级、合规地域、商业计费模式进行性能与成本实测。开放问题包括：策略服务在跨地域部署下的延迟与一致性、复杂组织结构的授权图维护成本、长时 Agent 运行中的动态权限撤销语义、外部供应商账单延迟、模型输出风险分级的可靠性，以及跨租户共享资产的生命周期治理。后续应以真实 Studio MVP 建立可执行测试基线，而非仅以架构图评判治理成熟度。
附录 A：参考文献与原始资料
以下为可用于进一步核验的官方规范与文档。引用它们旨在支持相关技术概念；不意味着这些来源定义了统一的 Agent Platform Governance 标准。具体版本、章节与适用性应在工程落地前复核。
- NIST, SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations. csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
- NIST, SP 800-207: Zero Trust Architecture. csrc.nist.gov/pubs/sp/800/207/final
- NIST, AI Risk Management Framework (AI RMF 1.0). www.nist.gov/itl/ai-risk-management-framework
- NIST, SP 800-162: Guide to Attribute Based Access Control (ABAC). csrc.nist.gov/pubs/sp/800/162/upd2/final
- Open Policy Agent, Policy Language / REST API / Decision Logs. www.openpolicyagent.org/docs/latest
- Cedar Policy Language, Authorization Model. docs.cedarpolicy.com
- OpenFGA, Modeling and Authorization. openfga.dev/docs
- OWASP, API Security Top 10. owasp.org/API-Security/editions/2023/en/0x11-t10
- OWASP, Top 10 for Large Language Model Applications. genai.owasp.org/llm-top-10
- PostgreSQL, Row Security Policies. www.postgresql.org/docs/current/ddl-rowsecurity.html
- IETF, RFC 6749: The OAuth 2.0 Authorization Framework. www.rfc-editor.org/rfc/rfc6749
- IETF, RFC 7662: OAuth 2.0 Token Introspection. www.rfc-editor.org/rfc/rfc7662
- IETF, RFC 9457: Problem Details for HTTP APIs. www.rfc-editor.org/rfc/rfc9457
- Kubernetes, Resource Quotas. kubernetes.io/docs/concepts/policy/resource-quotas
- Kubernetes, Admission Controllers. kubernetes.io/docs/reference/access-authn-authz/admission-controllers
- OpenTelemetry, Specification. opentelemetry.io/docs/specs/otel
- CloudEvents, Specification. cloudevents.io
- FinOps Foundation, FinOps Framework. www.finops.org/framework
- Google, Site Reliability Engineering - Handling Overload. sre.google/sre-book/handling-overload
- OpenAPI Initiative, OpenAPI Specification. spec.openapis.org/oas/latest.html
附录 B：研究证据、验证声明与适用边界
证据层级：身份与访问控制、零信任、策略引擎、HTTP、审计与资源配额等基础概念参考上述公开规范；本文提出的六环治理架构、对象模型、状态机、API 路径、SQL、策略示例和 Studio 实施顺序均属于综合推导的参考设计，不是某一官方规范的逐字要求。
未验证事项：未运行 SQL 迁移、未部署 OPA/Cedar/OpenFGA、未执行 32 项测试、未测量并发配额争抢、未验证特定云供应商成本账单、未进行渗透测试。任何示例阈值、字段或状态码均需结合产品需求与实际服务契约调整。
适用范围：面向具有多 Agent、异步 Workflow、工具调用、资产交付和潜在多租户需求的 Agent Platform；对单机个人实验系统可按风险简化，但不能省略实际存在的敏感操作授权与外部副作用保护。
章节衔接：至此完成 04 · Agent Platform / 02 · Technical Architecture 的 P1 - P2 - P3 - P4 - P5 - P6 - P7 - P8 - P9 - P10 - P11 - P12 专题序列。下一章为 03 · Agent Platform 应该提供哪些产品功能？ - Product Architecture，建议先编写章节概述，再依正式目录研究 F1 - F2 - F3 - F4 - F5 - F6 - F7 - F8 - F9 - F10 - F11 - F12。