权限、审计与安全

权限化上下文视图的详细设计见 权限视图与 MVC 模型。

治理目标

企业 Agent Harness 必须让智能体能力可控、可查、可停。

重点不是让 agent “永远不会犯错”，而是：

• 错误不越权。
• 高风险动作能拦住。
• 所有关键行为可追踪。
• 出问题后能复盘。

权限模型

建议组合使用：

• RBAC：按角色授权，例如 HR、财务、研发、行政。
• ABAC：按上下文授权，例如部门、数据等级、任务类型、金额阈值。
• Tool Policy：按工具定义只读、写入、高风险动作。
• Permissioned View：按用户、部门、项目、角色和任务裁剪 Agent 可见上下文。

源系统权限是底线。OrgReOrg 可以进一步收窄权限、脱敏字段或要求审批，但不能让 Agent 获得用户在 GitHub、财务系统、CRM、项目管理系统、文档系统或 BI 中本来没有的访问权。

审批策略

以下动作默认需要人工确认：

• 外发正式通知。
• 修改员工、合同、薪酬、财务数据。
• 提交报销、付款、采购等资金相关动作。
• 删除数据。
• 合并代码或发布生产变更。
• 访问超出任务必要范围的数据。
• 将某个部门系统数据长期纳入搜索索引。

审计日志

每次关键操作记录：

• 用户。
• agent session。
• runtime。
• 工具名称。
• 输入摘要。
• 输出摘要。
• 权限判断。
• 审批人。
• 时间戳。
• 关联业务对象。
• 来源系统和对象 ID。
• 当前权限视图。

数据安全

需要默认考虑：

• prompt 敏感信息扫描。
• PII 脱敏。
• 密钥和 token 检测。
• 最小权限访问。
• 数据跨境和供应商合规边界。
• 日志保留周期。

前端入口治理

网页端和企业微信入口降低了使用门槛，也会放大风险。因此入口层需要治理：

• 上传文件需要记录来源、上传人、任务和可访问 agent。
• 企业微信和飞书内容不能默认全部进入 agent 上下文。
• 企业微信和飞书只是统一入口，不是完整数据源；业务事实应通过对应部门系统 Connector 获取。
• 员工自然语言请求需要经过敏感信息和越权意图检测。
• UI 中的高风险按钮必须展示影响范围和确认信息。
• 任务转交需要保留原始上下文和责任链。

Agent-to-Agent 治理

Agent 网络必须有通信边界：

• agent 只能发送其职责范围内的 command。
• 每条 event、command、query 和 artifact 都要带 trace id。
• policy agent 可以拦截高风险 command。
• audit agent 记录关键消息。
• eval agent 可以抽样检查 agent 协作结果。
• 必须检测循环调用、重复执行和冲突写入。

Hooks 的位置

Hooks 可以用于：

• 工具调用前的策略检查。
• 工具调用后的审计写入。
• 用户输入的敏感信息检测。
• 回合结束时的质量门禁。

但 hooks 不应该替代 workflow 和 policy 服务。