Answer
How to let an AI agent buy a domain without giving it your credit card
Don't. Pasting card details into an agent conversation puts them in a transcript, a context window and probably a log, and no well-designed agent should ask for them. The right shape is the one Slipdock enforces: the agent prepares the order and cannot pay; you receive an email with the line items and a total; you approve it in your own browser. If you want the agent to keep going without asking again, you add credit and set a per-purchase cap — a ceiling the server enforces, not a promise the agent makes.
what you actually do
- An email arrives: line items, a total, one button.
- You approve it — or close the tab, in which case nothing happens.
- Optionally: add credit and pick a per-purchase cap.
Why "just tell the agent to ask first" is not enough
An instruction in a prompt is a preference, not a control. It can be forgotten across a long context, overridden by a later instruction, or subverted by text the agent read on some web page mid-task. If the only thing standing between your card and a purchase is the model's compliance, the guarantee is as strong as the weakest turn in the conversation.
A server-side cap is different in kind. Slipdock has one function that every debit passes through, and there is no card on file for it to fall back on — only a balance you put there and a ceiling you set. The worst case for a confused or compromised agent is bounded by a number you chose, not by how persuasive the last thing it read was.
agent → POST /v1/domains/register {"domain":"example.com"} 402 payment_required next_action: await_payment, pay_link_sent_to y***@example.com human → [email] approve $10.44 · set cap $50 · add $50 credit agent → GET /v1/orders/o_1f2e {"state":"complete","resources":[{"kind":"domain","name":"example.com"}]} agent → POST /v1/domains/register {"domain":"example.dev"} {"state":"complete"} # $14.50 < $50 cap — no email needed
What a cap actually protects you from
- Loops. An agent retrying a failed registration cannot buy the same domain twice — idempotency keys handle that — and cannot spend past the ceiling regardless.
- Prompt injection. If the agent reads a page that tells it to buy something, the purchase still has to fit under a cap you set, and anything larger comes back to you as an email you did not expect — which is itself the alarm.
- Bill shock on recurring services. Hosting draws monthly from the same wallet. When runway drops below 30 days you are warned; when it runs out the service degrades on a published ladder rather than generating an invoice.
If you are using another provider
The same principle applies and is worth insisting on: never give an agent raw card details, and prefer a provider where the limit is enforced by the API rather than by your prompt. GoDaddy's developer platform requires an explicit purchase-approval field the API will not let an agent skip, which is a genuinely good design even though it does not include a cap. Cloudflare's registrar documentation states plainly that designing a flow which will not buy domains without approval is the developer's responsibility.
Related questions
Does Slipdock store my card?
No. There is no card on file at all. There is a wallet balance you chose to fund and a per-purchase cap you chose to set, and you can empty or lower either at any time.
What if my agent is compromised?
It can spend up to the remaining wallet balance, within the per-purchase cap, on infrastructure attached to your workspace. It cannot withdraw funds, cannot raise its own cap, and cannot add a payment method. Revoking the token stops it.
Can I approve every purchase individually instead?
Yes. Setting no wallet at all is the default: every purchase emails you a link.