When Your AI Agent Pays the Wrong Amount, It's Not a Security Bug — It's an Evidence Gap
Published August 22, 2026
In February 2026, an AI trading agent called Lobstar Wilde intended to swap 4 SOL. It actually executed a swap for 52,439,283 LOBSTAR tokens — roughly $440,000. The root cause wasn't a hacker, wasn't a prompt injection, wasn't a vulnerability in the underlying blockchain. It was a session restart: the wallet state wasn't reconstructed, the decimal precision drifted, and what the planner said ("4") is not what the executor wrote ("52,439,283").
No human was in the loop. The card network said "authorized, within limit." The policy engine said "rule matched." The application log recorded the call — but the log was written by the same framework that made the call, so it's mutable, not WORM-compliant, and can't satisfy an examiner asking "show me cryptographic proof that the intended parameters matched the executed parameters."
This is not a security vulnerability. It's an evidence gap.
The Four Layers of Why This Matters Now
1. The Incident Layer: Planner ≠ Executor
When an AI agent calls a tool — whether that's a payment API, a database write, or a smart contract — there are at least two components involved:
- The planner (the LLM) decides what to do and declares intent
- The executor (the tool/API client) serializes that intent into actual parameters
Between those two steps, things can silently diverge: session state loss, numeric precision errors, serialization bugs, middleware transformations, model hallucinations. In the Lobstar case, the planner said one thing and the executor wrote another — with no component in the stack comparing the two.
Demonstrations of this class of failure aren't theoretical. In a widely-shared Payman demo, an LLM was trivially manipulated into treating "5000" as "500" and issuing a $500 invoice. Synchrony's August 2026 announcement that it's embedding card issuance into ChatGPT Checkout creates exactly this structure: a plugin is the planner, Synchrony's authorization API is the executor, and they're from two different vendors running two different models.
Existing controls don't cover this gap:
- Card networks and payment rails check "was the human authorized" and "is this within the limit" — they don't inspect whether the LLM's declared intent matches the API's received parameters
- Policy engines (OPA, ACS, Sentinel) evaluate rules against inputs — they don't compare what the planner declared against what the executor sent
- Application logs are written by the same process making the call — they're mutable, don't satisfy WORM requirements, and can't serve as third-party evidence
2. The Regulatory Layer: "Show Me the Receipt"
Across jurisdictions, 2026 marks a shift from "you should log AI decisions" to "you must produce cryptographic evidence of AI decisions":
- EU AI Act Article 12 mandates automatic event logging, traceability, and tamper-resistance for high-risk AI systems, including financial credit and underwriting decisions. While Annex III enforcement was delayed to December 2027 by the Digital Omnibus, Article 12 transparency obligations are already in force — and engineering preparation windows are 6–12 months.
- OCC SR 26-2 (succeeding SR 11-7) requires large banks to maintain an active audit chain from development code through runtime decisions, including model drift, version diffs, and human overrides.
- CFPB / Regulation B / ECOA require that adverse action decisions (credit denials, limit reductions) produce the actual driving factors, original feature values, and override rules — a black box doesn't comply.
- NYDFS Part 500, SEC 2026 examination priorities, FISMA, GLBA all tighten in the same direction.
The examiner's question isn't "do you use AI." It's: "For this specific decision, what did the agent read, which tool did it call, what parameters did it write, who approved it, and where is the cryptographic receipt?"
3. The Procurement Layer: Why Vendor-Neutral Matters
The emerging stack for agent payment authorization is dominated by cloud platform vendors:
- Microsoft Agent Card Service (ACS) issues receipts bound to Azure infrastructure
- Google Agent Payments Protocol (AP2) is a Google + Visa + Mastercard initiative where intent comes from a human signature — it doesn't attest to LLM-to-tool parameter fidelity
- AgentPay is a Claude Code plugin with a 1% session baseline that doesn't transfer across models
- The Verified Agent Protocol (VAP) draft explicitly states it "never encodes tool argument semantics" — deferring argument equivalence to local implementation
For a bank CISO or AI Governance Officer, binding your evidence layer to a single cloud provider creates a procurement problem: the evidence your regulator asks for should be independently verifiable, not locked in a platform vendor's attestation service.
What compliance teams actually need: a vendor-neutral receipt format where the signature verification key is published in an IETF draft, and any auditor can verify the receipt offline using only a public key — no software installation, no cloud account, no API call.
4. The Commercial Layer: It's Not a Tool, It's an Audit Deliverable
The people who sign purchase orders for this category — CISOs, AI Governance Officers, compliance directors — aren't buying a "security tool." They're buying the ability to answer an examiner's question that they currently cannot answer.
When an OCC examiner, ECB inspector, or FCA auditor sits down and asks "for the AI agent that denied this loan or made this payment, show me that the intended parameters matched the executed parameters with cryptographic evidence," the honest answer at most institutions today is: "we have logs."
Logs written by the same system that made the decision. Mutable logs. Logs without digital signatures. Logs that don't satisfy WORM.
How CCS Addresses This
The Correctover Conformance Shape (CCS) is a runtime verification standard for AI agent tool calls, currently an IETF Internet-Draft targeting Experimental RFC status. It defines seven verification dimensions: Structure, Schema, Latency, Cost, Identity, Integrity, and Security.
The part that closes the evidence gap is the receipt mechanism.
The Dual-Hash Intent Binding
When an agent declares its intent to call a tool, CCS computes two SHA-256 hashes:
-
intent_hash: hash of the agent's declared intent (the "planner said this" record) -
args_hash: hash of the actual serialized tool arguments (the "executor wrote this" record)
If the planner said "transfer 4 SOL" and the executor serialized "52439283" — those hashes won't match, and the receipt records both. This is the first mechanism that makes the planner-vs-executor divergence cryptographically visible rather than buried in a log line.
Ed25519 Signed Receipts
Every verification decision produces a receipt containing the dimension results, the dual hashes, timestamps, and metadata. The receipt is signed with Ed25519, producing a 64-byte signature over a canonical JSON body (sorted keys, excluding the signature fields themselves).
The signing public key has a fingerprint: sha256:<base16 of SHA-256(DER SPKI)>. An auditor can pin that fingerprint and verify receipts without trusting any network service.
Offline Verification
This is the critical property for audit and compliance use cases. The verifier is a zero-dependency script. Given a receipt JSON file and a public key (PEM or fingerprint), an auditor runs:
node verify-receipt.js receipt.json --pem signer-public.pem
No API calls. No cloud account. No telemetry. It returns exit code 0 if the signature is valid, 1 if tampered, 2 if the key doesn't match the pinned fingerprint. The verification runs entirely on the auditor's machine.
Reference Implementation
The server-side implementation is ccs-mcp-server v1.2.0 on npm — a Model Context Protocol server with five tools including verify_intent_binding and verify_receipt. It's zero-dependency (pure Node.js stdlib), 23 automated tests pass including tests run against the actual published npm tarball.
The independent auditor verifier is also available as a standalone skill: CCS Receipt Verifier — a single 200-line Node.js script that any auditor can run without installing the MCP server.
The software is archived with a citable DOI: 10.5281/zenodo.22054447.
What This Means Practically
If you're building or operating AI agents that make consequential decisions — payments, credit decisions, data modifications, access changes — the question isn't whether your agent will have a parameter drift incident. It's whether when it happens, you'll have cryptographic evidence of what the agent intended versus what it actually did, or just a mutable log line.
The Lobstar incident cost $440,000. That's the direct loss. The regulatory and reputational cost of not being able to explain it to an examiner is a separate line item — and it's usually larger.
The shift from "log everything" to "sign everything" is already underway in standards bodies and regulatory guidance. The implementations exist. The question is whether evidence architecture is treated as a design requirement now, or a remediation project after an examiner asks a question you can't answer.
CCS is an open IETF Internet-Draft. The reference implementations are available on npm and GitHub.
Top comments (0)