AskGrokWallet · draft verification procedure
What would this procedure need to be usable in your workpapers?
Not a product page. It is a five-step draft, and the answer we want is whether it fits an audit file — including the last section, which lists what it does not prove.
Why this exists now
AI agents move money directly: paying suppliers, placing orders, swapping tokens. Today the audit evidence for that is one of two things — an export the audited party produced themselves, or an explorer screenshot that proves a transfer happened without proving it was authorised.
EU AI Act Article 12 (record-keeping) has applied since 2026-08-02. The requirement is not "you keep records"; it is that a third party can verify the claim that you checked.
What a record contains
| Field | Meaning |
|---|---|
id summary amountUsd target | what the action was, how much, to whom |
policyId reason | the policy in force, and the rule that fired |
verdict status decision decidedBy | allow / needs-human / refuse, and who decided |
createdAt decidedAt settledAt | timestamps |
txHash rail railRef | if it executed, where |
signature sigVersion | Ed25519 over all of the above |
Each record is appended to an append-only hash chain, whose head is anchored on-chain hourly.
The procedure (draft, five steps)
1. Fetch the verifier and check the published hash BEFORE running it
curl -sLO .../verify-receipt-v1.0.1/SHA256SUMS
curl -sLO .../verify-receipt-v1.0.1/verify-receipt.mjs
shasum -a 256 -c SHA256SUMS
2. Verify a record: signature, its fixed position in the log, its anchor
node verify-receipt.mjs receipt.json
3. Work from structured output, not the four printed lines
node verify-receipt.mjs receipt.json --json
4. Independently check the log and its anchors
curl -s https://askgrokwallet.io/api/receipts/chain
5. Confirm one or two anchors on a block explorer yourself
What it proves, and what it does not
| Proves | Does not prove |
|---|---|
| These fields were signed by a pinned key you can read and pin yourself | That a payment happened — approval and refusal records are signed the same way |
| This record has a fixed position; changing it breaks every later entry | That nothing was omitted — that needs an enforcement point that refuses to execute an unrecorded action; not built yet |
| The log head is in a transaction that executed | That the policy, or the amount, was commercially sensible |
✓ proven · ✗ provably wrong · ~ not checked | That the named human approver is who you think — the signature covers the decision record, not the person |
Sampling we would suggest
- Boundary cases — amounts closest to the policy threshold.
- Every refusal — the hardest kind of evidence to fake, because nobody has an incentive to record what they did not block.
- Every human intervention — rows whose decider is not the policy engine.
- Large or first-time counterparties.
- Anchor spot-checks — pick two or three heads and confirm the transactions yourself.
Boundaries we will not soften. This does not replace management representations and is not an audit of the system. We do not do anonymous or untraceable payments; the record is selective disclosure — visible to whoever should see it. The system is an unaudited developer preview, the code is public, and the verifier can be rebuilt from the specification.