Shufti Know Your Agent 将 AI 行动关联至经验证的所有者与权限

Shufti 于 10 月 28 日推出 Know Your Agent，将身份验证扩展至 AI 智能体，同时将经验证的所有权与行动权限区分开来。Shufti Know Your Agent 面向接收代表客户或员工行事的软件所发出的自动化请求的企业。其核心主张十分明确：确认账户持有人身份，并不意味着以该人名义执行的每项操作都已获得授权。

这项公告给那些将智能体接入交易和敏感信息的企业带来了压力。AI 智能体，即能够围绕目标选择并执行任务的软件，需要可实际使用的授权。但授予过于宽泛的权限，可能使合法的助手变成未经授权变更的来源。接收方企业必须区分已获批准的请求，与仅仅携带有效凭证抵达的操作。

Microsoft Entra Agent ID 通过对智能体身份、所有权和访问权限的管理，提供了一个有用的对比。Shufti 强调外部智能体、其经验证所有者以及该所有者授权范围之间的联系，后者指的是委托权限的边界。这些方法从不同起点处理重叠的问题。关键问题在于：当智能体从一条指令走向实际交易时，授权是否仍能得到执行。

Shufti Know Your Agent 为智能体验证加入所有权和授权范围

Shufti 的智能体验证发布公告介绍了一项结合智能体身份、人工授权和权限检查的服务。该公司称，它通过既有的客户和企业验证流程，将智能体关联至个人或企业。所有者可定义允许的操作、限额、到期时间和撤销机制，撤销即收回此前授予的权限。Shufti 表示，这些授权范围适用于每一项请求。

此次公布的变化，是将已识别的所有者与受边界约束的行动关联起来，而不仅仅是进行身份验证。

这一差异之所以重要，是因为企业接收到的是一项请求，而非促成该请求的完整对话。客户可能要求助手整理财务文件，但这条指令并不必然授权转账、修改账户资料或与另一项服务共享文档。接收系统需要能够执行的方式来理解客户实际委托了什么。

Shufti 表示，智能体会获得可到期的凭证，企业可以撤销这些凭证。其 10 月 30 日的智能体授权报道还描述了将请求、决策和已撤销权限与智能体及所有者关联的记录。这些仍属于已报道的产品能力。报道并未证明其在减少欺诈、运营可靠性或客户采纳方面取得了独立成效。

因此，此次发布改变了可供选择的产品主张，但并未确定其有效性。企业可以评估一项围绕委托智能体权限明确设计的服务。它们仍需要证据表明，该服务的决策符合自身的交易规则。验证结果只有在接收它的应用程序准确理解该结果允许什么时才有用。

识别软件与识别其当前权限之间也存在重要区别。一个助手可以保持为同一款可识别的产品，同时为不同客户工作。同一位客户也可以分配具有不同限制的独立任务。企业不能仅凭助手的品牌、既往行为，或其已成功完成身份验证这一事实来推断许可。

访问令牌，即为获得访问权限而出示的凭证，在正确实施时可以携带受限权限。因此，Shufti 的论点应被理解为对授权设计不足的挑战，而非证明令牌天生缺乏边界。实际问题在于，凭证所代表的权限是否与具体业务操作相匹配。

这一框架使公告保持务实。Shufti 提供了另一种关联身份与委托权限的方式。买方应根据接收系统实际执行的内容来评判这种关联，包括当一个本来合法的智能体请求其所有者从未批准的事项时会发生什么。

接收方企业承担权限难题

直接压力落在接收由客户控制的智能体发出请求的组织身上。银行、交易平台和企业软件提供商必须决定，哪些自动化操作应纳入常规工作流。当客户对某项操作提出异议时，它们也需要有可辩护的应对方式。接受自动化会扩大现有账户控制机制必须处理的行动者范围。

接受智能体活动的企业，需要在客户意图与软件自主判断之间划定清晰边界。

设想一个假设性的购物助手，受指示替换一台办公设备。客户允许特定的产品类别和配送地点。结账时，助手发现商品缺货，便选择了替代品。商家现在面临一项业务决策：这次替换是否仍在客户授权范围内？

“找一件合适的东西”这样的指令为判断留出了空间。交易系统需要更明确的条件。产品限制、收件人信息、购买限额和审批要求，决定了该操作是否应当继续。如果这些条件仍隐藏在智能体对话中，商家便无法可靠地应用它们。

这会给多个团队带来工作。产品经理必须界定哪些操作可由智能体不受打断地完成。安全团队必须确保应用程序执行这些定义。客户支持团队需要能够以普通语言解释所发生情况的记录。业务负责人则必须决定哪些例外情况需要重新获得批准。

开发者还面临相关的集成问题。应用程序编程接口，即用于交换请求的软件接口，通常将操作分别暴露出来。读取记录、编辑记录、导出记录和删除记录可能需要不同权限。笼统的“使用账户”权限，并不能说明客户意图中的具体操作组合。

当智能体在任务过程中改变方向时，困难会更加明显。客户可能批准研究供应商，但希望在下单前另行作出决定。追求完成任务的助手可能将下单视为顺理成章的下一步。接收方企业需要一种能够识别这种转变的控制机制。

这种控制也会影响客户体验。要求每一项无害操作都获得批准，会让委托变得不便。允许宽泛权限，则会减少发现重大错误的机会。企业必须决定，在哪些场景下，中断流程所提供的保护足以证明其注意力成本和完成时间成本是合理的。

这正是 Shufti 的公告超出身份团队范畴的原因。该产品主张依赖于反映实际业务决策的规则。验证可以识别相关方，但组织仍必须界定哪些操作需要许可。缺少这项工作，经验证的所有者只会被附加到一项过于宽泛的授权之上。

由此产生的压力既是组织层面的，也是技术层面的。企业需要就谁编写权限规则、谁批准变更、谁处理例外情况达成共识。智能体安全产品无法独立化解便利性、客户控制权和运营风险之间相互冲突的预期。

竞争焦点在于授权在哪里得到执行

Microsoft 的文档描述了包含所有权、担保、权限和活动记录的智能体身份管理。它为管理员提供了一种检查智能体并管理其访问权限的方式。Shufti 的公告则聚焦于企业验证代表个人或组织行事的智能体。这一比较涉及各系统在何处建立信任并实施控制。

核心分野在于：识别合法智能体，与执行其特定任务边界之间的区别。

这些功能可以相互补充。一个组织可能集中管理员工智能体的身份，而另一家企业则评估该智能体的采购请求。内部系统确立组织责任。接收系统仍需判断所请求的采购是否符合所呈示的权限。

任何一方都不应假定另一方已回答所有问题。内部批准某个智能体运行，并不会自动授权每一笔外部交易。对员工的外部验证，也不能证明该员工有权代表组织作出承诺。每个接收系统都需要与自身决策相关的证据。

这一区别避免了对供应商进行过度简化的比较。以目录为中心的产品与客户验证服务不必彼此替代。它们的价值取决于所处环境、涉及的身份关系以及已部署的控制措施。产品名称本身无法证明覆盖范围等同。

Shufti Know Your Agent 进入这一市场时，强调的是委托的客户操作。其差异化将取决于企业能否有效地将这些授权范围转化为可执行的应用行为。若权限决策仍与执行脱节，提供的保护就有限。应用程序必须真正拒绝超出批准范围的操作。

更广泛的安全原则早于这项公告。OWASP 的过度自主性指南指出，过度的功能、权限和自主性会带来风险。该指南建议在下游系统中执行授权，而不是依赖语言模型的判断。语言模型根据学习到的模式和上下文生成回应，因此其输出不适合作为唯一的权限边界。

对于这则报道而言，该指南提供的是独立基准，而非对 Shufti 的背书。相关问题在于：即使智能体执意完成任务，独立控制机制能否阻止未经授权的操作。即使智能体误解了任务，身份和策略也需要保持有效。

设想一个假设性的业务助手，它可以起草供应商消息，却不能发送。只有当消息服务执行这一限制时，这一区别才得以成立。要求助手记住这一限制，会将最终决定留在同一个可能犯错的系统内。拒绝发送的接收服务则建立了更强的边界。

这正是该公告背后的竞争考验。供应商可以用不同方式描述智能体、所有者和审批流程。买方需要确定决定性的权限检查发生在哪里。当有效身份提出无效请求时，对执行的控制才是最具影响力的能力。

人工检查以额外控制换取不中断的自动化

Shufti 描述了当请求超出授权范围或跨越风险阈值时进行额外人工验证的机制。据该公司称，该流程可能包括自拍活体检测，用于评估是否有真实人员在场。这为原本自动化的工作流程增加了一个人工决策节点。其实际作用取决于该人员被要求批准的具体内容。

确认人员在场与确认知情批准，解决的是不同问题。

一个人可以在并不理解拟议交易的情况下完成身份验证。仅显示“继续”的批准界面，传达的信息少于明确说明收款方、操作内容和后果的界面。安全价值部分取决于界面是否让用户能够理解所作决定。仅确认在场无法补足缺失的背景信息。

这是一项分析上的局限，并非证明 Shufti 的实施方案存在缺陷。该公告描述了一种升级验证机制，但并未独立证明客户如何理解其批准界面。采购方需要审查实际体验，并应将成功的身份验证与清晰传达的授权决定区分开来。

一个假设性的付款场景可以说明这种差异。某个代理起初获准向一家既有供应商付款，随后却收到改用另一收款方的指令。额外检查提供了阻止这一变更的机会。但用户需要看到收款方已发生变化，而不只是被要求再次验证身份。

批准还必须始终与最终执行的操作保持关联。如果关键交易细节随后发生变化，先前的决定可能已无法反映实际将要发生的事项。这是接收应用及其验证集成所需解决的设计问题。获批请求与执行请求需要具有一致的边界。

中断也带来了运营层面的选择。代理可能在其所有者无法响应时继续工作。当需要批准时，系统必须有明确的处理结果：暂停、拒绝，或保留草稿。为了让任务继续推进而悄然扩大权限，会破坏这项检查的目的。

无障碍性和恢复机制同样值得关注。合法客户可能无法完成预期的验证方式。企业需要提供一种能够保留所需保障程度的替代方案。否则，一项原本旨在支持已授权自动化的控制措施，可能会成为拥有有效权限客户的障碍。

同样的张力也出现在日常知识工作中。查找信息、起草回复、发送回复以及更改共享记录，代表着不同程度的后果。构建可搜索知识库的团队，也会面临类似的边界：检索材料与授权后续操作之间的界限。获得有用的上下文，并不等于自动拥有发布或修改它的权限。

因此，这项权衡是具体的。额外验证可以在关键时刻恢复人工控制，但也会打断委派流程。企业需要设定能够反映交易风险和用户预期的阈值。若将每一次中断都视为安全成功，就会忽视用户是否获得了足够信息以作出有意义的决定。

发布声明仍未说明有效性与问责机制

截至 11 月 2 日，已审阅的来源证实了这项公告及其所述设计。它们并未提供对完整服务的独立评估。当一款产品结合身份验证、权限规则和交易控制时，这一区别尤为重要。某个组件的成功运行，并不能证明整个工作流程的有效性。

验证缺口在于：完整系统能否在现实的故障条件下执行正确的决策。

有价值的评估应同时考察未经授权的请求和合法活动。拦截攻击者固然重要，但让客户获准执行的任务顺利完成也同样重要。如果一个系统过于频繁地拒绝正常工作，企业就会面临放宽规则的压力。安全性与可用性需要一并衡量。

公开公告并未说明，在互联应用中，已撤销的权限会以多快速度停止相关活动。这是一个实质性的实施问题。当所有者取消权限时，代理可能已有待执行的请求。采购方需要了解，这些请求在完成前是否会再次接受检查。

任务链带来了另一个尚未解决的问题。助手可以要求另一项服务或代理完成任务的一部分。接收方企业随后需要判断，原始授权是否涵盖这类委派。若没有明确限制，清晰的初始授权可能会在工作流程后续环节变得模糊。

行为识别还提出了独立的评估问题。软件可能在更新后改变行为，也可能遇到不熟悉的任务。采购方应询问，系统如何区分合法变化与可疑活动。所审阅的发布材料并未提供这些条件下经独立测量的准确性证明。

这些问题不应被表述为已发现的漏洞。它们指出了评估公司声明所需的证据。没有任何已审阅来源表明 Shufti 的服务未能通过这些测试。同样，仅凭公告本身也无法证明其在生产环境中通过了这些测试。

问责同样需要谨慎处理。将代理与所有者关联的记录，可以帮助调查人员重建事件序列。但它并不会自动解决所有者是否理解请求、凭证是否遭泄露，或应用是否正确执行等问题。这些仍是彼此独立的事实问题。

当记录保留决策背景时，它们会更有价值。调查人员需要知道请求到达时适用了哪些权限，以及最终实际执行了什么操作。当前的账户设置未必能够解释过去的交易。证据应让审查人员能够区分后来的配置变更与此前存在的授权。

国家标准工作进一步凸显了这些未解决问题的重要性。9 月，NIST 的代理身份项目在收到利益相关方反馈后，将软件开发描述为首个实施使用场景。这项工作为评估身份与授权提供了更广泛的背景，但并不认证 Shufti 的产品，也不裁定任何商业方案的有效性。

对采购方而言，含义很直接：应将此次发布视为一项具有可测试声明的具体产品提案。要求其提供与预期部署相关边界的证据。关于可信代理的宽泛保证，应让位于针对允许操作、拒绝条件和事件重建的具体回答。

关注集成证据、独立测试与权限可移植性

下一批有价值的信号，应展示这项方案在发布材料之外如何运作。在未来数月内，应依次关注集成证据、独立测试和权限可移植性。权限可移植性是指在不同服务之间保留可理解的授权边界。每一种信号都在测试已公布方案的不同部分。

进展应以对代理操作的可观察控制来判断，而非以已宣布功能的数量来衡量。

首先，关注那些说明接收应用如何执行授权范围的已记录部署案例。一份有价值的说明应明确允许的任务、禁止的转换，以及代理跨越该边界时的响应方式。仅列出客户名称而没有运营细节，所能证明的内容较少。具体的集成证据将增强其实用落地的论据。

这类证据应包括异常情况，而不只是成功交易。当部署说明取消操作、验证失败或所有者不可用时会发生什么，它就更具参考价值。这些情形揭示了工作流程在压力下是否仍能维持其权限模型。仅限于成功完成的描述，无法回答这些问题。

其次，关注对完整授权流程的独立测试。最有价值的结果将考察冒充、凭证泄露、交易细节变更和权限撤销。测试还应纳入那些被系统错误中断的合法活动。覆盖两类情况的证据，将使有效性更易评估。

如果独立测试显示控制措施能在现实应用边界中保持有效，将增强信心。范围狭窄的演示只能支持范围同样狭窄的结论。结果应明确测试了什么，以及哪些内容仍不在范围内。采购方不应将身份验证方面的证据延伸为关于每一笔下游交易的无依据声明。

第三，关注 Shufti 和其他身份提供商如何处理跨组织边界的权限。所有者的授权需要具有接收企业能够理解的含义。如果每项集成都需要彼此无关的定义，推广和维护将更困难。权限之间的清晰映射将支持更一致的执行。

可移植性也需要限制。被某个商家接受的权限，不应悄然变成对无关业务系统的授权。当互操作性能在身份之外保留限制时，它才有价值。若有证据表明授权在跨系统交接时仍保持边界，将增强该公告的核心主张。

Shufti Know Your Agent 向采购方提出了一项具体主张，值得评估：将代理、其所有者和允许执行的操作连接起来。下一步要判断的是，这种连接能否经受真实工作流程的考验。要求演示一项贵组织实际委派的任务，包括一个超出权限的请求，以及执行期间的取消操作。检查应用阻止了什么、用户看到了什么，以及记录在事后说明了什么。应将评估与具体业务边界联系起来，例如起草与发送之间，或研究与采购之间。在扩大代理访问权限之前，你的团队能否准确识别该边界在哪里被执行，并证明当任务发生变化时它依然有效？