HUMAN AgenticTrust：允许 Agent 读取，不等于允许它购买

零售商希望购物助手读取商品页，却不想让所有自动访问者都能注册账户或修改已保存的支付信息。全部拦截会损失有效发现流量，全部放行又带来另一类风险。HUMAN AgenticTrust 处理的是商家侧这道准入决策。

核对范围： 2026 年 11 月 1 日查阅官方文档，没有安装 Sensor 或 Enforcer、修改网站策略，也没有测试识别准确率。零售商场景是架构示例。

它属于应用防护能力

接入文档把 AgenticTrust 放在 Sightline Cyberfraud Defense 或 Bot Defender 部署中，需要账户开通和受支持的 Sensor、Enforcer 版本。它不是独立钱包，也不是 Agent 单方采用就能生效的开放支付协议。

因此，产品使用方是负责入站流量的网站或应用运营者。评估策略前，要确认具体应用、边缘或源站部署受到支持，并已开通能力。其他账户里的控制台截图，不能证明自己的环境也有权限。

依据公开文档绘制的商家控制流程，非识别实测，也不代表修改本站安全设置。

读取与结账是不同权限

权限文档区分内容读取、互动、注册、登录、账户修改和结账，也提供会话请求频率限制，并说明可配置权限针对 HUMAN 已知的 Agent。

零售商应先定义希望开放哪种业务交互。商品发现可能只需读目录，不应顺带开放账户管理。经过认可的结账流程可能需要更多动作，但应明确选择，而不是允许首页后自然扩散出来。

策略复核应沿完整用户旅程进行。如果合法助手能读商品，却无法访问必要的交接页，用户会遇到中断；如果为了让结账成功而开放账户修改，又可能授权过宽。上线前应在受支持的实际集成中验证两条路径。

信任级别不是购买委托

信任级别文档把密码学身份、可冒充程度和行为信号列为判断依据，这些结果可以影响默认策略。但它们不证明某个用户批准了某一份订单。

网站准入、登录用户权限和付款授权应分别检查。被识别为正常的 Agent，仍可能使用错误账户、过期会话，或提出超出用户要求的购买。商家不能因为请求获得较好的信任分类，就取消自身订单校验。

默认策略也需要责任人

权限文档区分供应商默认值与运营方主动设置。重要商业流程应记录预期策略和变更审核责任，不能只看“默认”两个字，而不了解实际开放了哪些动作。

商家问题	复核依据
识别了哪个 Agent	身份信号和已知 Agent 覆盖范围
保护哪个应用	Sensor、Enforcer 与部署配置
具体允许什么	活动权限和请求频率限制
什么仍需用户同意	登录、订单与付款授权控制
正常用户受阻怎么办	支持、复核和恢复流程

评估时既看不需要的活动，也看合法购买能否完成。请求量下降，不一定是策略变好，也可能挡住了正常用户；成交增加，也不能成为放任未经授权账户修改的理由。

与身份标准相邻，但不互相替代

Web Bot Auth关注请求的密码学身份；AgenticTrust 是结合身份与行为支持应用策略的运营产品；Trulioo KYA侧重组织和 Agent 凭证。它们位于相邻层次，不是可直接互换的产品。

当商家需要区分有价值的 Agent 访问与不需要的自动化，并保留动作边界时，可以研究 AgenticTrust。通过 HUMAN 资料页核对实际支持部署。本文不建议削弱已有网站防护，也不认为某个知名 Agent 应自动得到结账权限。