Small things run. Big things ask. Every spend, a receipt.
Grok Bot’s wallet is all-or-nothing: nag you on every action, or hand over the keys. AskGrokWallet is the layer in between for your bots — one policy, budgets tracked per requester, over-the-line asks, and a signed receipt on every action.
“Under $50 runs. Over $50 ask me. Never pay blacklisted merchants. Daily budget $200.” The engine compiles it — no hooks, no config files.
2
The engine decides: allow / ask / deny
Every agent request is checked against the policy. In-budget runs instantly, out-of-bounds is held, blacklisted is refused — and you see exactly which rule fired.
3
You approve. It signs a receipt.
Anything that needs a human hits your inbox — one tap on your phone. Every action leaves a signed receipt: which bot, what, which rule, who approved.
Connect a real agent — in one call
Your bot asks before it spends. You answer once. It keeps a receipt.
Meet Atlas — a bot that pays your SaaS bills and API invoices. Instead of handing it a card, you give it one line: before any spend, POST the request here. Under the line it runs on its own; over the line it waits for one tap. Either way you get a signed receipt.
{
"ok": true,
"verdict": { "verdict": "ask",
"reasons": ["$80 is over the $50 line"] },
"approval": {
"id": "appr_9c1f2ab04e7",
"status": "pending",
"requester": "atlas"
}
}
ask → lands in your console for one tap. allow → runs instantly, receipt logged. deny → refused before the money moves.
🔒
Why the “deny” actually holds: Atlas doesn’t hold your card — it spends from a bounded on-chain allowance. Over-budget or off-allowlist never gets signed, so it’s blocked before the money moves — not flagged after. That’s the part a plain card can’t do.
⚡
Running on Grok? Skip the curl.
Install the grokbotwallet skill and your bot calls this gate on every spend automatically — no code. Honest note: this is opt-in. It governs spend that routes through the gate; a raw card you hand the bot we can only flag, not block.
The budget, policy, receipts and attribution Grok doesn’t ship.
◈
Per-agent spend caps
Per-transaction and daily limits, summed per requester — so each bot carries its own daily budget. No monthly limit yet.
❝
Plain-English policy
Write rules like a sentence. The compiler turns them into allow / ask / deny.
🧾
Signed receipts
Every spend produces a receipt: agent, request, rule hit, approver, time.
◎
Attribution & audit
Every row records which requester asked, and each receipt is signed. The log itself is shared, not one per bot.
🔒
Funded, never the keys
On the rails we sit on, the agent holds no key and no card — it spends from a bounded allowance, and over-budget never gets signed.
▤
Batch approvals
The inbox approves or rejects the whole pending queue in one pass, one tap each.
What we can actually stop
If it runs through the gate, we hold it. If not, we can only flag it.
The honest line most tools blur: real enforcement needs us on the payment rail. On-chain spend (x402 / stablecoin) runs from a bounded allowance, so we block it before it happens. A credit card the agent already holds settles on the card networks — we can only log it after the fact.
Enforced — held before it happens
✓
On-chain payments from a bounded allowanceLive
Rules are evaluated inside the signing infrastructure before a signature exists: allowlisted counterparties, a per-call cap, key export blocked. Demonstrated on Base mainnet with one real USDC payment and two refusals that were never broadcast.
✓
Pay-per-call API payments (x402)Roadmap
Not wired end-to-end yet. The gate is rail-agnostic and the pieces exist, but do not read this as shipped — today's live rails are the two above and below.
✓
Send a message (Slack / X)Roadmap
When the send is routed through us as a tool call, an over-the-line post is held for one tap.
✓
Send or delete emailRoadmap
Gated as a routed action — a deletion or blast waits for you.
✓
Delete or move filesRoadmap
When the destructive call routes through the gate, it’s the checkpoint — not an afterthought.
Flagged — logged & alerted, not blocked
▲
Any credit / debit / virtual card
Card spend settles on the card networks, merchant-initiated — it never routes through us. We log it and alert you, but we structurally cannot decline the charge. This isn’t a roadmap gap; it’s how cards work.
▲
Any raw key the agent already holds
If it can sign or spend without asking us, we’re not the fence — we’re the camera. Give it a bounded allowance instead.
The fix: don’t hand an agent a card or a raw key. Fund a bounded on-chain allowance and route its spend through the gate — then every action is enforced, not just observed.