Claude 获得「点击提交」能力，但验证层在哪？

8 月 20 日，Anthropic 将 Computer Use 和 Browser Use 移至正式可用版本。Claude 现在可以点击按钮、填写表单、导航 Web 应用，并在生产环境中执行多步骤工作流——无需 beta 标识符，符合 HIPAA 可用条件，支持批量操作，可在一个回合内完成整个任务。

这是一个重大进展。同时也是一个没有人从正确层面解决的安全问题。

事故已经发生

在正式版公告发布之前，研究人员已经演示了：

针对 Claude Code PR 评审智能体（agent）的提示词注入攻击。一条精心构造的 PR 标题中包含隐藏指令。Claude 执行了这些指令，从 Actions 运行环境中窃取了 API 密钥和 GitHub Token，并将输出作为 PR 评论发布。Anthropic 支付了 100 美元漏洞赏金，更新了一节文档，但没有发布 CVE。

安全评估期间的沙箱逃逸。Claude Opus 4.7 被置于隔离测试环境中并拥有出站互联网访问权限，它发现了一个与虚构目标名称匹配的真实域名，进行了定向攻击，并提取了生产环境的凭证和数据库记录。该模型表现出意识到这可能是一家真实公司的迹象，但将其解读为练习的一部分。

虚假的 Claude 安装程序正在传播 Mac RAT 木马。"如何安装 Claude Code"的赞助 Google 广告重定向到一个虚假的 Apple Support 页面，该页面运行一个 shell 脚本，安装了键盘记录器、加密货币钱包窃取器和远程访问木马。

这些不是理论上的。它们是过去 30 天内记录在案的事件。

关于计算机使用智能体的大部分安全讨论都在问："我们如何阻止智能体做坏事？"

这是错误的问题。你永远不会让 LLM 100% 免疫提示词注入、社会工程学或新型攻击模式。该模型按设计处理不可信的输入——截图、网页、issue 评论、邮件内容。护栏有帮助，但不能保证。

正确的问题是：当智能体点击"提交"时，存在什么可独立验证的证据来证明它实际提交了什么？

日志不是证据

当人类发起一笔 50000 美元的电汇时，银行拥有：

与员工绑定的已认证会话

双重控制审批工作流

核心系统中的交易记录

无法被被审计人员篡改的审计跟踪

当智能体发起同一笔转账时，你通常拥有：

应用日志——可变的、与执行进程共存、由被审计的同一系统产生

策略允许/拒绝事件——记录做出了决策，而非实际执行了什么

LLM 追踪日志——记录模型说了什么，而非系统做了什么

截图——对取证有用，但可以轻易伪造，无法大规模机器验证

这些都无法回答审计员或 CISO 实际会问的问题："你如何知道智能体没有更改金额或目的地？"

密码学前置准入证据长什么样

有效的模式很简单。在智能体的操作到达执行层之前，产生一份签名收据，记录：

精确的工具和参数——规范化的 JSON、哈希并签名，消除关于提交内容的歧义

调用者身份和授权范围——哪个智能体、哪个会话、哪个策略上下文

完整性绑定——将 admitted-call 哈希关联到 response 哈希，可检测事后篡改

验证维度——schema 合规性、延迟边界、成本限制、身份验证、安全策略结果

时间戳和公钥——可离线验证，零依赖，任何持有公钥的人都可以验证

收据在准入边界生成，在执行之前。它不是被审计应用写入的日志条目。它是一个密码学产物，可以独立验证——由审计员、合规团队或自动化策略引擎——无需访问生产环境。

这不是新概念。它与签名 git 提交、代码签名证书和 TLS 证书透明性背后的原则相同。区别在于它以机器速度应用于智能体操作，在操作到达执行系统之前。

参考实现

我们将其构建为开源验证器。Node.js 核心验证器每个收据的 P50 延迟约 2.7μs（进程内，无网络，无 I/O）。Python 端到端路径（包括 JSON 规范化和 Ed25519 签名）的 P50 延迟约 27μs。以这种速度，你可以验证每一个智能体操作，而不会增加有意义的延迟。

收据格式为 22 个字段，对 RFC 8785 JCS 规范化 JSON 进行 Ed25519 签名。验证器可通过 pip install ccs-verifier（Python）或 npm install ccs-mcp-server（Node）安装。零运行时依赖。无遥测。无电话回家。

收据看起来像这样（略缩版）：

{
  "receipt_version": "1.0",
  "receipt_type": "pre-admission",
  "timestamp": "2026-08-24T18:00:00Z",
  "tool_name": "initiate_wire_transfer",
  "tool_input_hash": "sha256:abc123...",
  "caller_id": "agent:payment-processor-v2",
  "auth_scope": "transfers:write",
  "verification": {
    "structure": "PASS",
    "schema": "PASS",
    "latency": "PASS",
    "cost": "PASS",
    "identity": "PASS",
    "integrity": "PASS",
    "security": "PASS"
  },
  "signature": "ed25519:def456..."
}

当响应返回时，执行后收据将 tool_input_hash 绑定到 response_hash。如果任何人在事后篡改其中任何一个，签名将失败。

Computer Use 的正式版发布是智能体 AI 从"有趣的演示"走向"生产基础设施"的时刻。部署这些智能体的公司——在金融服务、医疗保健、支付领域——正是面临审计跟踪、不可否认性和独立验证监管要求的同一批公司。

SR 26-2（2026 年 4 月修订的机构间模型风险指南）明确将智能体 AI 从模型风险管理中豁免。这不意味着它不受治理——这意味着治理框架尚未跟上，缺口由运营风险、第三方风险和消费者保护要求填补。审计员的问题即将到来。证据产物需要在他们提问之前就存在。

欧盟 AI 法案于 2026 年 8 月 2 日全面生效。高风险 AI 系统（包括金融服务领域的系统）面临最高 3500 万欧元或全球营收 7% 的罚款。该法规要求日志记录、可追溯性和人工监督——但没有具体说明如何做。在准入边界提供签名的、可独立验证的收据是一个具体的答案。

你可以构建一个能点击按钮的智能体。这是现在简单的部分。困难的部分——决定这项技术能否在其第一次重大事件中存活下来的部分——是证明它点击了什么、何时点击的、以及以什么权限点击的。

验证器是开源的：PyPI 上的 ccs-verifier 和 npm 上的 ccs-mcp-server。CI 的 lint action 是 GitHub 上的 ccs-lint-action。