In May 2026, Hacker News buzzed over Agents can now create Cloudflare accounts, buy domains, and deploy, as an official API made possible the workflow where "AI agents autonomously create Cloudflare accounts, purchase domains, and deploy Workers." This marks the moment the assumption that "humans log in to cloud consoles to perform work" broke down, fundamentally altering operational design for custom development.
In projects incorporating Claude Code, Codex, and Cursor, our company is seeing scenarios in practice where "agents autonomously sign up for services linked to credit cards." In an era where autonomous agents trigger expenditures, this article organizes how to redesign custom development contracts and operations.
What changed
Cloudflare's latest announcement is significant because it integrates the following three capabilities:
| Capability | Legacy approach | New system |
|---|---|---|
| Account creation | Manual human operation | Automated via API |
| Domain purchase | Human approves on checkout screen | Agent automatically acquires via Cloudflare Registrar |
| Deployment | Human approves via CI/CD | Agent configures Workers / Pages / R2 directly |
"Automated domain purchasing" is an especially major turning point, turning into reality a structure where annual domain fees + Workers Paid plans + R2 storage costs are incurred on accounts by an agent acting alone.
This is two sides of the same coin with the "automation of destructive operations" discussed in Guardrails Against Production DB Deletion by AI Agents, signaling that agents have begun wielding "the authority to spend money" alongside "the authority to destroy."
The four tiers of "autonomous spending governance" for custom development
At our company, we govern autonomous spending across four tiers: "Budget," "Identity," "Audit," and "Cancellation."
[Tier 1: 予算(Budget Wall)]
├ エージェント単位の月次支出上限
├ 80% 到達 → Slack + メール通知
└ 100% 到達 → API キー失効 + 新規購入停止
[Tier 2: 身元(Identity)]
├ エージェント専用の決済プロファイル
├ 顧客の社員クレカは絶対に使わない
└ Cloudflare / AWS / GCP すべて Service Account
[Tier 3: 監査(Audit)]
├ 取得ドメイン / 課金プラン / IP レンジを日次集約
├ 異常検知(前日比 +200% など)
└ 月次レポートで顧客 PM と共有
[Tier 4: 解約(Off-boarding)]
├ プロジェクト終了時の自動解約スクリプト
├ ドメイン譲渡 / 削除の手順書
└ 残債の精算ルール
In particular, Tier 4: "cancellation upon project completion" is frequently deferred in implementation, but because incidents where "domains registered under dormant agent names continue to be billed" occur frequently, it must be integrated into the design phase at the contracting stage.
Template for "autonomous spending clauses" in custom development contracts
In custom development where agents incur expenses, explicitly defining spending scopes and liabilities at the contracting stage is an essential requirement to prevent incidents.
| Clause | Details | What the client should verify |
|---|---|---|
| Spending limits | Explicitly specify monthly limits per agent | Consultation procedure when exceeding limits |
| Payment entity | Whether our company or the client settles payments directly | Expense booking rules |
| Ownership of acquired assets | Ultimate owner of domains and accounts | Transfer conditions upon project completion |
| Emergency suspension | Right to immediately suspend upon detecting anomalous spending | Notification SLA |
| Audit Logging | Retention period for billing details and operation history | Duration and granularity |
| Cancellation terms | Procedures for cancellation, transfer, and deletion upon completion | Settlement of outstanding balances |
In particular, unless you explicitly document the "ownership of acquired assets," you risk situations after project completion where "no one knows who actually owns the domain." Agree in writing on options such as: "assets acquired under our company's name will either be transferred to the client's name or deleted upon project completion."
Think of this as extending the Approval Gates concept covered in Safely Operating Claude Code Auto Mode in Custom Development to "operations involving financial transactions."
Creating agent-dedicated "payment profiles"
The most critical element in establishing healthy cloud spending is creating "agent-dedicated payment profiles." At our company, we standardize on the following setup:
| Item | Recommended setting |
|---|---|
| Credit card | Project-specific virtual card (Stripe Issuing, etc.) |
| Card limit | Monthly budget + 20% buffer only |
| Usage alerts | Instant Slack notification for all transactions |
| Cardholder name | Includes project name and agent ID |
| Freeze trigger | Automatically frozen when exceeding the limit |
Using personal cards of employees or company representatives is strictly prohibited. Having a structure that can instantly freeze payments if an agent goes rogue is an indispensable requirement in the era of autonomous spending.
Five common pitfalls
Finally, we share common pitfalls encountered in custom development projects dealing with autonomous spending.
Pitfall 1: Starting operations with a personal credit card
Starting out with "let's just use the CEO's card for now" frequently leads to incidents where charges continue on the individual's card long after the project ends. Always issue a project-specific virtual card from day one.
Pitfall 2: Cloud accounts without spending caps
If you forget to set monthly budget alerts on Cloudflare, AWS, or GCP accounts, hundreds of thousands of yen in charges can rack up overnight. Always configure budget alerts on every cloud account.
Pitfall 3: Leaving domain ownership ambiguous
Starting with "we'll register it under our company's name for now" leads to disputes over transfer fees and rights when the project wraps up. Agree on ownership policies during the contract phase.
Pitfall 4: Failing to write teardown scripts
Operating by "visually checking and manually deleting" resources created by agents leads to orphaned resources. Always prepare scripts that fetch resource lists via API and batch-terminate them.
Pitfall 5: Client PMs not reviewing charges
An operational setup where our company alone monitors billing creates scenarios where clients only notice charges when the month-end invoice arrives. Include a contractual rule for the client's PM to subscribe to daily Slack billing alerts.
Summary — From "human approval" to "automated guardrails"
In an era where AI agents create accounts and purchase domains, operational models where humans approve every single action fail on velocity. Designing automated guardrails (budget, identity, audit, cancellation) across both contracts and technical implementation is the only way to maintain healthy boundaries of responsibility in custom development.
Because required designs vary depending on project scale and cloud architecture for concerns around autonomous spending—such as "fearing unpredictable agent expenditures" or "lacking cancellation pathways after project completion"—we provide individual estimates after reviewing your requirements. First, feel free to get in touch via our inquiry form.









