一个 Skill 请求调用敏感操作（如转账），设计一套安全的确认与审计机制。

面试官：“当一个 Skill 想执行转账这种敏感操作时，你会怎么设计一套安全的确认与审计机制？”

候选人：

“转账是 Agent 系统里最高风险的操作之一，我的设计原则是：永远不信任单一环节，永远要求双重确认，永远留下不可篡改的审计痕迹。 我把它拆成四个阶段：预授权校验、显式用户确认、安全执行、事后审计追溯。

阶段一：预授权校验 —— 先看资格再看风险

Skill 本身不能直接触发转账，它只能向 Agent 核心发出一个“转账请求”。这个请求进入预授权校验流水线：

  1. 权限声明校验：检查该 Skill 的元信息里是否声明了 financial_transfer 权限。如果没有，直接拒绝并告警。

  2. 调用者身份验证：确认当前会话的用户是否已通过多因素认证（MFA）。如果用户只做了密码登录，还没通过指纹或动态令牌验证，Agent 必须先引导用户完成二次认证。

  3. 风控规则预检：将转账请求的参数（金额、收款方、时间）送入风控引擎。规则包括：

  4. 单笔金额是否超过用户设定的限额？
  5. 收款方是否在用户的历史白名单中？
  6. 当天累计转账是否超过阈值？

  7. 设备环境、地理位置是否异常？

  8. 依赖 Skill 输出完整性校验：如果转账金额是由上游 Skill 计算得来的（比如“差旅报销” Skill 算出的金额），编排引擎会要求该上游 Skill 的输出附带数字签名，确保金额未被中间 Skill 篡改。

任何一项不通过，请求就被拦截。

阶段二：显式用户确认 —— 让用户做最终决策

通过预授权后，Agent 不能替用户做决定，必须生成一个结构化确认请求推送给用户。这个确认请求不是简单的“是否确认转账”，而是一份完整的交易摘要：

⚠️ 转账确认

收款方：张三（招商银行 6225 **** 1234）
金额：¥ 12,800.00
用途：差旅报销
发起 Skill：报销审批助手 v1.3
预计到账时间：实时

[查看详情] [确认转账] [取消]

关键设计点：

  • 确认通道独立：确认请求通过 Agent 之外的第二通道发送（如 App 推送通知、短信验证码），防止当前对话被劫持后攻击者直接点“确认”。

  • 确认令牌一次性：每个确认请求生成唯一的 UUID 令牌，附带 60 秒有效期，且与用户 ID 和会话绑定。防止重放攻击。

  • 防误触设计：确认按钮点击后需要二次滑动或长按才能生效，避免误操作。

  • 大额交易升级审批：如果金额超过用户设定的“大额阈值”，除了本人确认外，还需要预设的审批人（如财务主管）在指定时间内通过系统完成联合审批。

用户确认后，客户端向 Agent 回传一个经过签名的确认令牌，Agent 验签通过后进入执行阶段。

阶段三：安全执行 —— 最小权限 + 防篡改

确认通过后，Agent 编排引擎并不直接操作用户账户，而是调用受严格限制的支付网关 Skill（一个内部系统级 Skill，非第三方）。

支付网关 Skill 的运行环境与普通 Skill 完全隔离：

  • 运行在独立的沙箱中，仅有访问银行接口的单一权限。

  • 接收的参数（金额、收款方）必须和用户确认过的摘要一致，重新生成哈希比对，不一致则拒绝。

  • 执行前再次验证用户账户状态、余额是否充足（防止时间窗口内余额变化）。

  • 执行结果（交易流水号、状态）不返回给请求 Skill，而是直接写入受保护的审计日志，并通过消息通道通知用户。

这一步的核心是：执行的权限和确认的权限彻底分离。 发起 Skill 只能“建议”转账，用户确认后由系统级 Skill 执行，发起 Skill 全程不接触支付密码、验证码和最终交易流水号。

阶段四：事后审计与异常追溯

每笔敏感操作都留下完整的审计链：

  • 审计日志：记录从 Skill 发起请求、预授权检查结果、用户确认时间与设备、执行结果的全链路事件。日志写入防篡改存储（如区块链日志或 append-only 数据库）。

  • 证据链绑定：将用户确认时的设备指纹、IP、生物特征记录、确认令牌、交易流水号做哈希串联，形成不可分割的证据链。事后任一环节被质疑，都能独立验证。

  • 实时监控告警：后台监控系统对以下异常实时告警：

  • 同一用户短时间内多次确认失败
  • 确认令牌被重复使用
  • 转账金额异常偏离用户历史均值

  • Skill 请求频率异常增高

  • 定期审计报告：每周自动生成用户敏感操作汇总报告，通过邮件或消息推送给用户，让用户自己核对。