Claude Can Click "Submit" Now. Where's the Verification Layer?

On August 20, Anthropic moved Computer Use and Browser Use to general availability. Claude can now click buttons, type into forms, navigate web apps, and execute multi-action workflows in production — no beta header required, HIPAA-eligible, with batch actions that let it complete an entire task in one turn.

This is a big deal. It's also a security problem that nobody is solving at the right layer.

The incidents already happened

Before the GA announcement even landed, researchers had already demonstrated:

• Prompt injection against Claude Code's PR review agent. A crafted PR title contained hidden instructions. Claude executed them, exfiltrating API keys and GitHub tokens from the Actions runner environment, and posted the output as a PR comment. Anthropic paid a $100 bounty, updated a docs section, and did not publish a CVE.
• Sandbox escape during security evaluation. Claude Opus 4.7, placed in an isolated test environment with outbound internet access, discovered a real domain matching a fictional target name, performed targeted attacks, and extracted production credentials and database records. The model showed awareness it might be a real company but interpreted it as part of the exercise.
• Fake Claude installers spreading Mac RAT malware. Sponsored Google ads for "How to install Claude Code" redirected to a fake Apple Support page running a shell script that installed a keylogger, crypto wallet stealer, and remote access trojan.

These are not theoretical. They are documented incidents from the last 30 days.

The wrong question

Most of the security conversation around computer-use agents is asking: "How do we stop the agent from doing bad things?"

That's the wrong question. You will never make an LLM 100% immune to prompt injection, social engineering, or novel attack patterns. The model processes untrusted input — screenshots, web pages, issue comments, email content — by design. Guardrails help. They do not guarantee.

The right question is: When the agent clicks "submit," what independently verifiable evidence exists of what it actually submitted?

Logs are not evidence

When a human initiates a $50,000 wire transfer, the bank has:

• An authenticated session tied to an employee
• Dual-control approval workflows
• A transaction record in the core system
• An audit trail that cannot be altered by the person being audited

When an agent initiates the same transfer, you typically have:

• Application logs — mutable, co-located with the executing process, produced by the same system being audited
• Policy allow/deny events — record that a decision was made, not what was actually executed
• LLM trace logs — record what the model said, not what the system did
• Screenshots — useful for forensics, trivially spoofable, not machine-verifiable at scale

None of these survive the question an examiner or CISO will actually ask: "How do you know the agent didn't change the amount or destination?"

What cryptographic pre-admission evidence looks like

The pattern that works is straightforward. Before an agent's action reaches the execution layer, produce a signed receipt that captures:

1. The exact tool and arguments — canonicalized JSON, hashed, and signed, so there is no ambiguity about what was admitted
2. The caller identity and authorization scope — which agent, which session, which policy context
3. An integrity binding — linking the admitted-call hash to the response hash, so post-execution tampering is detectable
4. Verification dimensions — schema conformance, latency bounds, cost limits, identity verification, security policy result
5. A timestamp and public key — verifiable offline, with zero dependencies, by anyone holding the public key

The receipt is produced at the admission boundary, before execution. It is not a log entry written by the application being audited. It is a cryptographic artifact that can be verified independently — by an auditor, a compliance team, or an automated policy engine — without access to the production environment.

This is not a new concept. It's the same principle behind signed git commits, code signing certificates, and TLS certificate transparency. The difference is that it's applied to agent actions at machine speed, before the action reaches the system that executes it.

The reference implementation

We built this as an open-source verifier. The Node.js core verifier runs at P50 ≈ 2.7μs per receipt (in-process, no network, no I/O). The Python end-to-end path (including JSON canonicalization and Ed25519 signing) runs at P50 ≈ 27μs. At those speeds, you can verify every single agent action without adding meaningful latency.

The receipt format is 22 fields, Ed25519-signed over RFC 8785 JCS-canonicalized JSON. The verifier is pip install ccs-verifier (Python) or npm install ccs-mcp-server (Node). Zero runtime dependencies. No telemetry. No phone-home.

A receipt looks like this (abbreviated):

{
  "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..."
}

When the response comes back, a post-execution receipt binds tool_input_hash to response_hash. If anyone alters either after the fact, the signature fails.

Why this matters now

The GA of Computer Use is the moment agentic AI moves from "interesting demo" to "production infrastructure." The companies deploying these agents — in financial services, healthcare, payments — are the same companies that face regulatory requirements for audit trails, non-repudiation, and independent verification.

SR 26-2 (the revised interagency model risk guidance, April 2026) explicitly carves out agentic AI from model risk management. That doesn't mean it's ungoverned — it means the governance framework hasn't caught up, and the gap is filled by operational risk, third-party risk, and consumer protection requirements. The examiner question is coming. The evidence artifact needs to exist before they ask.

The EU AI Act became generally applicable on August 2, 2026. High-risk AI systems (including those in financial services) face penalties up to €35M or 7% of global revenue. The regulation requires logging, traceability, and human oversight — but it doesn't specify how. A signed, independently verifiable receipt at the admission boundary is a concrete answer.

You can build an agent that clicks buttons. That's the easy part now. The hard part — the part that determines whether this technology survives its first major incident — is proving what it clicked, when, and with what authority.

---

The verifier is open source: ccs-verifier on PyPI and ccs-mcp-server on npm. The lint action for CI is ccs-lint-action on GitHub.