Harness 架构智能体平台 Policy Engine 高风险操作安全控制方案

Policy Engine 高风险操作安全控制方案

基于 Harness 架构的企业 ERP 智能体平台 — 安全治理专题

适用范围：本方案聚焦付款指令、合同变更两类典型高风险操作，阐述 Policy Engine 的拦截机制、风险评分模型、防绕过手段与审计设计，面向安全架构师与企业 CIO/CFO 团队。

一、Policy Engine 在整体架构中的定位

Policy Engine 是 Harness 架构中唯一有权拦截 Agent 动作的组件。它在 Action Bus 将请求发往 ERP 之前介入，形成同步阻塞式安全门，Agent 必须等待裁决结果才能继续。

1.1 核心设计原则

原则含义
Agent 永不直接执行高风险操作只能生成草稿，实际执行由审批通过后的独立系统完成
规则引擎与 LLM 解耦策略规则是硬代码，不受 Prompt 注入或模型幻觉影响
拦截先于执行任何 ERP 调用必须先通过 Policy Engine 裁决，无旁路
审计先于执行审计记录写入时间早于 ERP API 调用，不可事后删除
最小权限原则每个 Agent 角色只开放本场景所需最小工具集

1.2 三种裁决结果

ALLOW → ERP Connector 直接执行，写入审计日志 REQUIRE_APPROVAL → 冻结操作，生成审批任务，推送审批引擎 审批通过后由审批系统（非 Agent）调用 ERP DENY → 硬性拦截，ERP 完全不调用 写入安全告警，通知安全管理员

二、三维风险评分模型

Policy Engine 在裁决前对操作进行三维量化评分，再映射到 L1-L5 风险等级。

2.1 评分维度说明

维度一：操作类型（0-50分）

操作分值说明
只读查询0无任何 ERP 侧变更
创建草稿10仅在暂存区，未提交
提交 / 修改30改变 ERP 正式数据
付款 / 删除50资金流出或数据销毁

维度二：业务对象（0-30分）

对象分值说明
库存 / 日志5可追溯，影响范围小
采购申请 / 工单15中等业务影响
合同 / 主数据25核心数据，变更成本高
付款单 / 财务凭证30直接涉及资金与账务

维度三：量级参数（0-20分）

金额区间分值
< 10 万元3
10 万 - 100 万元10
100 万 - 500 万元15
> 500 万元20

2.2 等级映射与处置方式

总分等级处置典型操作
0-20L1自动放行 + 日志库存查询、报表生成
21-50L2放行 + 异步通知负责人采购申请创建
51-75L3暂停，操作人二次确认主数据修改
76-90L4冻结，强制触发审批流10-50万付款、合同变更
91-100L5硬性拒绝，不产生任何效果>50万付款指令（Agent无权）

关键设计：L5 不是"拒绝后让人工重试"，而是该操作根本不在 Agent 的权力边界内。付款金额超过 50 万元时，Agent 只能生成草稿，由人工通过独立渠道进入 ERP 完成提交。

三、付款指令：完整控制流程

付款指令是风险最高的 ERP 操作，控制链路覆盖从 Agent 发起到 SAP 执行的全过程。

3.1 五条核心规则（P-001 ~ P-005）

规则 P-001：金额阈值

IF amount > 500,000 CNY AND operator_role NOT IN ["财务经理", "CFO"] THEN → L4（强制审批）

规则 P-002：收款账户核验

IF bank_account NOT IN vendor_master.approved_accounts THEN → L5（硬性拒绝） MSG "收款账户未通过主数据认证，存在欺诈风险，请联系财务核实"

此规则是最高优先级规则，账户与供应商主数据不匹配时直接拒绝，不进入后续规则评估。防范的是通过篡改账户将资金转移至非供应商账户的欺诈场景。

规则 P-003：关联单据有效性

IF reference_po NOT EXISTS OR po.status != "已审批" THEN → L4（冻结至关联单据确认）

规则 P-004：紧急付款窗口

IF payment_date < TODAY + 2 business_days AND amount > 1,000,000 THEN → L4（紧急付款需额外审批） MSG "距付款日不足2个工作日的百万级付款，需财务总监紧急审批"

规则 P-005：单日累计额度

IF SUM(今日 operator 已触发付款) + amount > 5,000,000 THEN → L5（超出个人单日权限上限）

3.2 审批链设计

金额区间审批层级
50 万以下直属经理（1级）
50 万 - 100 万直属经理 → 财务经理（2级）
100 万 - 500 万直属经理 → 财务经理 → CFO（3级）
500 万以上3级 + 董事长（4级）或按公司授权体系

四、合同变更：Diff 强制展示与双重确认

合同变更的核心风险在于条款修改的隐蔽性——Agent 可能用模糊的自然语言描述遮蔽实质性变更。Policy Engine 的核心控制手段是强制生成结构化 Diff，让审批人看到精确变更内容而非摘要描述。

4.1 合同变更控制规则

规则 C-001：Diff 强制生成

所有合同条款修改请求： → 自动拉取原版本快照 → 逐条对比生成变更 Diff → 将 Diff 作为审批任务必要附件 → 缺少 Diff 的审批请求系统拒绝受理

规则 C-002：变更理由强制录入

IF 合同金额 > 100,000 THEN Agent 必须提供： - 变更申请人（实名，非 Agent 自称） - 业务理由（自然语言，字数 ≥ 50） - 关联审批文件编号（如董事会决议号） ELSE → DENY

规则 C-003：并发锁定

合同进入审批流后： → 锁定原版本，禁止任何并发修改 → 审批拒绝 → 解锁，恢复原版本 → 审批通过 → 新版本生效，旧版本归档

规则 C-004：关键条款变更升级

IF Diff 包含以下任一：付款周期、违约责任、争议管辖、知识产权归属 THEN 风险等级 +20 分（自动升级一个等级）

4.2 合同变更审批矩阵

变更类型合同金额审批级别
非关键条款（如地址、联系人）任意L2，部门经理确认即可
关键条款（付款、违约等）< 100 万L3，法务 + 部门总监
关键条款100 万 - 1000 万L4，法务 + 采购 VP + CFO
任何条款> 1000 万L4 + 董事会授权文件
合同终止 / 解除任意L4，必须附法律意见书

五、防绕过机制

单纯的阈值规则可以被拆单绕过，Policy Engine 设计了两类防绕过机制。

5.1 聚合窗口检测（防化整为零）

规则 AG-001：同受益方累计额度

滑动时间窗口：60 分钟 检测逻辑： IF 同一 operator 在窗口内 AND 向同一受益方（vendor_code 或 bank_account）的累计付款 > 100 万 CNY THEN 最新一笔升级到 L4 回溯冻结窗口内所有放行的同受益方付款 推送风控部门：疑似拆单告警

规则 AG-002：同类型操作频率

IF 同一 operator 在 30 分钟内发起 ≥ 5 次付款操作 THEN 触发人机验证，第 6 次操作必须经理在场确认 MSG "高频操作触发人工核验"

5.2 操作序列异常检测

规则 SEQ-001：超速操作识别

异常序列： query_vendor_account → modify_vendor_account → create_payment IF 以上序列完成时间 < 60 秒 THEN → L5（硬性拦截） REASON "操作速度异常，疑似自动化欺诈序列" ALERT 安全团队 + 冻结该 Agent 会话

规则 SEQ-002：非工作时间高额操作

IF 当前时间 NOT IN 工作时间（07:00-22:00 工作日） AND amount > 500,000 THEN 升一级处理（L3 → L4，L4 → L4 + 值班经理确认）

规则 SEQ-003：敏感字段变更后立即付款

IF 最近 10 分钟内发生 modify_bank_account(vendor_id=X) AND 当前操作 create_payment(vendor_id=X) THEN → L5（强制拦截） REASON "账户变更后立即付款是高风险欺诈模式"

六、审计记录设计

6.1 每条 Policy 裁决记录的强制字段

{"audit_id":"PE-20260814-00421","timestamp":"2026-08-14T14:23:05+08:00","agent_id":"procurement-agent-01","operator":"张三（工号 EMP-10892）","operation":"SAP_FI_CreatePaymentOrder","params_hash":"sha256:b8f3c...","risk_score":82,"risk_level":"L4","verdict":"REQUIRE_APPROVAL","rules_matched":["P-001","P-003"],"rules_evaluated":["P-001","P-002","P-003","P-004","P-005"],"llm_reasoning_hash":"sha256:a3f9c...","erp_called":false,"approval_task_id":"APPR-2026-0814-001","approved_by":"李四（财务经理，工号 EMP-00231）","approved_at":"2026-08-14T16:05:12+08:00","erp_called_at":"2026-08-14T16:06:00+08:00","erp_doc_number":"5100023456"}

6.2 审计记录的存储与防篡改

要求实现方式
不可篡改写入 ClickHouse 后追加区块链时间戳，禁用 DELETE/UPDATE
长期保留按监管要求保留 7 年（财务类），10 年（合同类）
实时可查支持按操作人 / 时间 / 业务对象 / 规则 / 裁决结果多维检索
操作回放可还原完整操作上下文，用于事后审查和监管核查
合规报告每季度自动生成 SOX / 内控合规报告，附异常统计

七、规则配置与运营

7.1 规则热更新机制

Policy Engine 的规则引擎与 LLM 完全解耦，规则可以热更新而无需重启平台：

规则管理员（风控/财务）通过配置界面修改规则 → 规则版本号 +1，写入 Rule Registry → Policy Engine 加载新版本规则（无停机） → 新规则仅对新发起的操作生效 → 旧版本规则决策记录永久保留，不被覆盖

7.2 规则灰度发布

新规则上线流程： Step 1 Shadow Mode：新规则与旧规则并行运行，只记录差异，不影响实际裁决 Step 2 小范围生效：对特定部门/角色先行启用 Step 3 全量生效：确认无误后对所有 Agent 生效 Step 4 回滚预案：发现误拦截 1 小时内可一键回滚到上一版本

7.3 规则效果监控指标

指标告警阈值含义
每日 L5 拒绝率> 0.5%可能存在规则误判或异常操作
审批通过后 ERP 失败率> 2%ERP 侧数据或规则不一致
平均审批等待时长> 4h审批链可能存在堵塞
聚合告警触发频率> 3次/天可能存在系统性拆单行为

八、落地检查清单

在将 Policy Engine 接入生产环境前，建议完成以下核查：

安全设计

  • 所有 ERP 写操作均已在 Tool Registry 中标注风险等级
  • P-002（账户核验）规则已与供应商主数据实时同步
  • L5 规则清单已经法务和风控联合确认
  • Agent 角色权限表已完成最小化裁剪

技术实现

  • Policy Engine 与 Action Bus 为同步调用，无异步绕过路径
  • 审批系统与 ERP 的集成已完成，非 Agent 直接调用
  • 聚合窗口检测所需的分布式计数器（Redis）已部署
  • Audit Logger 的区块链时间戳服务已接入

运营准备

  • 规则灰度发布流程已测试（含回滚）
  • 值班财务经理的审批推送渠道已配置
  • 首批规则已在 Shadow Mode 下运行 ≥2 周
  • 监控告警阈值已设定并接入 OnCall 系统

📎关联文档

  • 基于 Harness 架构的企业 ERP 智能体平台方案
  • X附件：Policy Rule 配置 Schema 规范
  • X附件：各 ERP 系统账户核验 API 接入文档

版本：v1.0 | 2026年8月 | 适用对象：安全架构师、风控团队、企业 CTO/CFO