1. 从“失控”到“可控”为什么我们需要一个授权框架最近和几个做AI应用的朋友聊天大家不约而同地提到了同一个痛点AI智能体Agent的权限管理快成“玄学”了。一个负责处理客户邮件的Agent理论上只需要读取邮件和调用日历API但你怎么确保它不会“一时兴起”去访问公司的财务数据库一个被授权可以调用外部天气API的Agent你怎么防止它被恶意诱导去反复调用一个收费高昂的、本不该它接触的付费服务造成“账单爆炸”更复杂的是当多个Agent需要协作完成一个任务时比如一个Agent负责分析需求一个Agent负责调用工具执行权限该如何在它们之间安全、可控地传递这种“我授权给你你再授权给他”的链条一旦失控后果不堪设想。这背后暴露的正是当前AI系统特别是走向“智能体化”Agentic的AI系统在治理Governance和授权Authorization层面的巨大空白。传统的权限模型无论是简单的角色访问控制RBAC还是更细粒度的属性访问控制ABAC在面对动态、自主、且可能进行复杂工具调用的AI智能体时都显得力不从心。它们大多是静态的、围绕“人”设计的而AI智能体的行为是程序驱动的、上下文相关的并且可能涉及多层级的任务分解与委派Delegation。“Overlaying Governance: A Compositional Authorization Framework for Delegation and Scope in Agentic AI”这个标题精准地戳中了这个行业痛点。它提出了一个愿景不是推翻重来而是在现有的应用和智能体之上“叠加”Overlaying一层治理层。这个治理层的核心是一个“可组合的”Compositional授权框架。可组合意味着授权策略可以像乐高积木一样根据具体的任务、上下文和风险等级进行灵活组装和嵌套。它要解决两个关键问题委派Delegation和作用域Scope。委派解决的是“权限如何安全传递”作用域解决的是“权限的边界在哪里”。本文将深入拆解这个框架背后的核心思想、技术实现路径以及我们如何在实际的AI应用开发中借鉴这些理念来构建自己的“安全护栏”。2. 核心概念拆解叠加、组合、委派与作用域在深入技术细节之前我们必须先厘清标题中几个关键术语的确切含义。它们共同构成了这个授权框架的理论基石。2.1 治理的“叠加”Overlaying Governance“叠加”是一种架构哲学。它不主张将权限控制逻辑深埋在每一个AI智能体或应用程序的业务代码中——那样会导致代码臃肿、策略分散、难以统一审计和更新。相反它倡导建立一个独立的、透明的治理层。这个层像一张滤网或一个看门人横亘在AI智能体与它所要访问的资源数据、API、工具之间。所有的访问请求都必须经过这一层。这一层不关心智能体内部复杂的推理过程它只关心一个原子问题“在当前的上下文下这个智能体以其当前身份请求执行这个操作Action于这个资源Resource是否被允许” 这种关注点分离Separation of Concerns的设计使得安全策略可以独立于业务逻辑进行开发、测试、部署和迭代。你可以随时调整“滤网”的密度而无需重写智能体的核心代码。2.2 授权的“可组合性”Compositional Authorization这是框架灵活性的核心。传统的权限模型往往是“一刀切”或基于简单布尔逻辑AND/OR。可组合授权则将策略视为可以动态组合的“策略单元”。基础策略单元可以是最简单的规则如“智能体A可以读取资源R”。逻辑组合通过逻辑运算符与、或、非组合基础单元形成复杂策略。例如“智能体A是客服角色 AND 当前时间为工作时间OR 智能体A是系统管理员”可以访问工单系统。上下文组合策略的有效性可以绑定到动态上下文。例如“智能体可以调用支付API”这个策略只有在“当前会话用户已通过双重认证”且“交易金额小于1000元”这个上下文组合成立时才生效。层次化组合策略可以继承和覆盖。一个项目级的默认策略可以被某个特定任务下的更严格策略所覆盖。这种组合性允许开发者用声明式的方式像编写配置文件一样精细地描绘出不同场景下的权限边界极大地提升了策略的表达能力和可维护性。2.3 委派Delegation权限的安全流转链条委派是智能体协作场景下的刚需。用户授权给主智能体主智能体可能需要将部分任务及相应权限委派给子智能体或专门工具。框架必须能清晰地刻画和约束这条委派链。委派凭证权限的传递不能是隐式的必须通过显式的、可验证的凭证如一个签名的令牌。这个凭证应包含原始授权者、被委派者、被委派的权限范围、有效期以及可能的使用次数限制。衰减原则一个核心安全原则是被委派者的权限不应超过委派者自身的权限。即权限在传递过程中只能保持不变或缩减绝不能扩大。如果主智能体只有“读取”权限它绝不能委派出一个“写入”权限。溯源与审计治理层必须能够完整记录委派链。当发生越权访问时可以清晰地追溯是哪个环节的委派出了问题是凭证泄露、策略配置错误还是智能体行为异常。2.4 作用域Scope为权限装上“定位器”和“围栏”作用域是限制权限生效范围的关键机制。它回答了“权限在哪里有效”和“权限能干什么”的问题。资源作用域限定权限针对的具体资源。不仅是资源类型如“数据库表”更是资源实例如“仅限id123的用户记录”。对于AI工具调用作用域可以细化到具体的API端点、参数取值范围如“查询天气仅限北京、上海”。时间作用域权限的有效期。例如一个处理临时任务的智能体其权限可能只在未来10分钟内有效。操作作用域限定允许的操作类型。对于数据库可能是CRUD创建、读取、更新、删除的细分对于API可能是GET、POST等HTTP方法。上下文作用域绑定到动态环境。例如“仅在用户会话来自公司内网IP时允许访问”、“当系统负载低于70%时才允许启动资源密集型分析任务”。通过作用域我们可以实现“最小权限原则”确保每个智能体在任何时刻都只拥有完成其当前任务所必需的最少权限极大压缩了攻击面。3. 框架架构设计一个可落地的系统蓝图理论需要工程化落地。一个叠加式的、可组合的授权框架其系统架构通常可以分为以下几个核心层次我们可以参考业界在零信任、API网关和策略即代码领域的实践。3.1 策略决策点与策略执行点这是经典策略引擎模式在AI治理层的应用。策略执行点PEP这是治理层的“前线哨所”。它被嵌入到AI智能体与资源之间的所有关键通路上。例如它可以是一个独立的微服务也可以是集成在API网关、数据库代理或工具调用SDK中的模块。当智能体发起请求时PEP会拦截该请求收集所有相关信息谁、在什么上下文、想对什么资源、做什么操作并将其格式化后发送给策略决策点进行裁决。策略决策点PDP这是治理层的“大脑”或“法官”。它接收来自PEP的查询加载当前生效的、可组合的授权策略结合动态上下文来自策略信息点进行计算最终做出“允许”或“拒绝”的决策并将决策结果有时还包括附加义务如“必须记录日志”返回给PEP。策略信息点PIP为PDP决策提供所需的一切上下文信息。它可能连接着用户目录、设备管理库、实时风险分析系统等用于获取“当前用户是否在多因素认证状态”、“请求来源IP的地理位置”等信息。策略管理点PAP这是策略的“编辑台”。管理员通过PAP以声明式语言如Rego、Cedar或自定义DSL编写、测试、发布和版本化管理可组合的授权策略。这种分离架构确保了策略逻辑的集中化、一致性和高性能。PEP可以轻量且遍布各处而复杂的策略计算由统一的PDP承担。3.2 策略语言与声明式模型框架的表现力很大程度上取决于其策略语言。对于可组合的授权策略语言需要支持声明式语法描述“是什么”What is allowed而非“如何检查”How to check。这使得策略更易于理解、审计和推理。第一等公民的“组合”语言原生支持策略的逻辑组合、模块化和继承。例如可以定义一个基础模块base_policy然后通过import和override来创建针对不同场景的变体。丰富的上下文感知能够方便地引用和判断来自PIP的动态属性。对“委派”的原生支持语言中应有结构来表示和验证委派链。例如可以定义一个delegated_chain字段要求其长度不超过3且每一环的签名有效。开源策略引擎如OPAOpen Policy Agent及其策略语言Rego或AWS开源的Cedar都在向这个方向演进是构建此类框架的优秀基础选型。它们都强调声明式、可组合和上下文感知。3.3 智能体身份与凭证管理AI智能体不能是“匿名用户”。每个智能体在系统中都必须有一个明确的、可验证的身份。这个身份通常与一个服务主体或动态角色绑定。身份供应在智能体启动时由可信的编排器或身份服务为其颁发一个初始身份凭证如JWT令牌或SPIFFE ID。这个凭证包含了智能体的唯一标识符和其初始角色/属性。凭证传递与委派当智能体A需要委派任务给智能体B时它不能直接把自己的凭证给B。而是应向一个可信的令牌交换服务发起请求该服务会根据A的凭证、目标B的身份以及预定义的委派策略为B生成一个具有特定作用域的新凭证。这个新凭证的“签发者”可以记录为A从而实现溯源。凭证生命周期管理智能体凭证必须有短暂的有效期如几分钟到几小时并支持吊销。这对于遏制凭证泄露造成的损害至关重要。4. 实战推演构建一个安全的AI客服工单处理流程让我们通过一个具体的场景来看看这个框架如何运作。假设我们有一个AI客服系统包含以下智能体主控智能体Orchestrator接收用户工单分析内容决定路由。信息查询智能体Retriever被授权查询知识库和用户历史记录。操作执行智能体Executor被授权在CRM系统中创建后续任务或修改工单状态。目标用户提交一个工单“我的订单#1001物流停滞了请帮忙催单”。主控智能体需要协调Retriever和Executor来完成这个任务同时确保整个流程符合安全策略Retriever只能读取该用户和订单#1001的相关信息Executor只能在CRM中为订单#1001创建一条“催单”任务而不能修改其他订单或执行其他操作。4.1 策略定义使用类Rego语法示例首先我们在策略管理点定义可组合的策略。# 基础策略模块定义资源和操作 package agentic.authz import future.keywords.in # 资源定义 resources : { knowledge_base: {actions: [query]}, user_history: {actions: [read]}, crm_ticket: {actions: [read, create_followup]} } # 默认拒绝一切 default allow : false # 规则1Retriever智能体可以查询知识库和读取用户历史需上下文限制 allow { input.principal agent:retriever input.action in resources[input.resource_type].actions input.resource_type in [knowledge_base, user_history] # 上下文限制资源ID必须匹配工单中的订单号 input.context.order_id input.resource_id } # 规则2Executor智能体可以为工单创建后续任务 allow { input.principal agent:executor input.action create_followup input.resource_type crm_ticket # 上下文限制只能操作该工单对应的CRM工单ID input.context.ticket_id input.resource_id } # 规则3委派链验证 - 确保委派深度不超过2且权限未扩大 valid_delegation { count(input.delegation_chain) 2 # 检查链中每一步的权限范围是否在衰减此处简化为例 # 实际中需更复杂的逻辑对比scope }4.2 流程中的授权交互用户发起请求用户通过前端与主控智能体交互主控智能体获得一个代表该用户的、有局限性的令牌Scope处理订单#1001相关工单。主控智能体委派查询主控智能体需要查询订单#1001的物流信息。它不能直接让Retriever用自己的令牌。于是它向令牌交换服务发起请求携带自己的令牌和请求{“target_agent”: “retriever”, “scope”: {“resource”: “user_history”, “id”: “order_1001”, “action”: “read”}}。令牌交换服务决策该服务内部的PDP会评估主控智能体的令牌是否有效且包含对订单#1001的权限是请求的委派user_history.readonorder_1001是否在主控智能体权限范围内是因为主控有处理该订单的权限读取历史是子集是否符合valid_delegation等全局策略是 评估通过后为Retriever生成一个短期、窄范围的令牌。Retriever执行查询Retriever拿着新令牌去访问用户历史数据库。数据库前的PEP拦截请求将{principal: “agent:retriever”, action: “read”, resource_type: “user_history”, resource_id: “order_1001”, context: {order_id: “1001”}, delegation_chain: […]}发送给中央PDP。PDP根据上述策略规则1和规则3计算返回allow: true。查询得以执行。主控智能体委派执行获取信息后主控智能体决定创建催单任务。它再次向令牌交换服务请求为Executor生成令牌{“target_agent”: “executor”, “scope”: {“resource”: “crm_ticket”, “id”: “ticket_5678”, “action”: “create_followup”, “params”: {“type”: “urge_delivery”}}}。Executor创建任务Executor用其令牌调用CRM API。API网关处的PEP拦截PDP根据规则2和规则3评估后放行。任务创建成功。整个过程中主控智能体从未直接接触用户历史数据库或CRM系统Retriever和Executor也仅拥有完成其特定子任务所必需的最小权限。所有决策由中央策略引擎统一做出全程可审计。5. 实施挑战与关键考量将这样一个框架落地到生产环境会面临一系列工程和组织上的挑战。5.1 性能与延迟每一次智能体的工具调用都可能触发一次远程的策略决策这对于低延迟要求的应用如实时对话Agent可能是不可接受的。解决方案本地PDP缓存在智能体运行环境或PEP本地部署轻量级PDP缓存常用的策略决策结果。可以设置合理的TTL并在策略更新时广播失效通知。批量预授权对于已知的任务流程可以在任务开始时由编排器一次性为整个流程可能需要的所有权限进行预授权和令牌颁发减少过程中的决策次数。但这需要精确预测任务路径否则会扩大权限范围。策略编译与优化将声明式策略预先编译成高性能的、可嵌入的决策代码如Wasm模块直接在PEP处执行消除网络往返。5.2 策略的复杂性与正确性可组合性带来了灵活性的同时也带来了策略冲突和推理复杂度的提升。当数十上百条策略组合在一起时如何确保没有逻辑漏洞或意外允许的访问解决方案策略测试与验证建立完善的策略测试套件模拟各种访问场景和边缘案例确保策略行为符合预期。可以利用策略引擎提供的单元测试框架。形式化验证对于核心安全策略探索使用形式化方法验证其属性例如“确保任何情况下智能体X都不能访问资源Y”。变更管理与同行评审将策略代码化并纳入标准的软件开发生命周期进行代码审查、CI/CD流水线测试确保变更受控。5.3 动态上下文的管理策略的决策严重依赖于上下文用户位置、设备状态、时间、系统负载等。这些上下文信息需要被实时、可靠地收集并传递给PDP。解决方案建立统一的上下文服务构建一个低延迟、高可用的服务聚合来自各方的属性信息并为PIP提供统一的查询接口。上下文信息的可信度需要考虑上下文信息的来源是否可信是否需要签名验证。例如一个来自智能体自身声明的“用户已认证”属性可能不可信而来自独立认证服务的声明才可信。处理上下文缺失定义清晰的策略规定当关键上下文信息暂时无法获取时是默认拒绝安全优先还是采用降级策略。5.4 与现有系统的集成大多数企业已有成熟的IAM身份与访问管理系统。新的AI治理层不应成为又一个孤岛。解决方案充当适配层授权框架的PIP可以集成现有IAM将企业中的用户、角色、组属性拉取过来作为决策上下文的一部分。同步与映射将AI智能体的身份与服务主体Service Principal或动态角色映射到企业IAM体系中实现统一的身份生命周期管理。审计日志聚合将授权框架的审计日志推送至企业统一的SIEM安全信息与事件管理系统实现全景式的安全监控。6. 从理念到实践启动你的第一个AI授权原型如果你正在构建或规划一个涉及AI智能体的项目并希望引入系统的授权治理我建议采用“渐进式”路径而非“大爆炸”式地重构一切。第一步定义你的“皇冠宝石”与最危险操作不要一开始就试图管理所有权限。找出你的AI系统中最敏感的数据客户PII、支付信息和最危险的操作删除数据、发起交易、调用昂贵API。优先为这些场景设计授权策略。这能让你用最小代价获得最大安全收益。第二步选择一个策略引擎并深入理解我个人推荐从OPAOpen Policy Agent开始。它云原生、生态成熟、语言Rego功能强大且专为策略设计。花几天时间在 playground.openpolicyagent.org 上尝试编写策略理解其“输入-查询-输出”模型。关键要掌握如何用Rego表达“可组合性”例如通过定义规则和函数来模块化策略。第三步实现一个最简单的PEP-PDP交互选择一个你智能体最常用的工具调用比如访问一个内部API。在调用这个API的代码前后插入一个PEP逻辑。这个PEP可以简单地调用一个你本地运行的OPA服务PDP。最初策略可以很简单比如“只允许来自特定IP的智能体调用”。目标是打通整个决策链路验证从拦截请求、收集属性、发送查询到执行决策的整个流程。第四步引入身份和委派为你的智能体创建简单的JWT令牌作为身份凭证。然后尝试实现一个最基础的“令牌交换”原型。让智能体A在调用工具前先向一个简单的交换服务内部可以是另一个OPA策略申请一个用于调用特定API的派生令牌再将这个令牌传递给工具调用SDK。这一步是理解委派和安全边界的关键。第五步迭代与扩展在核心链路跑通后你可以开始将更多资源和操作纳入管理。编写更复杂的、基于上下文的组合策略。将PEP集成到API网关、服务网格或数据库代理中。建立策略的版本控制和回滚机制。在整个过程中最深的体会是授权框架的构建与其说是一个技术项目不如说是一个梳理和澄清业务规则与安全边界的过程。你需要和业务、产品、安全团队不断沟通将模糊的“这个Agent大概可以做什么”转化为精确的、可执行的策略声明。这个过程本身就是对AI系统风险的一次彻底盘点价值巨大。最后记住安全是一个持续的过程而不是一个一劳永逸的状态。你的授权框架需要随着智能体能力的演进、业务场景的复杂化和威胁模型的变化而不断迭代。但有了这样一个可组合、可叠加的治理基础你就拥有了应对未来复杂性的核心武器。