Agent 自主决策的安全边界：权限分级、用户确认与操作审计

一、Agent 自主性带来的双重属性

Agent 的价值在于自主决策——用户说"帮我整理本周的会议纪要"，Agent 自行完成搜索日历、提取邮件、调用 AI 摘要、生成文档这一系列操作。但这种自主性也是最大的风险来源。如果 Agent 将"整理会议纪要"误解为"删除本周所有日历事件"，损失将是灾难性的。

Agent 安全的核心不是"阻止 Agent 做任何事"，而是"区分哪些操作 Agent 可以自主执行，哪些必须经过用户确认"。一个安全的 Agent 系统需要明确的三条线：自主线（Agent 自行决定）、确认线（Agent 提议，用户确认）、禁止线（Agent 无权提议）。

二、操作权限的三级模型

graph TB
    subgraph 自主操作区
        A1[读取日历事件]
        A2[搜索邮件主题]
        A3[调用AI生成摘要]
        A4[读取文件内容]
    end

    subgraph 确认操作区
        B1[创建日历事件]
        B2[发送邮件]
        B3[修改共享文档]
        B4[调用外部API]
    end

    subgraph 禁止操作区
        C1[删除日历事件]
        C2[更改账户设置]
        C3[执行支付操作]
        C4[访问密码/密钥]
    end

    AGENT[Agent 决策] --> A1
    AGENT --> B1
    AGENT -.->|阻断| C1

    A1 --> EXEC[自动执行]
    B1 --> CONFIRM{用户确认?}
    CONFIRM -->|是| EXEC
    CONFIRM -->|否| ABORT[取消操作]

自主操作区：只读操作 + 无副作用的生成操作。确认操作区：有副作用的操作，需要用户审查和批准。禁止操作区：不可逆的危险操作，Agent 不应有提议的权限。

三、权限执行框架的实现

// Agent 操作的权限分级管理
// 设计意图：每个操作声明自己的风险等级
// Agent 执行前由权限引擎检查等级并决定流程

enum RiskLevel {
  SAFE = 'safe',           // 自主执行：只读 + 无副作用
  REQUIRES_CONFIRM = 'confirm',  // 需确认：有副作用
  FORBIDDEN = 'forbidden', // 禁止：不可逆操作
}

interface AgentAction {
  id: string;
  name: string;
  riskLevel: RiskLevel;
  // 用户可见的描述——用于确认界面
  description: string;
  // 当前操作涉及的数据摘要
  affectedResources?: string[];
}

class AgentPermissionEngine {
  // 操作注册表——每个操作的风险等级
  private actionRegistry: Map<string, RiskLevel> = new Map([
    ['read_calendar', RiskLevel.SAFE],
    ['search_emails', RiskLevel.SAFE],
    ['generate_summary', RiskLevel.SAFE],
    ['create_calendar_event', RiskLevel.REQUIRES_CONFIRM],
    ['send_email', RiskLevel.REQUIRES_CONFIRM],
    ['modify_document', RiskLevel.REQUIRES_CONFIRM],
    ['delete_calendar_event', RiskLevel.FORBIDDEN],
    ['change_account_settings', RiskLevel.FORBIDDEN],
    ['execute_payment', RiskLevel.FORBIDDEN],
    ['access_credentials', RiskLevel.FORBIDDEN],
  ]);

  // 检查操作是否需要确认
  needsConfirmation(action: AgentAction): boolean {
    const riskLevel = this.actionRegistry.get(action.id);
    
    if (!riskLevel) {
      // 未知操作——安全起见，默认禁止
      console.warn(`未知操作 ${action.id}，默认禁止`);
      return true;
    }

    switch (riskLevel) {
      case RiskLevel.SAFE:
        return false;
      case RiskLevel.REQUIRES_CONFIRM:
        return true;
      case RiskLevel.FORBIDDEN:
        throw new Error(
          `操作 ${action.id} 被禁止执行 (risk: ${riskLevel})`
        );
    }
  }

  // 批量操作检查——同一批次中所有 SAFE 操作可自动执行
  // 但只要有一个 REQUIRES_CONFIRM，整批操作都暂停等待确认
  async evaluateBatch(
    actions: AgentAction[],
  ): Promise<{
    autoActions: AgentAction[];
    confirmActions: AgentAction[];
  }> {
    const autoActions: AgentAction[] = [];
    const confirmActions: AgentAction[] = [];

    for (const action of actions) {
      const riskLevel = this.actionRegistry.get(action.id);

      switch (riskLevel) {
        case RiskLevel.SAFE:
          autoActions.push(action);
          break;
        case RiskLevel.REQUIRES_CONFIRM:
          confirmActions.push(action);
          break;
        case RiskLevel.FORBIDDEN:
          // 记录安全审计日志
          this.auditLog(action, 'BLOCKED');
          // 不抛出异常——阻止该操作但继续评估其他操作
          console.error(`禁止操作已阻止: ${action.id}`);
          break;
        default:
          confirmActions.push(action); // 未知操作按需确认
      }
    }

    return { autoActions, confirmActions };
  }

  // 安全审计日志——所有操作都留痕
  private auditLog(
    action: AgentAction,
    result: 'AUTO_EXECUTED' | 'CONFIRMED' | 'BLOCKED',
  ): void {
    const logEntry = {
      timestamp: new Date().toISOString(),
      actionId: action.id,
      actionName: action.name,
      riskLevel: this.actionRegistry.get(action.id),
      result,
      affectedResources: action.affectedResources || [],
    };
    // 写入审计日志（数据库/文件）
    console.log('[AUDIT]', JSON.stringify(logEntry));
  }
}

三个设计要点：

1. 操作注册表集中管理风险等级——新增操作时必须显式声明风险；
2. 未知操作默认需确认——安全起见，不假设任何未注册操作的安全；
3. 审计日志全量记录——所有操作（包括阻止的）都留痕。

四、确认界面的用户体验设计

批量确认而非逐个确认。如果 Agent 需要执行 5 个确认级操作，不应弹出 5 个确认框。应展示一个汇总卡片——列出所有待确认操作的清单，用户一次点击确认全部。

确认疲劳的预防。如果 Agent 频繁请求"确认发送邮件"，用户会养成无脑点击"确认"的习惯。可以在首次确认时提供"本次会话中自动确认同类操作"的选项。

上下文信息的展示。确认界面应展示操作的目的和上下文——"为了生成本周会议纪要，Agent 需要创建 3 个日历事件"，而非仅仅"确认创建日历事件×3"。

五、总结

Agent 自主决策的安全边界设计：

1. 三级权限模型——自主执行（只读）、需确认（有副作用）、禁止（不可逆）；
2. 操作注册表集中管理风险等级；
3. 审计日志全量记录——所有操作可追溯；
4. 批量确认减少用户操作负担。

落地建议：

1. 梳理 Agent 所有可能执行的操作，按风险等级分类；
2. 实现操作注册表和批量确认界面；
3. 审计日志保留至少 90 天，用于安全事故排查；
4. 定期审查操作的风险等级——随着业务变化，某些操作的风险可能降低。