当编码智能体调查生产环境中的 bug 时，它可能需要读取代码仓库、查询日志并提交拉取请求。如果它在另一个服务中发现了可疑之处，读取该服务的日志可能是合理的下一步。它是否应该拥有访问权限取决于调查本身，但它的凭证往往无论任务如何都会授予相同的权限。
API 密钥和令牌通常几乎无法说明智能体被要求做什么、由谁指派，或者任务是如何到达智能体的。基于意图的授权利用该目的和上下文来决定每项任务的访问权限。它会将请求的访问权限与指派任务的人或系统的权限、智能体被指派的目的以及组织策略进行比对评估。例如，检索 HR 记录的请求应始终超出客户支持智能体的职责范围，即使它的工具能够触及这些记录。
访问权限跟随任务
设想一个报告支付服务错误的告警。编排器提出一项调查，授权服务使用经过身份验证的触发器、智能体被允许的角色以及在其控制之外制定的策略对其进行评估。然后，它授予事件智能体对该服务前一小时日志的读取访问权限。
随着调查的推进，智能体发现了指向某个身份验证服务的证据，并请求获取那些日志。策略可能会自动允许这一额外访问，或要求人工批准，但运行时会阻止该请求，直到访问被授予。智能体可以顺着新线索追查，而无需自行决定随之而来的权限。
如果事件智能体将日志分析委派出去，接收方智能体使用其自身可验证的身份，并且只获得其任务部分所需的访问权限，且在其自身权限范围内。这种交接可以缩小现有授权，但不能扩大它，并且它会保留任务上下文并记录是谁传递了它。
在整个调查过程中，授权必须区分可信上下文与不可信内容。一条经过认证的告警可能包含由攻击者写入的日志行，因此信任告警的来源并不意味着其中的指令可以授权访问另一个系统。
运行软件工厂
在软件工厂中，智能体越来越多地既提出任务又执行任务。编排器可以监视事件和扫描器发现的问题，在没有工单的情况下接手缺陷，并派遣智能体去调查和提出修复方案。它识别有用任务的能力，并不赋予它分配这些任务可能所需任何访问权限的许可。工厂需要独立的授权决策，并在智能体运行时执行限制。
这些限制不仅限于访问权限，因为智能体可能把一项合法任务执行得很糟。它可能发出数千个不必要的请求，或产生一个通过审查但在生产环境中失败的变更。预算有助于限制消耗，而检查和测试有助于确定哪些变更可以推进。不受智能体控制的审计记录保存了实际发生的情况，可撤销的访问权限则让操作员在出问题时能够停止活动。
由 Keycard、Docker、Barclays、Socket 和 Aaron Stanley 开发的软件工厂参考架构，展示了这些控制措施如何组合在一起。它构建在 Agent Baseline 之上，定义了四个边界：身份与访问、供应链、沙箱和网络。随着自主性提高，这些边界依然成立，将任务范围的访问权限与对智能体所用软件、执行位置以及可触达系统的控制结合起来。
工厂可以让智能体决定接下来调查什么，同时将关于访问权限的决策保持在独立控制之下。这种分离使工厂能够承担更多责任和自主性，而不必给每个智能体更广泛的常设权限。