AI Agent权限困境：计划不等于许可，意图授权如何破局

当Agent的"计划"遇上"许可"的边界

一个编码Agent在排查生产环境Bug时，可能需要读取代码仓库、查询日志、甚至提交Pull Request。如果它在调查中发现另一个服务存在可疑行为，读取那个服务的日志似乎是合理的下一步。但它是否应该拥有这个权限，取决于具体的调查任务——然而现实是，它的凭证往往授予了与任务无关的固定权限。

这是当前AI Agent安全领域的一个核心矛盾：API密钥和令牌几乎不携带任何关于Agent被要求做什么、由谁指派、任务如何到达Agent的信息。权限是静态的、预配置的，而任务是动态的、情境化的。两者之间的鸿沟，正在成为企业部署Agent的最大安全隐忧。

意图授权：让访问跟随任务

针对这一问题，意图授权（Intent-based Authorization）提出了一种新思路：利用任务的目的和上下文来决定每次访问的权限。

具体来说，当一个请求到来时，授权系统会评估三个维度：请求的访问权限是否匹配任务指派者（人或系统）的权限范围、Agent被赋予的任务目的是什么、以及组织政策是否允许。举例而言，一个客户支持Agent即便其工具链在技术上能够触及HR记录，检索HR数据的请求也应被拒绝——因为这超出了它的任务remit。

一个事故调查的实战场景

设想一个支付服务报错的告警。编排器提议发起调查，授权服务根据经过认证的触发器、Agent被允许的角色、以及独立于Agent控制的政策来评估请求。随后，它授予事故Agent对该服务前一小时日志的读取权限。

调查推进过程中，Agent发现了指向认证服务的证据，于是请求访问认证服务的日志。政策可能自动允许这次额外访问，也可能要求人工审批——但运行时会在权限授予之前阻塞该请求。Agent可以跟随新线索深入调查，却无法自行决定随之而来的权限范围。

如果事故Agent将日志分析任务委托给另一个Agent，接收方使用自己可验证的身份，仅获得完成其那部分任务所需的权限，且不超出自身权限边界。这种交接可以收窄已有的授权范围，但不能扩大它，同时保留任务上下文并记录是谁传递了任务。

能力收窄（Capability Narrowing） 是多Agent协作中的一项关键安全属性。当Agent A将子任务委托给Agent B时，B获得的权限范围必须是A当前持有权限的子集，而不能是并集或超集。这一原则源自经典的最小权限原则（Principle of Least Privilege），但在Agent间委托的动态场景下需要额外机制保障：每次委托必须携带可验证的身份凭证、明确的任务范围和委派链记录。如果委托链中某一环试图扩大权限，授权系统应直接拒绝该请求。这样即使某个中间Agent被攻破，攻击者也无法通过委托链获得超出原始任务范围的权限。

可信上下文与不可信内容的区分

整个调查过程中，授权系统必须严格区分可信上下文和不可信内容。一个经过认证的告警中可能包含攻击者写入的日志行——信任告警的来源，并不意味着告警内部的指令可以授权访问另一个系统。这个区分对于防止提示注入攻击至关重要。

提示注入（Prompt Injection） 是指攻击者将恶意指令隐藏在看似正常的数据载体中（如日志行、网页内容、文档），当大语言模型处理这些内容时，可能将其误认为合法指令并执行。与传统SQL注入不同，提示注入利用的是模型对自然语言指令和数据的混淆。在Agent场景下，风险被进一步放大：Agent不仅能"理解"恶意指令，还具备执行工具调用的能力，因此一条精心构造的日志行可能诱导Agent去访问未授权的系统、泄露敏感数据或执行破坏性操作。这也是为什么意图授权体系必须将"内容的来源是否可信"与"内容本身是否可信"分开判断。

软件工厂：当Agent也开始"派活"

在软件工厂（Software Factory）模式下，Agent不仅执行任务，还越来越多地提议任务。编排器可以监控事故和扫描器发现的问题，无需工单即可拾取Bug，并派遣Agent去调查和提出修复方案。

但这里存在一个关键约束：Agent识别有用任务的能力，并不赋予它分配这些任务所需权限的权力。工厂需要一个独立的授权决策机制，在Agent运行时强制执行限制。

限制不止于访问控制

这些限制不仅限于访问权限，因为一个Agent可能以糟糕的方式执行一个合法任务。它可能发出数千个不必要的请求，或者产出一个通过审查但在生产环境中失败的变更。

因此，控制体系需要多层防护：预算机制限制资源消耗，检查和测试决定哪些变更可以推进，Agent控制之外的审计记录保存操作历史，可撤销的访问权限让运维人员在出问题时能够中止活动。

可撤销访问权限（Revocable Access） 与传统的静态API密钥形成鲜明对比。静态密钥一旦泄露，在轮换前始终有效；而可撤销权限通常通过短期令牌（如OAuth 2.0的短期Access Token）或动态凭证实现，运维人员可以在检测到异常行为时即时吊销。在Agent场景中，这意味着：当预算机制触发告警、审计记录显示异常模式、或审查环节发现可疑变更时，系统能够立即切断该Agent的进一步访问，而不影响其他正常运行的任务。这种"运行时可中断性"是高自主性Agent系统不可或缺的安全底线。

四重边界架构

由Keycard、Docker、Barclays、Socket和Aaron Stanley共同开发的Software Factory参考架构，展示了这些控制如何协同工作。该架构建立在Agent Baseline之上，定义了四个边界：

• 身份与访问：确保每个Agent操作都可追溯到明确的身份和授权
• 供应链：控制Agent使用的软件组件的来源和完整性
• 沙箱：限定Agent的执行环境
• 网络：约束Agent可以触及的系统范围

这些边界在自主性提升时依然成立，将任务范围的访问与对Agent所用软件、执行位置、可触达系统的控制结合在一起。

软件供应链安全（Software Supply Chain Security） 在Agent场景下面临新挑战。传统供应链安全关注的是依赖包的来源、完整性和漏洞，但Agent可能动态生成代码、调用第三方工具或引入运行时依赖，这使得攻击面显著扩大。该架构中的供应链边界要求：Agent使用的每个组件都需经过来源验证和完整性校验，Agent生成或修改的代码在进入生产前需经过独立审查。沙箱边界则通过容器化或虚拟机隔离，确保即使Agent被诱导执行恶意操作，其影响也被限制在隔离环境内。网络边界进一步约束Agent可触达的系统，防止横向移动。这三层与身份访问层共同构成纵深防御体系。

分离"决定做什么"与"允许做什么"

这套架构的核心洞察在于：工厂可以让Agent自行决定下一步调查什么，同时将访问决策保持在独立控制之下。这种分离使得系统能够承担更多责任和自主性，而无需给每个Agent更广泛的常设权限。

换言之，Agent的计划不等于权限。它可以规划、推理、提议下一步行动，但每一步实际获得多少访问权，应该由一个独立于Agent自身的授权层来裁决。这既是安全的需要，也是Agent走向更高自主性的前提条件。

对正在构建Agent系统的团队而言，这意味着需要重新审视权限模型的底层假设：从"这个Agent能做什么"转向"这个任务需要什么，以及谁有权批准它"。