Agent IAM 系列（二）：Agent 有权限，不代表它该这么做

这是「Agent IAM 系列」第二篇。上一篇讨论的是：为什么 Agent 不能再被当作普通服务账号，企业 IAM 需要先把 Agent 当成一种新的自治非人类身份来治理。本文继续往前走一步，讨论一个更细的问题：即使 Agent 拥有合法身份和合法权限，也不代表它此刻就该这么做。Agent IAM 正在从“权限控制”走向“目的治理”。

上一篇我们讲到，Agent 不能再被当成普通服务账号。

传统服务账号只是一个技术入口，Agent 则更像一个会行动的数字角色。

它会理解任务、拆解步骤、调用工具、访问数据、委派子 Agent，甚至在不同系统之间连续执行动作。

所以企业 IAM 必须先承认 Agent 是一种新的自治非人类身份，并把它纳入完整的身份生命周期治理。

但做到这一步，还不够。

因为 Agent 有了合法身份，也拿到了合法权限，仍然可能做出不该做的事。

问题不一定出在“它有没有权限”，而可能出在“它为什么使用这个权限”。

2026 年 5 月，Angelika Steinacker 和 Hari Hayagreevan 又发布了一篇后续文章《Purpose and Intent: Two Governance Dimensions for Agent-Aware IAM》。

https://zenodo.org/records/20210494

这篇文章延续前一篇 Agent-Aware IAM Framework 的讨论，进一步提出两个治理维度：Purpose 和 Intent。

文章认为，Purpose 是 Agent 数字身份中声明的、受生命周期治理的属性；Intent 则是运行时从当前任务、提示词、工具调用和行为中推断出的会话级信号。

两者如果混在一起，就无法处理语义权限提升、任务漂移和反复提示改写任务边界等问题。

这篇文章真正想说的是：Agent 时代，IAM 不能只回答“谁能访问什么”，还要回答“它为什么访问，以及当前到底想干什么”。

权限通过了，治理也可能失败

传统 IAM 的核心逻辑，是判断一个身份能否访问一个资源。

员工是否属于某个角色，服务账号是否绑定某个策略，应用是否具备调用某个 API 的权限，数据库是否允许某个账号读取字段。

这些判断很重要，也构成了企业安全体系的基础。

但 Agent 改变了问题的形态。

一个 Agent 访问候选人数据，可能是为了筛选简历，也可能是为了分析薪资水平；它调用邮件工具，可能是为了通知面试，也可能是为了向外发送敏感信息；它读取客户记录，可能是为了处理当前工单，也可能是为了批量生成营销画像。

从传统权限角度看，这些动作可能都使用了合法账号、合法接口和合法资源。

系统看到的是访问被允许，审计日志里也会显示权限检查通过。

但从业务目的看，它们完全不是一回事。

这就是文章中强调的“semantic privilege escalation”，可以翻译成“语义权限提升”或者“语义越权”。

它不是传统意义上的漏洞提权，也不一定绕过权限系统。

它更隐蔽：Agent 仍然在技术权限范围内行动，但它使用权限的业务语义已经越界。

文章指出，这类问题会表现为 mission drift、reprompting problem 等失败模式，仅靠运行时 intent enforcement 或传统访问控制很难防住。

这也是 Agent 安全里特别容易被低估的一类风险。

我们过去习惯问：“这个账号有没有权限？”

Agent 时代还要继续追问：“它正在用这个权限完成什么目的？”

Purpose 和 Intent，不是一个东西

这篇文章最大的贡献，就是把 Purpose 和 Intent 分开。

在很多行业讨论里，Purpose 和 Intent 经常被混用。

大家都知道 Agent 不能只看身份，还要看它的目的、意图、上下文。

但如果这两个概念不区分清楚，工程上就会出现问题：到底哪个东西应该在身份注册时写入？哪个东西应该在运行时推断？哪个东西由业务负责人审批？哪个东西由策略引擎动态判断？审计时又该记录什么？

文章给出的定义很清楚。

Purpose 是 Agent 被创建和授权行动时声明的政策级理由。它是 Agent 数字身份的一部分，在 provisioning 阶段登记，并且只能通过受治理的生命周期事件发生变化。简单说，Purpose 更像 Agent 的岗位职责。

Intent 则是 Agent 在某个具体任务或会话中，当前试图完成什么。它不是静态身份属性，而是运行时信号，可以从用户提示词、任务计划、工具调用序列、数据访问行为中推断出来。

文章在表格中把 Purpose 定义为 declared、lifecycle、identity governance，把 Intent 定义为 inferred、session、runtime authorization。

用一句话讲：

Purpose 是“这个 Agent 被允许做哪类事”。

Intent 是“这个 Agent 此刻正在尝试做什么事”。

这个区分非常重要。

如果只管理 Intent，没有 Purpose，就没有上层边界。系统可能知道 Agent 当前想做薪资分析，但不知道这件事是否属于它的职责范围。

如果只管理 Purpose，没有 Intent，就没有运行时感知。系统可能知道这个 Agent 的职责是招聘支持，但不知道它在某一轮对话中已经被用户带偏，开始试图访问员工薪酬数据。

Purpose 和 Intent 必须同时存在。一个负责定义边界，一个负责感知当前行为。

这篇文章的核心公式

这篇文章最关键的结构，可以用一个公式概括：

I

(

A

,t) ⊆ Pe(

A

) ⊆ PU(D)

这里，

I(A,t)

表示 Agent A 在时间 t 的运行时意图。

Pe(A)

表示 Agent 当前有效目的。

PU(D)

表示数据 D 被允许使用的目的集合。

这个公式表达了一条很直观的治理链条：Agent 当前想做的事，必须落在它被授权的目的之内；而它被授权的目的，又必须落在数据允许使用的目的之内。

原文把它称为 two-level governance architecture，一层是治理时的 Permission Compatibility Check，另一层是运行时的 Containment Constraint。

这比传统权限判断多了两个约束。

第一，Agent 的 Purpose 要和数据的 permitted-use label 兼容。比如候选人数据可以用于招聘筛选，但不一定可以用于薪酬分析。这个检查通常发生在 Agent 创建、授权或 Purpose 变更时。

第二，Agent 当前 Intent 要被 Purpose 包住。比如 Screening Agent 的 Purpose 是筛选候选人，那么它运行时的 Intent 可以是评估简历、生成候选人排序、提取工作经验要点，但不能突然变成访问现有员工薪资记录。

这就是文章所谓的 Containment Constraint，它把身份治理层和运行时授权层连接起来。传统 IAM 回答“谁访问什么”，Containment Constraint 回答“这个访问为什么发生，以及这个为什么是否仍在边界内”。

数据允许用途约束 Agent Purpose，Agent Purpose 再约束运行时 Intent。

真正危险的，是合法权限里的不合目的使用

这篇文章最适合用一个企业 HR 场景来讲。

设想一家企业部署了一个 HR Orchestration Agent，用来支持招聘流程。

它的 Purpose 很明确：支持人才获取流程，包括候选人寻源、筛选、面试安排和入职流程。这个 Purpose 在 Agent 创建时被登记，Owner 是人才招聘负责人，数据访问范围包括候选人申请数据、职位描述、面试反馈记录和入职文档。

在正常情况下，它可以委派一个 Screening Agent。这个子 Agent 的 Purpose 更窄，只负责评估某个岗位的候选人申请，并生成候选人排序。

这时系统是安全的。

Screening Agent 访问候选人简历，是为了招聘筛选。它的 Intent 落在自己的 Purpose 内，自己的 Purpose 又落在父 Agent 的 Purpose 内，同时候选人数据也允许用于招聘和筛选。

整条链路都对齐。

问题出现在一个很普通的提示词里。

招聘经理可能对 Screening Agent 说：“既然你已经看到了候选人数据，顺便帮我做一个薪资 benchmark，把现有员工薪酬和候选人薪资期望做个对比。”

这句话看起来很自然，甚至很像真实业务里的临时需求。它没有明显的恶意，也不是典型越狱提示词，但它改变了 Agent 当前任务的语义边界。

如果薪资系统与招聘系统完全隔离，传统权限控制可以直接拦截；但在真实企业里，更常见的问题是数据被汇入同一个 HR 平台、数据湖、分析仓库或 SaaS 系统中，Agent 对平台有合法访问能力，却在合法访问范围内改变了数据使用目的。

Screening Agent 原本是为了筛选候选人，现在变成了访问现有员工薪酬记录并进行薪酬对比。

原文认为，这时两个约束都被破坏了：薪资 benchmarking intent 超出了 Screening Agent 的有效 Purpose，也不再和父 Agent 当前“推进招聘筛选流程”的 Intent 对齐。

系统应阻断动作、记录违规，并触发人工介入。

这就是 Agent 风险最麻烦的地方。

它往往不是黑客式的攻击，而是业务流程里的顺手一句话。Agent 也不是拿到了不该拿的权限，而是拿着已有权限做了不该做的用途。

传统权限系统很难识别这种变化，因为它看到的是同一个 Agent、同一类数据、同一条调用链。但 Agent-aware IAM 要看的，是这次访问背后的目的是否已经改变。

Purpose 不是静态标签，而是生命周期属性

这篇文章还有一个很重要的判断：Purpose 不能只是 Agent 创建时填的一行备注。

如果 Purpose 只是静态元数据，那么它很快就会失效。

企业里的 Agent 不会永远只做一件事，业务会变化，工具会增加，数据源会扩展，Agent 会被重新分配任务，也会通过委派形成更窄的子目的。

文章认为，Purpose 必须作为 Agent 身份的正式属性纳入生命周期治理。

它可以在初始创建时声明，可以在 Agent 被重新分配任务时更新，也可以在子 Agent 委派时被收窄，最终在 Agent 下线时失效。

所有这些变化都应该被记录在 Purpose Path 中。

Purpose Path 可以理解成 Agent 的“职责演化日志”。

它记录这个 Agent 从一开始被授权做什么，到后来如何被扩展、收窄、转移、委派、失效。

每一次 Purpose 变化，都应该有触发事件、授权主体、变更前后状态、时间戳和审计记录。

这件事非常现实。

很多企业最初上线 Agent 时，只是一个问答助手。后来加了知识库，再后来接入业务系统，再后来可以调用工单、邮件、数据库、代码执行器。它的能力一点点长大，职责边界也一点点变化。

如果这些变化没有作为身份治理事件被记录，Agent 的真实能力就会和 IAM 里的登记状态脱节。

到了出事的时候，企业很难说清楚：它到底是在执行原始职责，还是某次配置修改后已经变成了另一个 Agent？

多 Agent 系统里，子 Agent 不能只继承权限

单 Agent 场景已经复杂，多 Agent 系统更复杂。

在多 Agent 系统里，父 Agent 会把任务拆给子 Agent。传统权限继承通常关心一件事：子 Agent 的权限不能超过父 Agent。

这当然必要，但还不够。

文章提出，多 Agent 委派需要满足 recursive containment constraint。

简单讲，子 Agent 不仅 Purpose 不能超过父 Agent，当前 Intent 也必须和父 Agent 当前 Intent 保持一致。

原文用公式表达为：

I

(sA,t) ⊆ Pe(sA) ⊆ Pe(pA)，并且

I

(sA,t) ⊆

I

(pA,t)。

也就是说，既要满足目的链约束，也要满足意图对齐约束。

这个要求很关键。

一个父 Agent 的总目标可能是“完成招聘流程”，它委派给子 Agent 的任务是“安排面试”。这个子 Agent 可以访问候选人联系方式和日历系统，但不能访问薪资系统，也不能自己扩展成“分析候选人与现有员工薪酬差异”。

子 Agent 不是一个独立逃逸出来的执行体。它必须在父 Agent 当前任务意图的范围内行动。

这对 Agent 平台非常重要。

未来企业不会只有一个 Agent，而是会形成主 Agent、工具 Agent、检索 Agent、审批 Agent、数据 Agent、代码 Agent 组成的工作流。

如果平台只记录最终工具调用，不记录父子 Agent 关系和任务委派链，就很难判断某个子 Agent 的行为是否已经偏离主任务。

Intent 检测不是万能的，但必须进入授权链路

现在很多 Agent 安全方案都开始谈 Intent 检测，这个方向是对的，但这篇文章提醒我们，Intent 检测不能单独存在。

因为 Intent 是运行时推断出来的，不是天然可信的。

它可能来自用户 prompt，也可能来自 Agent 计划，也可能来自工具调用行为，还可能来自模型自己生成的中间步骤。不同信号的可信度不同。

文章提到，可以通过 prompt/task analysis、behavioral inference 和 signed intent 等方式获得运行时 Intent。

Prompt 分析速度快，但容易被模糊表达和提示注入影响；

行为推断更接近真实动作，但可能偏事后；

signed intent 能增强可归因性，但只能证明“声明过什么”，不能证明声明本身一定合规。

文章还提出 intent confidence，表示系统对当前意图推断结果的确信程度。

这对产品设计很有启发。

Agent 授权决策不应该只有放行和阻断两个状态。

当 Intent 置信度高，而且落在 Purpose 内，可以自动执行。

当 Intent 置信度低，可以降权执行、限制工具、只读访问、要求二次确认，或者转人工审批。

当 Intent 明确越界，才应该阻断并记录事件。

这意味着 Agent IAM 未来会更像风险自适应控制，而不是静态权限表。

它要看身份，也要看目的；要看资源，也要看当前任务；要看工具，也要看行为轨迹；要看是否有权限，也要看这次使用权限的理由是否成立。

这套框架最难落地的地方：粒度

这篇文章没有把问题说得过于简单。

它承认，Purpose/Intent 框架有一个最直接的难题：granularity problem，也就是粒度问题。

如果 Purpose 定义得太粗，系统会产生形式上正确、实质上错误的判断。

比如，一个 Agent 的 Purpose 写成“客户账户管理”，数据的允许用途也写成“账户管理”。这时 Agent 批量导出客户记录到外部分析平台，可能也能被解释成“账户管理”的一部分。公式看起来成立，治理结论却可能不安全。

原文指出，当 Purpose 和 permitted-use labels 定义得过粗时，治理链条可能在形式上成立，但无法提供足够强的治理保证。这个问题虽然在 PBAC 文献中有所讨论，但如何扩展到 Agent Purpose 维度，仍然是开放问题。

这句话特别重要。

因为它说明，Agent 目的治理不是写几个标签就完事。企业必须建立更细的业务目的分类、数据用途标签、工具风险分类和行为语义模型。

“招聘支持”可能还要拆成候选人筛选、面试安排、入职文档处理、人才库维护。

“客户管理”可能要拆成单个客户服务、批量运营分析、风险调查、营销推荐、合同履约。

“财务处理”可能要拆成报销审核、账单生成、付款执行、预算分析、异常检测。

如果这些目的标签过粗，Agent 很容易在一个大标签里完成实质越界。

所以 Purpose/Intent 治理最终会倒逼企业补一件以前不太愿意做的事：把业务目的、数据用途和工具动作语义化、结构化。

这对 Agent 安全产品意味着什么

从产品角度看，这篇文章给了一个很好的定位：Agent 安全不能只做工具调用防火墙，也不能只做 Prompt Injection 检测，它需要进入授权决策链路。

未来一个 Agent 行为管控系统，至少要接住三类上下文。

第一类是身份上下文。包括 Agent ID、Owner、业务域、模型版本、系统提示版本、Purpose、父子 Agent 关系、生命周期状态。

第二类是运行时上下文。包括用户请求、任务计划、当前 Intent、Intent Confidence、工具调用序列、会话状态、上下文变化和异常行为。

第三类是资源上下文。包括数据分类、允许用途、敏感等级、工具风险、外部系统边界和操作可逆性。

有了这些信息，策略引擎才能做真正的 Agent-aware authorization。

比如，同样是访问候选人数据，如果 Intent 是“生成候选人初筛排序”，可以放行。如果 Intent 是“将候选人数据和现有员工薪酬做对比”，就要阻断或升级人工审批。如果 Intent 不清楚，但工具调用涉及敏感数据导出，就要降权或要求二次确认。

这比传统“工具危险就拦截”的方式更细。

因为一个工具本身不一定危险，危险的是 Agent 在什么任务、什么目的、什么数据上下文下使用它。

IAM 正在从“访问控制”走向“目的控制”

这两篇文章连起来看，可以得到一个很清楚的判断。

第一篇说，Agent 不是服务账号，它是一种新的自治非人类身份。企业 IAM 需要管理它的身份、凭证、生命周期、委派链和审计链。

第二篇进一步说，Agent 有身份、有权限还不够。企业还要管理它的 Purpose 和 Intent，防止它在合法权限下发生目的漂移和语义越权。

这其实代表 IAM 的一次范式变化。

过去 IAM 管的是访问边界。谁能访问什么资源，能读还是能写，能调用哪个接口，能操作哪个系统。

Agent 时代，IAM 还要管行动理由。这个 Agent 为什么访问这个资源？当前任务是否仍然在授权目的内？子 Agent 是否和父 Agent 当前目标一致？数据是否允许被用于这个目的？如果发生事故，能不能还原当时的 Purpose Path 和 Intent Log？

这会让 IAM 从后台的权限系统，变成 Agent 平台的前台控制面。

因为企业真正要放开的，不是一个聊天窗口，而是一组能够调用工具、连接数据、跨系统行动的数字执行体。

只要 Agent 开始行动，权限问题就会变成目的问题；只要 Agent 能够委派，身份问题就会变成链路问题；只要 Agent 能够根据上下文调整行为，审计问题就会变成因果解释问题。

所以，Agent 安全的下一步，不只是让 Agent 不说错话，也不是只让 Agent 不调用危险工具。

更关键的是，让企业能够回答：

这个 Agent 为什么这么做？

这个理由是否被授权？

这个目的是否发生了漂移？

这次行动是否仍然在它的职责边界内？

出了问题以后，能不能把它的身份、目的、意图、工具和数据访问链路完整复盘？

当这些问题进入 IAM，Agent 才可能从“能演示的智能体”，变成“能进生产的数字员工”。

也正是在这个意义上，IAM 正在进入目的治理时代。