摘要
当Agent能够付款、修改权限、删除资源或发送敏感信息时，账户已经登录、用户点击过按钮，都不能充分证明某个具体动作获得了有效授权。iProov开源发布的Human Approval and Presence Specification（HAPS）提出更严格的思路：高风险动作执行前必须暂停，把准确的待执行内容展示给用户，验证真实人员的存在与批准，并确保批准对象和最终执行动作一致。对企业而言，HAPS最值得借鉴的不是增加一道确认框，而是把“谁、在什么状态下、看到了什么、批准了什么、最终执行了什么”做成可验证证据。企业应立即梳理高风险动作目录，设计交易级绑定、短时有效和防重放机制，并把批准服务放在Agent与执行工具之间，而不是依赖Agent自行遵守提示词。
一、Agent有权限，不等于人批准了这次动作
9月17日，身份验证厂商iProov开源发布Human Approval and Presence Specification（HAPS），采用Apache-2.0许可证，并提供部分Rust参考实现与测试向量。该规范关注的问题非常具体：一个Agent可以使用某个账户或令牌，并不意味着它准备执行的每一个高风险动作，都得到了负责人的真实授权。
过去的企业系统通常把身份、权限和操作连在一起理解。用户登录后，系统根据角色决定他能否访问某个功能；只要请求携带有效会话或令牌，后台往往就认为操作来自该用户。Agent打破了这个默认关系。人可能只是允许Agent处理日常事务，Agent却在复杂任务中生成了一个高风险工具调用；也可能是Agent被提示注入、上下文污染或参数篡改影响，最终执行了用户从未打算批准的动作。
普通确认框也不能充分解决问题。页面显示“是否继续”，用户点击“确认”，后台却没有把这次点击与准确的收款方、金额、资源对象、权限范围和有效时间绑定。只要确认内容模糊、显示层与执行层不一致，或者批准凭证可以被重复使用，所谓“人类在回路中”就只剩流程形式。
HAPS提出的方向，是把人的身份、真实存在和具体事务绑定起来。一旦Agent触发组织定义的高风险动作，系统暂停执行，向用户展示Agent准备执行的准确内容，取得真实人员存在与批准的证明，然后验证批准内容与实际执行动作是否一致。企业事后应能够证明：谁批准了什么，批准时看到的是什么，最终执行的又是什么。
工程判断很明确：OAuth解决“应用能否代表某个主体访问资源”，RBAC解决“某个主体拥有哪些角色权限”，但它们通常不能单独证明“此人刚刚明确批准了这一笔具体动作”。Agent进入金融、医疗、政务和企业运维后，动作级批准会成为身份与权限体系之上的新控制层。
二、可验证批准至少要回答五个问题
第一，批准者是谁。系统需要把批准凭证绑定到明确身份，而不是只记录某个浏览器会话点了按钮。高风险程度越高，对身份可信度的要求越高。普通内部操作可能使用企业单点登录和二次认证，重大资金或关键基础设施操作则可能需要更强的身份与在场证明。
第二，批准者是否真实在场。攻击者如果已经劫持设备、会话或远程控制链路，仅凭账号已登录不足以证明本人正在做出决定。HAPS强调Human Approval and Presence，意味着批准流程不仅关注身份声明，也关注批准当下是否存在真实人员参与。
第三，批准者看到的是什么。批准界面必须以人能理解的方式呈现关键事实，不能只展示工具名、JSON参数或“Agent请求执行操作”。支付要显示金额、币种、收款方和用途；权限变更要显示对象、原权限、新权限和持续时间；数据发送要显示接收方、数据类别和敏感范围；删除操作要显示资源、影响和可恢复性。
第四，批准内容和执行内容是否一致。系统应对规范化后的动作内容形成不可歧义的绑定。批准“向供应商A支付10万元”，不能被替换成“向供应商B支付10万元”，也不能在用户批准后把金额改成100万元。执行端必须重新计算并校验动作摘要，而不是信任Agent声称“已经获批”。
第五，批准是否仍然有效。批准凭证要有短时效、单次使用和上下文约束。任务状态、金额、对象或权限一旦变化，就应重新批准。否则攻击者可以截获旧批准，在不同时间或不同任务中重放。
这五个问题共同构成有效授权链。缺少其中任何一个，企业都可能留下“日志显示有人点过确认，但无法证明他批准的是最终动作”的审计漏洞。
三、批准服务必须位于Agent之外
很多团队会想到在系统提示词中写入：“执行高风险动作前必须询问用户。”这可以改善交互，却不能成为安全边界。提示词属于Agent行为约束，会受到模型错误、上下文冲突和提示注入影响；被攻击的Agent也可能直接调用工具，或者伪造已经获得同意的文本。
可靠架构应把策略执行点放在Agent和真实工具之间。Agent生成动作提案后，工具网关先判断风险等级。低风险动作可以按既定权限自动执行；需要批准的动作被转换为标准化事务，交给独立批准服务；批准服务完成身份、在场、内容展示和签署后，生成与该事务绑定的凭证；最终执行工具独立验证凭证，再执行一次且仅执行一次。
这个结构包含三个不能混淆的对象：动作提案、批准凭证和执行结果。Agent负责提出“想做什么”，人负责批准“允许做什么”，执行系统负责确认“即将做的和获批的相同”。三者需要独立记录并通过事务标识关联。
企业还应避免让Agent自己拼接批准页面。展示内容应由受信任服务根据标准化事务生成，否则Agent可以省略关键字段、使用误导性描述，甚至在自然语言摘要中掩盖真实参数。对于金额、账户、权限范围、数据目的地等关键字段，界面应直接读取待执行事务，不接受Agent提供的自由文本作为唯一说明。
批准凭证也不应是简单布尔值。至少应包含批准者身份、事务摘要、动作类型、目标对象、时间戳、有效期、随机数或唯一标识、策略版本，以及必要的密码学证明。执行端要检查完整性、有效期、使用次数和当前事务是否匹配，并把校验结果写入审计日志。
四、企业应如何划定“高风险动作”
HAPS并不主张所有Agent动作都人工确认，否则自动化将失去价值。真正困难的是风险分层。企业可从影响对象、不可逆性、金额或规模、数据敏感度、权限提升和外部传播六个维度建立动作目录。
通常应直接列入高风险的动作包括：大额或异常支付；新增收款账户；授予管理员权限；扩大数据访问范围；删除生产资源或备份；修改安全策略；向外部发送敏感信息；提交具有法律效力的声明；改变医疗、信贷、保险等重要决定；执行会影响大量客户的批量操作。
但风险不能只按工具名判断。同一个“发送邮件”工具，发送会议纪要可能是低风险，向外部域名发送客户名单则是高风险；同一个“修改配置”工具，调整测试环境日志级别和关闭生产安全控制也完全不同。因此策略引擎需要检查参数、目标、环境、数据分类和业务上下文。
建议企业设计四级处置。一级为低风险且可逆，允许Agent自动执行并记录；二级为中等风险，执行后通知或允许短时间撤销；三级为高风险，要求单人可验证批准；四级为重大风险，要求双人复核、职责分离或线下程序。批准强度应与潜在损失匹配，而不是所有场景套用同一种生物识别或同一个弹窗。
风险目录还必须动态更新。一次事故、一次红队测试或一种新工具接入，都可能暴露原先未识别的危险组合。安全团队要定期审查哪些动作被频繁批准、哪些动作经常被拒绝、哪些动作通过拆分规避阈值，并据此调整规则。
五、可验证批准仍然可能失败
第一类失败是“看不懂但照点”。即使能够证明批准者真实存在，也不能证明他理解了操作。批准界面若充满技术术语、字段过多或警告泛滥，用户会形成点击疲劳。解决办法不是继续增加弹窗，而是突出后果、异常点和不可逆部分，并减少不必要的人工介入。
第二类失败是“显示正确、执行被替换”。如果批准服务和执行工具之间缺少端到端绑定，攻击者仍可在批准后修改参数。必须由执行端验证同一个规范化事务摘要，不能只检查“此用户最近批准过某类操作”。
第三类失败是重放。一次有效批准如果没有唯一编号、有效期和已使用状态，就可能被重复提交。资金、权限与删除操作应默认使用单次凭证，执行成功或失败后都要有明确状态机，避免网络重试造成重复动作。
第四类失败是通道被劫持。若批准消息与Agent运行在同一受攻击界面，用户可能看到伪造内容。高风险场景可考虑独立可信通道，例如企业认证应用或受管理设备，并在通道中显示能够核对的事务细节。
第五类失败是审批人本身权限过大。可验证批准证明“谁批准了”，却不自动证明“此人有权批准”。执行端还要校验审批人的业务授权、金额额度、职责范围和利益冲突规则。HAPS类机制应与RBAC、ABAC、职责分离和最小权限共同使用，而不是替代它们。
第六类失败是隐私与生物特征风险。验证真实人员存在可能涉及敏感身份数据。企业应尽量保存可验证结果和必要证据，而不是无期限集中保存原始生物特征材料；还需明确数据处理目的、访问权限、保留周期和替代流程。安全控制不能以制造新的高价值隐私风险为代价。
六、从今天开始落地的企业行动清单
第一步，盘点Agent当前能调用的所有写操作。不要只看公开API文档，要结合实际令牌权限、工具封装和网络访问路径，确认Agent事实上能改变哪些数据、资产与外部状态。
第二步，建立高风险动作登记表。每项至少记录动作类型、目标系统、触发条件、潜在损失、是否可逆、当前审批方式、审批人范围和日志证据。先覆盖支付、权限、删除、敏感数据外发和生产变更五类，不要试图一次穷尽所有场景。
第三步，在工具网关设置强制拦截。任何被标记为高风险的动作，没有有效批准凭证都不能进入执行系统。拦截必须由确定性策略完成，不能依赖模型自评“这是否危险”。
第四步，定义标准化事务格式。对每类动作明确哪些字段必须展示和绑定。例如支付事务至少绑定金额、币种、付款方、收款方和用途；权限事务至少绑定主体、资源、权限级别和有效期。字段发生变化即视为新事务。
第五步，实施防重放和最小授权。批准凭证短时有效、单次使用，并只授权一个明确动作。不要签发“未来一小时内允许Agent做所有财务操作”这类宽泛许可。确有批量业务时，也要绑定批次、对象集合和总额上限。
第六步，建设完整审计链。日志需要关联Agent版本、策略版本、动作提案、展示内容、批准者、在场验证结果、批准时间、凭证校验和执行结果。日志本身应防篡改，并限制访问。发生争议时，企业要能重建全过程，而不是只找到一条“approved=true”。
第七步，做对抗测试。测试者应尝试在批准后替换参数、重复使用凭证、拆分金额规避阈值、诱导用户批准模糊内容、利用超时和重试触发重复执行。只有在这些路径上验证过，审批机制才从交互功能变成安全控制。
七、采购与治理：不要把HAPS误解为一项孤立产品
HAPS以实验规范形式开源，来源材料提到Apache-2.0许可证、部分Rust参考实现和测试向量，但没有提供其在大规模企业系统中的部署成效。因此，企业现阶段应把它视为值得参考和试验的协议方向，而不是已经成熟统一的行业标准。
采购相关方案时，应重点考察：能否绑定准确事务而非仅绑定登录会话；能否由执行端独立验签；是否支持短时效、单次使用与撤销；能否根据风险采用不同批准强度；是否提供清晰且防误导的可信展示；如何处理身份与生物特征数据；能否导出完整审计证据；在批准服务不可用时是安全失败还是绕过控制。
治理层面还要明确例外流程。批准人无法操作、身份验证失败、紧急事件处置和系统断网时，企业可能需要备用机制，但备用机制不能变成日常绕过通道。任何紧急放行都应限制范围、提高审计等级，并在事后强制复核。
最终判断是：Agent时代的授权单位正在从“账户”和“会话”下沉到“具体动作”。人类监督是否有效，不取决于流程里有没有一个人，而取决于这个人是否看到了真实事务、是否以足够可信的方式批准，以及执行系统是否只能执行被批准的那一件事。对高风险Agent而言，可验证人工批准不是降低自动化水平，而是让自动化获得进入核心业务的资格。
参考资料
- Business Wire / iProov｜《iProov Publishes HAPS, an Experimental Specification for Verifying Human Approval of AI Agent Actions》｜2026-09-17。
https://www.businesswire.com/news/home/20260917276267/en/ - iProov｜《HAPS: Verifying Human Approval of AI Agent Actions》｜2026-09-17。
https://www.iproov.com/press/haps-specification-human-approval-ai-agent-actions - AI技术每日分析｜《2026年9月18日三篇日报》中“iProov发布HAPS”部分｜2026-09-18。本文事实表述据该日报整理，工程判断与企业建议为基于该材料的分析。