安全与治理
角色：企业级智能体平台的治理基线页
说明：本文重点回答“当前方案必须管住什么、分别由谁负责、上线前如何判断可控”，与 方案、总体架构、协议与标准体系 保持一致。
治理目标
结合 NIST AI RMF 的治理思路，企业级智能体平台至少要同时满足六个目标：
- 正确的人，只能在正确的上下文里访问正确的数据和工具。
- 模型、知识、Prompt、工具和策略变更都可追踪、可回放、可回滚。
- 平台输出和自动化动作始终受到策略约束，而不是完全交给模型临场判断。
- 高风险任务存在人工确认、人工接管和事后复盘机制。
- 质量、时延、成本和容量门槛在发布前可验证，而不是事后补救。
- 治理能力从试点开始内建，不随着规模扩大而失控。
当前治理范围
| 治理域 | 重点问题 | 当前主控能力 | 结果要求 |
|---|---|---|---|
| 身份与组织 | 谁能进入系统、是谁、属于哪个租户和部门 | 企业现有 SSO / IAM、APISIX | 入口身份可信、组织属性可传递 |
| 授权与动作控制 | 谁能看、谁能调、谁能执行高风险动作 | Casbin、应用内审批与 Maker-Checker 规范 | 最小权限、动作可裁决 |
| 数据与知识安全 | 哪些数据可入库、可检索、可进入 Prompt | 数据治理链路、权限标签、检索过滤 | 不把越权数据带入模型上下文 |
| 模型与 Prompt 治理 | 用哪个模型、何时切换、何时允许升级 | LiteLLM、Prompt 版本化、评测门槛 | 模型与配置可控、可审计 |
| 观测与审计 | 发生了什么、为什么发生、能否复盘 | LangFuse、OpenTelemetry、Prometheus、Grafana、Loki | 关键链路留痕完整 |
| 发布与运行治理 | 改动何时能上线、异常如何回滚 | 评测、灰度、k6 基线、发布流程 | 有准入门槛，有回滚路径 |
当前组件承载关系
| 治理能力 | 当前主控组件 | 说明 |
|---|---|---|
| 入口认证接入与流量治理 | APISIX + 企业现有 SSO / IAM | 负责入口身份接入、路由、限流和审计前置 |
| 细粒度授权 | Casbin | 负责应用内动作级裁决和策略执行 |
| 知识权限过滤 | OpenMetadata + LlamaIndex | 负责标签治理、可见范围和检索前过滤 |
| 模型调用治理 | LiteLLM | 负责模型路由、配额、留痕和切换控制 |
| LLM 观测与评测 | LangFuse | 负责 Prompt、Trace、评测样本和回放 |
| 平台级观测 | OpenTelemetry + Prometheus + Grafana + Loki | 负责指标、日志和全链路追踪 |
| 发布前容量门槛 | k6 | 负责入口、编排、检索和模型链路压测 |
身份与权限
统一身份主链路
当前方案的公开口径是：
企业现有 SSO / IAM -> APISIX -> 门户 / BFF -> Casbin -> 知识服务 / 工具服务 / 业务服务
分工要保持清楚：
- 企业现有
SSO / IAM负责身份源、登录、组织与账号生命周期。 APISIX负责入口级认证接入、流量治理、审计前置和安全策略前移。Casbin负责应用内细粒度授权裁决。- 业务应用和 Agent Runtime 只消费已经传下来的身份与授权上下文，不自行重造一套权限体系。
如果企业当前没有统一 IAM，应该补齐兼容 OIDC / OAuth2 / SCIM 的实现能力；但这不改变当前公开方案“优先复用企业现有体系”的主口径。
授权模型
企业级平台至少组合使用三类授权：
RBAC：处理岗位、角色、应用菜单、常规功能授权。ABAC：处理部门、租户、项目、数据等级、地域、流程阶段等上下文限制。- 工具级授权：处理写操作、外部通知、审批提交、数据库执行等高风险动作。
组织与身份同步
身份信息进入智能体平台后，至少要保留下列字段：
- 用户 ID
- 部门 / 组织
- 角色
- 租户
- 会话来源渠道
- 应用或场景 ID
- 临时授权或审批状态
这些字段应沿门户、编排、检索、工具和审计链路传递，而不是只在登录页生效。
数据与知识安全
入库前控制
任何面向 AI 的知识资产在入库前都需要经过：
- 分类分级
- 敏感信息识别与脱敏
- 所属部门、业务域、责任人标注
- 生命周期与可见范围定义
- 非结构化内容解析和格式清洗
检索时控制
检索环节不能只看“召回率”，还必须同时做：
- 基于角色、租户、部门和标签的权限过滤
- 对引用来源进行可追溯记录
- 对过期、失效、冲突数据进行抑制
- 对结果拼装范围做最小化控制
Prompt 与输出控制
Prompt 组装和模型输出至少要满足：
- 不把未经授权的内容注入模型上下文
- 对高风险话题和高风险动作做规则前置
- 输出保留引用、来源或行动依据
- 在需要时触发人工确认或二次校验
模型、Prompt 与路由治理
模型治理
模型不是“谁觉得好用就临时换”，而应该受控于统一路由与准入清单：
- 统一通过
LiteLLM暴露给上层调用。 - 为不同业务场景维护白名单模型池。
- 把时延、成本、准确率和安全策略命中作为切换依据。
- 模型切换必须走评测和灰度，而不是直接在生产生效。
Prompt 与配置治理
下列配置都应视为“会改变系统行为的发布项”：
- Prompt 模板
- 工具描述与参数模板
- 知识源绑定关系
- 检索与重排参数
- 模型路由策略
- 安全规则与阈值
这些配置都要进入版本管理和变更记录。
工具与动作治理
一旦系统进入“会执行动作”的阶段，治理重点就从“答得对不对”升级为“做得可不可控”。
工具分级
建议把工具至少分为三类：
- 只读查询：如查知识、查状态、查指标。
- 低风险写入：如生成草稿、创建待审核记录。
- 高风险动作：如发送通知、执行 SQL、提交审批、变更业务系统数据。
高风险动作要求
高风险动作必须满足：
- 动作前有权限裁决。
- 动作前或动作中有人工确认节点。
- 动作后有结果记录、失败原因和补偿动作。
- 审计中能追到“是谁授权、谁执行、执行了什么”。
审计与可观测
审计字段基线
| 维度 | 必须记录的关键字段 |
|---|---|
| 用户访问 | 用户 ID、租户、角色、入口渠道、应用 ID、会话 ID |
| 检索过程 | 数据源、命中记录、权限过滤结果、引用 ID、重排结果 |
| 模型调用 | 模型名称、路由策略、输入摘要、输出摘要、Token 成本、时延 |
| 工具执行 | 工具名称、参数摘要、执行结果、失败原因、补偿动作 |
| 安全策略 | 命中规则、审查结论、人工接管标记、审批记录 |
| 发布变更 | 变更对象、变更人、评测结论、灰度批次、回滚记录 |
双层观测
观测要分成两层：
- 平台级观测：
OpenTelemetry + Prometheus + Grafana + Loki - AI 级观测：
LangFuse
两层缺一不可。前者负责系统运行面，后者负责 LLM 行为面。
发布门槛
上线前必须经过的环节
任何影响运行行为的变更，至少经过以下流程：
- 变更登记与责任人确认
- 离线评测或回归样本验证
- 安全规则与权限检查
k6基线压测与关键链路容量验证staging环境验证- 小流量灰度
- 正式发布与审计抽样复盘
建议关注的核心指标
- 问答正确率和引用有效率
- 工具调用成功率
- 高风险动作误触发率
- P95 时延和失败率
- Token 成本和单位请求成本
- 安全规则命中率和人工接管率
人机协同与人工接管
只要涉及审批、资金、合同、客户外发、生产系统写入、数据库改写等环节，就不能把“模型建议”直接等同于“系统执行”。
当前方案要求：
- 把人工确认设计成显式节点，而不是异常时才临时介入。
- 对高风险流程保留暂停、撤回、重试和人工接管能力。
- 把人工介入结果纳入审计和评测闭环。
角色分工
| 角色 | 主要责任 |
|---|---|
| 平台团队 | 维护平台底座、观测、发布流程和跨场景能力 |
| 业务负责人 | 定义业务目标、验收指标、人工接管规则 |
| 数据负责人 | 确认数据源范围、分类分级、知识可见范围 |
| 安全 / 合规团队 | 审核身份接入、权限模型、审计与高风险动作策略 |
| 运维团队 | 维护环境、容量、备份、恢复和故障处理 |