用于关键基础设施中自主AI系统的去中心化细粒度访问控制

# 面向关键基础设施中自主AI系统的去中心化细粒度访问控制

来源：https://arxiv.org/html/2607.22611  
Arun Malik¹, Deepal Jayasinghe¹, Bradley Klemick¹, Prachi Shah¹, Nitish Talasu¹, Vineet Tushar Trivedi¹  

###### 摘要

在生产基础设施中部署自主AI代理带来了传统基于角色的访问控制（RBAC）模型无法解决的根本性安全挑战。与确定性自动化不同，AI代理表现出随机行为，这使得传统信任模型不足以管理其对关键系统的访问。本文提出一种专为在关键云基础设施中运行的自主AI系统设计的去中心化多层访问控制架构。我们的框架引入了四项关键创新：(1) 复合身份模型，将代理行为与委派的人类权威绑定；(2) 分级权限系统，涵盖从全局平台访问到每个参数约束的五个粒度级别；(3) 去中心化策略所有权模型，允许工具团队独立管理其授权边界；(4) 渐进式信任提升与安全互锁机制，防止自主代理执行高风险操作。我们将设计基于OWASP LLM应用Top 10 (2025) 威胁分类法，并展示每个架构决策如何缓解特定攻击向量。该系统已在管理数百个数据中心网络基础设施的主要云提供商的生产环境中部署，为20多个专业AI代理和60多个确定性剧本实施细粒度访问控制，每天处理数千次操作，并在八个月的生产部署中保持零未授权写入操作。我们提供了访问模式分布、拒绝率以及分层授权在防止非确定性行为者特权提升方面的有效性的实证数据。

## I. 引言

由大语言模型（LLM）驱动的代理在企业运营中的快速采纳带来了前所未有的安全挑战：如何为行为本质上非确定性的行为者授予生产系统访问权限。传统访问控制系统是为两类行为者设计的：通过身份提供者认证并做出有意识决策的人类，以及执行预定逻辑的自动化系统。AI代理并不完全属于任何一类。它们会推理、适应、产生幻觉，并可能通过对抗性提示被操纵。

在云网络运营等关键基础设施环境中，风险尤其高。单个配置错误的网络设备可能级联导致影响数百万用户的区域性中断。拥有过多权限的代理可能被提示注入，从而执行破坏性命令。而权限不足的代理则无法完成其运营任务。这种操作必要性与安全边界之间的张力正是本工作要解决的核心挑战。

现有的AI代理安全方法分为两大阵营。第一种将代理视为不可信的外部实体，将其限制在只读沙盒中，这限制了它们的运营价值。第二种则授予代理与其服务的人类相同的提升权限，这在代理出现故障或被攻破时会造成不可接受的爆炸半径。这两种方法在大规模应用中均不可行。

本文提出第三条道路：一种去中心化的细粒度访问控制架构，为AI代理提供精细、上下文感知的授权，同时保持关键基础设施所需的安全保证。我们的系统已生产部署八个月，管理着在数百个数据中心运行的20多个专业代理的访问权限，在零未授权写入操作的情况下，使代理能够自主解决1400多个运营任务。

### I-A 贡献

本文做出以下贡献：

- **复合身份模型**：一种新颖的身份绑定机制，将人类权威委派给AI代理，同时保持问责制和审计追踪。
- **五层权限层级**：多粒度授权框架，涵盖平台、工具、函数、参数和执行上下文级别。
- **去中心化策略所有权**：基于Git的治理模型，基础设施工具团队为其服务独立定义、审查和批准访问策略。
- **渐进式信任提升**：一种安全分层方法，写入操作需要越来越严格的授权，最终高风险操作需要多方批准。
- **实证评估**：生产部署数据，展示该架构的安全有效性和运营影响。

## II. 威胁模型与问题陈述

### II-A 非确定性问题

传统自动化系统（工作流引擎、CI/CD流水线、定时任务）通过一个直接的信任模型获得生产访问权限：它们的行为是确定性的、可审查且受限的。给定相同输入，它们产生相同输出。其源代码可被审计。其执行路径可被穷举测试。

AI代理违反了此模型中的每一个假设：

- **随机行为**：给定相同输入，由于温度采样、上下文窗口变化或模型更新，LLM驱动的代理可能采取不同行动。
- **提示漏洞**：代理可能通过其处理数据中嵌入的对抗性输入（间接提示注入）被操纵。
- **能力放大**：代理的有效能力是其工具访问权限和推理能力的乘积，使得权限边界更难预测。
- **涌现行为**：多代理系统可能表现出单个代理策略无法预见的集体行为。

参照图标题图1：确定性自动化与随机AI代理在五个安全维度上的信任模型比较。我们的框架（蓝色）恢复了确定性系统大部分信任属性。

### II-B OWASP LLM应用威胁

我们将威胁模型建立在OWASP LLM应用Top 10 (2025) [1](https://arxiv.org/html/2607.22611#bib.bib1)之上，重点关注与关键基础设施中基于代理的系统最相关的威胁（表I(https://arxiv.org/html/2607.22611#S2.T1)）。

表 I: OWASP LLM威胁及针对代理的缓解措施。

### II-C 行为者分类

我们的架构区分四种不同的行为者类型，每种具有不同的信任属性和授权要求（图2(https://arxiv.org/html/2607.22611#S2.F2)）。

参照图标题图2：行为者分类，显示系统中每种行为者类型的信任级别、确定性和授权复杂性。

表 II: 行为者类型及其信任属性。**剧本**代表与AI代理和传统服务都不同的第四种关键行为者类别。剧本是一种**确定性、预先编写的流程**，由离散步骤组成，按固定顺序执行基础设施操作。与动态推理工具选择和参数的AI代理不同，剧本遵循在部署前经过代码审查、测试和批准的作者逻辑。这种确定性赋予剧本更高的信任级别：它们可能持有代理无法直接获得的限定写入权限。在我们的架构中，识别出补救措施的AI代理将执行委托给适当的剧本，而不是自主执行写入，从而创建一条**代理到剧本的提升路径**，既保留代理的分析能力，也保留剧本的安全保证。

## III. 架构

### III-A 设计原则

六项核心安全原则指导该架构：

1. **最小权限**：每个行为者获得其功能所需的最小权限。代理默认为只读访问。
2. **零信任**：不基于网络位置或先前行为进行隐式信任。每个请求都经过认证、授权和审计[4](https://arxiv.org/html/2607.22611#bib.bib4)。
3. **过度代理守卫 (OWASP LLM06)**：通过工具范围和参数级拒绝模式，明确防止代理积累超出其定义范围的能力。
4. **委派身份**：代理从不以独立权威运行。它们的行动与委派人类的身份和权限绑定。
5. **可观测性与审计**：每个代理行动都产生不可变的审计追踪，将该行动与代理及其委派权威相关联。
6. **环境隔离**：生产环境与企业环境保持严格分离，具有独立的凭证系统。

### III-B 五层权限层级

授权决策遍历五个不同的层级，每个层级逐步缩小允许行动的范围（图3(https://arxiv.org/html/2607.22611#S3.F3)）：

参照图标题图3：五层权限层级，显示逐步的范围缩小。每层减少行为者可用的有效权限集。

表 III: 五层权限层级。

### III-C 复合身份模型

复合身份模型是我们代理授权方法的基石。代理操作不携带具有固定权限的独立凭证，而是携带一个复合身份，将以下内容绑定在一起：

- **用户令牌 (OBO)**：来自发起或委托给代理的人类的“代表”令牌，建立问责制并确定权限上限。
- **代理托管身份**：代理服务本身的系统分配身份，实现平台级访问控制和审计归属。
- **执行上下文**：元数据，包括触发事件、剧本标识符和时间约束。

此复合身份确保代理永远不能超过其委派人类的权限，同时也通过代理特定策略独立约束（图4(https://arxiv.org/html/2607.22611#S3.F4)）。

参照图标题图4：复合身份解析：有效访问权限计算为用户权限、代理角色边界和执行上下文约束的交集。

### III-D 去中心化策略所有权

一个关键的架构创新是将策略定义去中心化到工具拥有团队。与其维护一个集中的访问控制配置，每个基础设施服务团队在版本控制仓库中拥有其授权策略的YAML文件：

清单1: 去中心化工具策略定义。

```yaml
toolName: TopologyService
owner: [email protected]
roles:
  Topology-Reader:
    description: "只读拓扑查询"
    permissions:
      functions:
        - "Topology-GetDeviceInfo"
        - "Topology-QueryGraph"
  Topology-Writer:
    inherits: Topology-Reader
    permissions:
      functions:
        - "Topology-UpdateConfig"
      parameters:
        environment:
          denyPattern: "prod-.*"
```

这种去中心化模型提供了几个关键属性：

- **所有权清晰**：每个工具团队确切知道他们授予了什么访问权限以及授予了谁。
- **独立演化**：团队可以修改权限而无需与中央平台团队协调。
- **基于Git的治理**：所有策略更改通过拉取请求进行，需要审查者批准，提供完整审计历史。
- **热重载**：策略更改在合并后立即生效，无需服务重启。

参照图标题图5：集中式与去中心化策略管理对比，显示六个月内更改时间、审查准确性和策略冲突情况。

### III-E 渐进式信任提升

关键基础设施中的写入操作需要基于风险评估的逐步授权级别（表IV(https://arxiv.org/html/2607.22611#S3.T4)）：

表 IV: 渐进式信任提升层级。关键在于，AI代理被结构性排除在启动多方批准工作流之外。这一设计决策反映了一个基本安全原则：无论非确定性行为者的功能正确性历史如何，都应永远无法自我授权高风险操作。

### III-F 访问控制矩阵

表V(https://arxiv.org/html/2607.22611#S3.T5)呈现了生产中管理所有行为者-服务交互的完整访问控制矩阵。

表 V: 生产访问控制矩阵：行为者类型 vs. 服务类别。图例：R=读取，W=写入。STS MI=具有托管标识的安全令牌服务。AME/SAW=Azure托管环境/安全管理员工作站。JIT=即时提升。OBO=代表委托。*=受每个工具的RBAC及OWNERS.txt治理约束。

该矩阵揭示了一个关键不对称性：虽然确定性工作流引擎继承了其服务身份的完整访问面，但非确定性AI代理在操作向更高影响服务层级移动时面临渐进式限制。

## IV. 实现

### IV-A 运行时授权引擎

授权引擎实时评估每次工具调用，针对五层层级结构。评估过程遵循先否定模型：

1. 验证复合身份（用户令牌新鲜度、代理MI有效性）
2. 检查全局RBAC成员身份（安全组验证）
3. 解析工具级权限（此工具对此角色可访问吗？）
4. 评估函数级访问（此具体操作是否允许？）
5. 应用参数级约束（输入值是否匹配拒绝/允许模式？）
6. 验证执行上下文（剧本范围、事件关联、时间窗口）

任何层都可拒绝请求。引擎返回最具体的拒绝原因以帮助调试，同时不泄露更广泛权限结构的信息。

### IV-B 代理特定安全控制

除了RBAC框架，代理还受到额外的运行时控制：

- **工具范围**：每个代理声明明确枚举其允许的工具集。未列出的工具对代理的LLM上下文不可见。
- **权限边界**：最大权限集，无论角色继承如何，都不可超过。
- **人机回环门**：可配置的检查点，代理执行暂停等待人工审核。
- **速率限制**：每个代理、每个工具的操作配额，防止失控执行。
- **输出验证**：执行后验证代理行动是否符合预期模式，然后才提交更改。

### IV-C 自带角色 (BYOR)

入职团队创建跨多个工具的自定义角色，针对其运营场景量身定制：

清单2: 自定义跨工具角色定义。

```yaml
NetOps-DRI:
  description: "网络运营DRI角色"
  addedBy: [email protected]
  toolPermissions:
    TopologyService:
      inherits: Topology-Reader
      extra: ["Topology-GetInterfaceStatus"]
      parameters:
        datacenterName:
          allowPattern: "^(dc1|dc2|dc3)-.*$"
    DeviceProxy:
      role: DeviceProxy-Viewer
    WorkflowEngine:
      role: Workflow-Reader
```

### IV-D 身份绑定与分配

自定义角色通过灵活的分配机制绑定到身份，支持多种身份类型：

清单3: 角色分配给多种身份类型。

```yaml
roleAssignments:
  NetOps-DRI:
    assignedTo:
      - type: securityGroup
        id: "sg-netops-dri"
      - type: managedIdentity
        id: "mi-netops-agent"
      - type: agent
        id: "netops-dri-agent"
      - type: playbook
        id: "incident-netops-*"
```

## V. 评估

### V-A 部署上下文

该系统已生产部署八个月，管理着以下规模的AI代理集群的访问权限：

- 20多个专业AI代理，具有不同的运营任务
- 60多个系统剧本