Agent Proof of Presence：高风险工具调用＋MFA＋人工确认＋审计完整项目

摘要： Agent Proof of Presence 是针对高风险 AI Agent 操作的“新鲜在场证明”控制：即使用户已经登录、Agent 已持有 Token，系统仍要求真实授权人在关键动作发生前重新验证身份、查看具体交易内容并明确确认。本文以 GitHub 2026 年 9 月发布的企业 Proof of Presence 公测为事实起点，结合 NIST 数字身份指南、Passkey/WebAuthn 与企业零信任实践，给出高风险工具调用、MFA、人工确认、双人审批、短时授权和审计闭环的完整落地方案。适合 Coding Agent、MCP Gateway、CI/CD、云资源、数据库和企业自动化团队，用于阻止被劫持会话、长期 Token 或提示注入把“可调用工具”变成未经授权的生产操作。

核心结论

企业应该为高风险 Agent 工具调用建立 Proof of Presence，但不能把它理解为“登录时做过 MFA”或“弹窗点一次允许”。有效的 PoP 必须证明：正确的人在正确时间，看到并同意了这一次具体动作；授权还必须绑定工具、参数、目标资源、环境、数据摘要和有效期，任何变化都应重新确认。

• 必须触发 PoP： 创建或导出 Token、修改 Webhook 与安全策略、合并受保护分支、生产部署、数据库写入、删除数据、付款、外发敏感信息、修改 IAM/MFA 和恢复码等动作。
• 首选认证方式： 对高风险操作优先使用具备抗钓鱼能力的 Passkey/FIDO2 或受管设备上的强 MFA；短信和仅密码重认证不应作为最高风险动作的唯一证明。
• MFA 不等于交易批准： 身份验证只能证明“谁在场”，审批界面还要清晰展示“要做什么、对哪个资源、产生什么后果”，并把确认绑定到调用摘要。
• Agent 不持有永久特权： 通过策略引擎签发一次性、短时、最小权限的执行凭证；执行后立即失效，不能让 Agent 缓存审批会话或复用人的登录 Cookie。
• 审计必须可关联： 请求、风险判定、认证、人工决定、实际调用、目标系统结果和回滚状态必须共享同一事务 ID，才能证明“批准的动作”和“执行的动作”一致。

Proof of Presence 到底是什么

结论：Proof of Presence 的核心不是生物识别，而是“新鲜身份验证 + 明确意图 + 具体动作绑定”。 GitHub 在 2026 年 9 月 24 日宣布，GitHub Enterprise Cloud 的特定企业可以要求成员在执行高影响操作前回到身份提供方重新认证或完成 MFA。官方举例包括创建 Token、编辑 Webhook、修改组织安全设置和查看恢复码。它的目标是降低会话 Cookie、长期 Token 或 Agent 被劫持后的影响：系统不能只看到一个仍然有效的会话，还要确认真实授权人此刻正在参与。

GitHub 当前方案是企业 sudo mode 的扩展。完成挑战后，用户可在同一浏览器会话中继续执行受保护操作，沿用两小时的 sudo mode 会话模型。这个设计适合 GitHub 账户与企业管理场景，但对自主 Agent 来说仍需更细粒度：如果 Agent 在两小时窗口内连续发起多个不同的生产动作，仅依靠“刚刚验证过”可能不足以表达用户对每一笔操作的明确意图。

因此，本文把企业 Agent PoP 定义为一种实施模式，而不是声称它已经是跨厂商统一标准。它由四部分组成：

1. Fresh Authentication： 使用近期完成的重认证、MFA 或 Passkey 证明授权人仍在场。
2. Human Intent： 用户必须主动触碰、输入、点击或使用验证器完成明确响应，而不是被动检测到人脸就算同意。
3. Transaction Binding： 把工具、关键参数、目标、环境和内容摘要绑定到挑战与签名。
4. Policy Enforcement： 由 Agent 之外的策略与执行层验证授权，模型本身不能伪造、降低或跳过要求。

如果你正在建设统一安全控制面，可以结合 AI Stack Nav 的 Agent 安全沙箱检索 与 MCP Gateway 检索 共同设计：沙箱限制 Agent 能接触什么，PoP 决定某次高风险能力何时可以释放。

为什么现有 Agent 审批还不够

结论：普通“Allow/Deny”弹窗主要防误操作，PoP 还要防被劫持会话、被盗 Token、恶意自动化和审批重放。 如果浏览器会话已经被盗，攻击者可能直接点击普通确认；如果 Agent 拿到长期云密钥，即使 UI 被关闭，它仍可从后台执行；如果批准只绑定工具名，Agent 还能在用户确认后替换参数。

常见失效场景包括：

• 用户批准“创建测试 Token”，执行时却生成组织管理员 Token；
• 用户确认向测试群发送消息，Agent 实际把源码发往外部 Webhook；
• 用户完成一次 MFA 后，后台任务在有效窗口内执行额外删除；
• 审批链接被复制到另一台设备或另一会话重放；
• 提示注入诱导 Agent 把“安全扫描”替换为上传私钥；
• 子 Agent 或重试机制复用同一批准，重复付款或重复部署；
• 人工界面显示自然语言摘要，真实 MCP 参数中藏有额外接收者或更宽 Scope。

NIST SP 800-63B 对“authentication intent”的解释很关键：认证过程要让申请人对每次认证或重认证请求做出明确响应，目的是减少恶意软件在用户不知情时调用验证器。NIST 还指出，被动摄像头捕获人脸不必然证明意图，需要额外的明确动作。这意味着“人在电脑前”“人脸出现在镜头里”都不是充分的 Agent 操作授权。

哪些 Agent 操作必须要求 PoP

结论：PoP 应由业务影响和不可逆性触发，而不是按某个产品或工具名称触发。 同一个 MCP Server 既可能只读查询，也可能删除客户；同一个 gh 或 kubectl 命令的风险取决于参数和环境。

操作类别	典型动作	推荐控制	原因
身份与凭据	创建 PAT、API Key、SSH Key，查看恢复码	强 MFA/Passkey + 每次 PoP	可形成长期访问能力
权限与安全	IAM、MFA、分支保护、审计、SSO、Webhook	每次 PoP，关键项双人审批	可关闭或绕过后续控制
源码与供应链	合并保护分支、发布包、修改 CI、签名发布	PoP + Diff + CI + 独立复核	影响软件供应链
云与生产	部署、扩缩容、网络规则、K8s、Terraform Apply	PoP + 变更单 + 短时凭证	影响生产可用性与成本
数据	生产写入、批量导出、删除、改变 Schema	PoP + 数据范围 + 回滚计划	泄露或不可恢复损失
外部通信	发邮件、群发、Webhook、公开发布	PoP 或草稿审批	声誉、隐私与合规风险
资金	下单、转账、退款、购买云资源	强 PoP + 金额/收款方绑定 + 双人审批	直接财务损失
普通开发	工作区检索、测试、格式化、临时构建	沙箱内自动允许	低风险且可重建

PoP 并非越多越安全。对每条只读命令都要求 MFA 会造成严重审批疲劳，最终用户会机械确认。正确做法是先用沙箱、最小权限、只读副本、网络白名单和资源配额把大量低风险操作降到自动执行，只把真正高影响的决策留给强认证和人工判断。

需要双人审批的场景

单人 PoP 仍可能受到胁迫、内部滥用或账号接管影响。以下动作建议双人审批：关闭审计或安全策略、修改身份提供方连接、导出大规模敏感数据、删除生产数据库、发布关键基础设施、改变付款账户、签发组织级高权限 Token，以及批准 Agent 自身权限升级。两位审批人应来自不同职责组，不能由同一人使用两个账号完成。

MFA、Passkey 与“在场”的正确关系

结论：Passkey/FIDO2 更适合作为高风险 PoP 的认证基础，但仍需交易确认层。 GitHub 官方说明，Passkey 基于公钥密码学、绑定网站域名并依赖安全连接，浏览器会拒绝在仿冒域名上完成认证，因此比 SMS 或 TOTP 更抗钓鱼。NIST 也把 WebAuthn/FIDO2 作为通过验证者名称绑定提供抗钓鱼能力的例子。

认证强度可以分三档：

• 基础重认证： 再次输入密码。能证明会话用户仍掌握密码，但容易受钓鱼、恶意软件和凭据填充影响。
• 一般 MFA： TOTP、推送、短信等。增加第二因素，但短信和可转发验证码仍可能被钓鱼或劫持。
• 抗钓鱼 MFA： Passkey/FIDO2、安全密钥、受管设备中的平台验证器。更适合生产、权限和凭据操作。

然而，WebAuthn 签名通常证明的是对某个 Relying Party 挑战的响应，不会天然把任意 Agent 交易详情都呈现并加密绑定给用户。W3C 曾讨论把交易文本显示并绑定到认证断言的机制，但相关 WebAuthn Level 2 扩展因浏览器支持不足被移除。实施时不能宣称“用了 Passkey 就天然实现任意交易签名”。更可靠的做法是：服务端生成不可预测 Nonce，把规范化的动作摘要放入批准对象，认证成功后由审批服务签发只对该摘要有效的一次性授权。

七层系统架构

结论：PoP 必须是 Agent 之外的独立控制平面。 模型可以提出请求、解释原因和响应拒绝，但不能自己签发授权或直接接触长期高权限凭据。

1. Agent 与任务层： 提交工具名、参数、目的、来源材料和预期副作用。
2. 风险分类层： 解析操作语义，识别生产环境、敏感数据、外发、资金、权限和不可逆性。
3. 策略决策点 PDP： 根据用户、设备、资源、时间、风险和企业策略决定允许、普通审批、PoP、双人审批或拒绝。
4. 身份与 MFA 层： 调用企业 IdP、Passkey/FIDO2 或条件访问，取得新鲜认证结果。
5. 交易绑定与授权层： 规范化调用内容，计算摘要，签发短时一次性 Capability Token。
6. 策略执行点 PEP： 位于 Shell 代理、MCP Gateway、Git/CI、数据库或云 API 前，验证 Token 后执行。
7. 审计与响应层： 记录请求、认证、批准、实际结果和回滚，进行异常检测与合规取证。

生产凭据应保存在执行代理或密钥系统中，而不是传给模型。Agent 获得的是工具引用和授权结果；PEP 在调用瞬间交换短时凭据，并将权限限制到精确资源与动作。即使 Agent 会话被窃取，攻击者也无法从上下文中提取永久管理员密钥。

交易绑定：防止“批准 A，执行 B”

结论：审批必须绑定规范化后的机器可验证对象，而不是只保存一段自然语言摘要。 自然语言适合给人理解，签名对象则必须稳定、精确、不可歧义。

下面是一个 PoP 请求对象示例：

{
  "transaction_id": "TXN_01JEXAMPLE",
  "actor": "[email protected]",
  "agent_id": "coding-agent-prod-01",
  "tool": "github.merge_pull_request",
  "tool_version": "2026-09-24",
  "resource": "org/payment-service#842",
  "environment": "production",
  "parameters": {
    "base_branch": "main",
    "head_sha": "COMMIT_SHA",
    "merge_method": "squash"
  },
  "effects": ["write_code", "trigger_ci", "possible_deploy"],
  "diff_digest": "sha256:DIFF_DIGEST",
  "expires_at": "2026-09-26T03:10:00Z",
  "nonce": "RANDOM_ONE_TIME_NONCE"
}

服务端应采用确定性序列化后计算 transaction_hash，审批页展示同一对象的人类可读版本。批准后生成的 Capability Token 至少绑定：事务哈希、审批人、认证时间、认证强度、工具、资源、最大调用次数、过期时间和随机 Nonce。PEP 必须重新计算实际调用摘要并比较；任何参数、Commit SHA、收款方、金额、域名或目标环境变化都使授权失效。

一次性 Token 应在首次成功或明确失败后标记已使用。对结果不确定的网络超时，先使用事务 ID 查询目标系统状态，而不是直接重试。涉及付款、消息发送、Issue 创建和部署的工具都应支持幂等键。

策略配置示例

结论：策略需要版本化、可测试并默认拒绝。 以下是厂商无关的示意 YAML，可映射到内部 Policy Engine、MCP Gateway、CI/CD Gate 或云访问代理，不代表 GitHub、OpenAI 或某一 IdP 的原生格式。

policy_version: "2026-09-25"
default_decision: deny

authentication_profiles:
  standard_mfa:
    max_age_seconds: 900
  phishing_resistant:
    methods: [passkey, fido2_security_key]
    max_age_seconds: 300

rules:
  - id: deny-secret-export
    match:
      effects: [read_secret, external_egress]
    decision: deny

  - id: prod-destructive-two-person
    match:
      environment: production
      effects: [delete, disable_security, change_iam]
    decision: require_two_person_pop
    auth_profile: phishing_resistant

  - id: high-impact-tool-pop
    match:
      effects: [create_token, merge_protected_branch, deploy, pay, publish]
    decision: require_pop
    auth_profile: phishing_resistant
    bind_transaction: true
    capability_ttl_seconds: 120
    max_uses: 1

  - id: low-risk-workspace
    match:
      environment: development
      effects: [read_workspace, test, lint]
      external_egress: false
    decision: allow

fail_mode: closed
audit:
  immutable_log: true
  redact_secrets: true
  retention_days: 365

策略顺序必须确保 deny 和更高强度要求不能被后续宽松规则覆盖。身份提供方不可用、风险解析失败、工具版本改变、审计服务中断或交易对象无法规范化时，应停止高风险操作，而不是为了可用性自动降级为普通允许。

完整执行流程：从 Agent 请求到安全落地

结论：一个可靠的 PoP 流程应把风险判定、认证、交易确认和执行结果串成不可拆分的状态机。 推荐实现以下十步：

1. Agent 提交意图： 发送工具调用、完整参数、任务理由、目标资源、数据来源和预期影响。
2. 网关规范化： 解析别名、路径、资源 ID、环境和工具版本，生成稳定交易对象。
3. 风险引擎评分： 判断是否涉及生产、Secrets、外发、删除、权限、付款或不可逆操作。
4. 策略作出决定： 返回自动允许、普通确认、PoP、双人 PoP 或禁止，并记录命中规则。
5. 创建挑战： 生成事务 ID、Nonce、过期时间和交易摘要，冻结待批准参数。
6. 展示确认页： 明确展示工具、目标、Diff、金额/接收者、使用身份、风险和回滚方案。
7. 完成强认证： 跳转企业 IdP 或调用 Passkey/FIDO2；验证认证时间、方法、设备与条件访问结果。
8. 记录人工决定： 用户批准或拒绝；双人场景等待不同职责的第二位审批者。
9. 签发并消费凭证： 授权服务签发一次性 Capability Token，PEP 校验事务摘要后执行。
10. 闭环审计： 记录实际参数、响应、外部对象 ID、Diff、错误、重试和回滚状态，通知审批者。

审批界面怎样避免“确认疲劳”

结论：审批页面要让授权人在十秒内看懂风险，又能展开验证原始参数。 只显示“是否允许 Agent 使用 MCP？”会迫使用户盲批；塞满原始 JSON 又让非技术审批人无法判断。

页面第一层应显示：动作、目标、环境、关键变化、外发对象、金额或数据量、Agent 请求理由、风险等级与是否可回滚。第二层可展开完整参数、代码 Diff、资源 Plan、Token Scope、数据分类和策略命中详情。对付款应突出金额、币种和收款方；对代码合并应突出仓库、分支、Commit SHA 与 CI 状态；对数据导出应突出表、字段、行数与目的域名。

批准按钮必须清晰区分“仅本次”“拒绝”和“转交双人审批”，高风险动作不能提供“一直允许”。移动端推送应包含数字匹配或事务摘要，防止 MFA Fatigue 和误点；请求来源、设备和地理异常应触发更高强度验证或直接阻断。

审计证据与不可抵赖性

结论：PoP 的审计目标是证明批准者、批准内容和实际执行三者一致，而不是承诺法律意义上的绝对不可抵赖。 企业应保留足以复原事件的技术证据，并由法务与合规团队确定其证据效力。

建议日志字段包括：事务 ID、任务和会话 ID、Agent/模型版本、策略版本、工具与服务端版本、原始参数的脱敏副本、规范化对象、事务摘要、风险标签、审批者、认证方法、认证时间、设备合规状态、IdP 断言标识、决定与理由、Capability Token ID、PEP 校验结果、实际执行摘要、目标系统响应、外部对象 ID、回滚与通知状态。

日志要写入不可变或防篡改存储，实施访问隔离、签名或哈希链、时间同步、保留期限和敏感字段脱敏。绝不能把真实 API Key、Passkey 私钥、完整 IdP Token 或恢复码写入日志；只记录引用、Scope、签发方与不可逆指纹。

与 GitHub Proof of Presence 的关系

结论：GitHub PoP 是重要的现实产品信号，但当前公测范围和会话模型不能直接等同于通用 Agent 逐工具审批。 GitHub 官方说明，该功能目前处于 Public Preview，适用于使用 Microsoft Entra ID 作为 SAML 或 OIDC IdP 的特定 GitHub Enterprise Cloud/托管用户企业；配置可以选择重新认证或 MFA。官方还说明 PR Merge 的 PoP 支持“即将推出”，因此本文不能把它描述为已经普遍可用。

GitHub PoP 的价值在于把高影响操作重新连接到企业 IdP 策略，可利用 MFA、设备合规或重新登录证明新鲜性。限制是：它沿用 sudo mode 的两小时有效会话，且保护范围由 GitHub 当前高影响动作清单决定。企业自己的 Agent 还可能使用 CLI、PAT、GitHub App、MCP、云 API 和后台队列，因此必须在这些调用路径前部署统一 PEP，避免只保护浏览器界面。

微软公开的源代码零信任实践也提供了更严格的参照：受保护分支合并需要真实验证人员使用新鲜 MFA，并结合分支分类、最小权限与例外治理。它说明 PoP 最适合成为软件供应链控制的一部分，而不是替代代码评审、CI、签名和分支保护。

风险、限制与回退方案

结论：PoP 能降低会话劫持和无人知情执行风险，但不能证明 Agent 的业务判断正确，也不能自动消除内部威胁。 主要边界包括：

• Public Preview 变化： GitHub 当前功能、支持 IdP 与动作范围可能调整，上线前以官方页面为准。
• MFA 仍会被攻击： 推送疲劳、SIM Swap、钓鱼代理、终端恶意软件和账号恢复流程仍可能削弱保证。
• 交易展示欺骗： UI 摘要与真实参数不一致时，强认证也只是批准了错误内容。
• Agent 旁路： 直接 API、长期 Token、备用机器人或目标系统本地账号可能绕过审批网关。
• 可用性风险： IdP、审批服务或移动设备不可用会阻塞生产操作，因此必须设计受控 Break-glass。
• 隐私风险： 设备状态、生物认证结果、位置与行为日志属于敏感数据，应坚持最少收集。
• 审批疲劳： 频率过高会诱导盲批，应通过风险分层和批量计划减少低价值挑战。

Break-glass 不能是共享管理员密码。应使用离线保管的应急身份、强硬件认证、双人启用、极短有效期、受限网络、即时告警和事后强制复盘。应急操作同样写入独立审计，并在事件结束后立即轮换相关凭据。

回退时先禁用高风险自动执行，让 Agent 降级为生成计划、Diff 或草稿；人工在现有安全流程中完成动作。这样即使 PoP 服务故障，开发与分析仍能继续，而生产变更不会静默绕过控制。

成本与实施建议

结论：PoP 的主要成本不是 MFA 许可证，而是策略集成、工具代理、审批体验和持续运营。 企业需要投入 IdP/条件访问、Passkey 或硬件密钥、策略引擎、MCP/工具 Gateway、审计存储、SIEM 对接、移动审批、红队测试和支持流程。具体费用取决于现有企业订阅与自建程度，官方来源没有给出一个可普遍套用的 Agent PoP 价格。

建议先选三类高风险动作试点：生产部署、保护分支合并、组织级 Token 创建。用四周统计请求量、平均批准时间、拒绝原因、误触发率、旁路发现、失败回滚和开发者满意度。若审批时延过高，优先优化风险分类与上下文展示，而不是扩大长时授权窗口。

事实依据与来源

官方已确认：GitHub 于 2026 年 9 月 24 日发布企业 Proof of Presence 公测，支持在高影响操作前回到 IdP 重新认证或完成 MFA；当前公测支持 Microsoft Entra ID，并沿用 sudo mode 的会话与超时模型。GitHub Sudo Mode 官方列出的保护动作包括 Token、Webhook、组织安全、成员与角色、规则集和恢复码等。

NIST SP 800-63B-4 明确解释了抗钓鱼、重放抵抗和 authentication intent；其中 WebAuthn/FIDO2 是通过验证者名称绑定实现抗钓鱼的例子，明确响应是证明认证意图的重要部分。GitHub 官方 Passkey 文档说明 Passkey 使用公钥密码学并绑定网站域名。W3C 资料则说明，曾讨论的 WebAuthn 交易文本绑定扩展因浏览器支持不足被移除，因此本文没有把通用交易签名描述为当前 WebAuthn 的默认能力。

本文的七层架构、交易对象、YAML 策略、十步状态机、Capability Token、审计字段和双人审批范围属于编辑实施建议，并非 GitHub 或 NIST 的统一产品规范。文章没有第三方 Benchmark；实际认证强度、合规证据效力、IdP Claim 和各目标系统权限仍需企业实测与法务审查。

FAQ

Agent Proof of Presence 与普通 MFA 有什么区别？

普通 MFA 通常证明用户登录时拥有两个或更多认证因素；Agent PoP 强调在高风险动作发生时重新证明人在场，并让人明确确认具体工具、参数和目标。MFA 是重要组件，但只有与交易绑定、短时授权和执行校验结合，才形成完整 PoP。

GitHub Proof of Presence 已经正式可用吗？

截至 2026 年 9 月 25 日，该功能处于 Public Preview，官方说明当前面向特定 GitHub Enterprise Cloud/Enterprise Managed Users 场景，并支持 Microsoft Entra ID。预览功能与范围可能改变，企业应先在测试组织验证。

GitHub PoP 是否已经保护 PR 合并？

不能把它写成已全面支持。2026 年 9 月 24 日的 GitHub Changelog 表示，Pull Request Merge 的 Proof of Presence 支持“coming soon”。在正式可用前，应继续依靠分支保护、必需评审、CI 和内部合并 Gate。

Passkey 是否等于对 Agent 交易进行了数字签名？

不等于。Passkey/WebAuthn 能强力证明用户对特定网站挑战作出响应并提供抗钓鱼属性，但任意工具参数不会自动以人类可读形式绑定到断言。企业仍需创建交易摘要，并让授权服务签发只对该摘要有效的执行凭证。

哪些操作一定要每次重新确认？

创建高权限凭据、关闭安全控制、生产删除、付款、外发敏感数据、改变 IAM/MFA、查看恢复码和绕过分支保护应每次确认，部分还需双人审批。普通工作区检索、测试和格式化不应重复触发强 MFA。

Agent 可以持有完成 PoP 后的 IdP Token 吗？

不建议。IdP Token 和人的会话应保留在审批/授权服务中，Agent 只接收“批准或拒绝”及一次性 Capability Token。执行代理在目标系统调用时使用受控短时凭据，避免模型上下文成为凭据仓库。

两小时的新鲜认证窗口是否足够安全？

它适合部分账户管理体验，但不一定适合每个 Agent 生产动作。企业应按风险缩短窗口，并对金额、目标、Commit SHA 或权限范围变化重新挑战。最高风险操作建议一次批准对应一次调用。

IdP 或手机不可用时怎么办？

高风险动作应 Fail Closed，并使用受控 Break-glass，而不是自动跳过 MFA。应急身份需要硬件认证、双人启用、短时权限、即时告警和事后复盘；普通分析任务可以降级为只生成计划与草稿。

如何防止批准被重复使用？

每个挑战加入随机 Nonce、短过期时间和事务摘要，签发 max_uses=1 的 Capability Token。PEP 原子地记录消费状态；发生超时先按事务 ID 查询结果，而不是直接重放请求。

参考来源

• GitHub Changelog：Require proof of presence for high-impact actions
• GitHub Enterprise Cloud：Configuring Proof of Presence
• GitHub Docs：Sudo mode
• GitHub Docs：About passkeys
• NIST SP 800-63B-4：Authenticators
• Microsoft：Zero Trust for source code access
• W3C：How EMVCo, FIDO, and W3C Technologies Relate

内容核验日期：2026 年 09 月 25 日

会员充值教程

会员充值与订阅排查资料

适合阅读会员充值、订阅购买、权益对比和支付问题类文章后继续转化。

AI 订阅充值失败排查包 整理常见支付失败、地区限制、订单未到账和账号异常处理步骤。 查看资料包 会员权益对比表 对比不同 AI 工具会员权益、价格、适用人群和购买建议。 查看资料包