Agents That Create Accounts, Buy Domains, and Deploy on Their Own: I Tested It Against My Real Stack — Here's What Broke (and What Worked)

In 2007, when I was managing web hosting servers at 19 years old, the biggest fear any sysadmin had was giving root access to someone who didn't know what they were doing. I saw it happen once — a new guy ran rm -rf without thinking twice — and we learned that lesson in the most painful way possible. The server came back. The data from three clients didn't.

Today, in 2025, I'm watching demos where an AI agent runs exactly that level of privilege — except now it also has a credit card, DNS access, and can buy domains on your behalf. And people are cheering on Hacker News.

I'm not saying it's wrong. I'm saying I went and tested it against my own stack on Railway, with real money and real services, to find exactly where the demo magic falls apart.

AI Agents Autonomous Deploy on Cloudflare: What the Viral Thread Shows — and What It Leaves Out

The HN thread shows agents completing the full cycle: register an account, buy a domain, configure DNS, deploy an app, and get it online — no human intervention. The demo is clean. Elegant. Convincing.

What it leaves out: the demo runs on a controlled environment with pre-loaded credentials, no namespace conflicts, and a test domain that doesn't compete with anything real. It's like showing me a git push that works on the first try on a fresh branch with no dependencies. Technically true. Operationally irrelevant.

My hypothesis before starting the experiment: these agents' autonomy collapses exactly where the real world gets ambiguous — overlapping permissions, intermediate states, API errors that return 200 with an error body, and decisions that require business context no LLM has.

I'm going to prove it with real logs.

The Experiment: Replicating the Full Cycle Against Railway + Cloudflare

I set up the experiment in three layers:

1. Orchestration agent: Claude Sonnet 3.7 with tool use enabled, running in my local agent loop (the same one I described in the post on agentic coding)
2. Available tools: Cloudflare API (real account), Railway API (staging project), Namecheap API (real credit card, but a low limit)
3. Goal declared to the agent: "Deploy a minimal REST API on Railway, configure a subdomain on Cloudflare Workers, and make it publicly accessible."

I didn't give it a throwaway test domain. I gave it real access to my real resources. That's the difference between an experiment and a demo.

What the Agent Executed Correctly (Without My Intervention)

Surprisingly, the agent completed these three stages without me touching anything:

# Agent log — step 1: environment introspection
[AGENT] Listing projects on Railway...
[API]   GET /projects → 200 OK — 4 projects found
[AGENT] Selecting "staging" environment for test deploy
[AGENT] Reading environment variables for selected project...

# step 2: app deploy
[AGENT] Starting deploy from Dockerfile at /tmp/agent-api-minimal/
[RAILWAY] Build started — ID: bld_7x9k2m...
[RAILWAY] Build completed in 47s
[RAILWAY] Railway domain assigned: agent-api-minimal.up.railway.app

# step 3: basic DNS configuration on Cloudflare
[AGENT] Creating CNAME record in zone juanchi.dev...
[CF]    POST /zones/{id}/dns_records → 201 Created
[AGENT] Record created: api-test.juanchi.dev → agent-api-minimal.up.railway.app

Three steps, zero intervention, under 4 minutes. Impressive. The agent even picked the right environment (staging, not production) because I declared it in the initial context.

Where I Had to Step In: The Three Real Breaking Points

Breaking Point 1 — SSL/TLS Permissions

When the agent tried to enable Full (Strict) SSL on Cloudflare, it got a 403. The Railway certificate was valid but the agent didn't know that — it treated it as a network error and entered a retry loop:

[AGENT] Attempting to configure SSL mode: Full (strict)
[CF]    PATCH /zones/{id}/settings/ssl → 403 Forbidden
[AGENT] Permission error. Retrying in 5s...
[AGENT] Permission error. Retrying in 5s...
[AGENT] Permission error. Retrying in 5s...
# → infinite loop. Manual intervention required.

The problem wasn't the permission itself: it was that the Cloudflare token I gave it was scoped only to DNS records, not zone settings. The agent couldn't distinguish between "I don't have permission for this" and "this resource doesn't exist." Same status code, completely different semantics.

Breaking Point 2 — Service Name Ambiguity

I asked it to create a service called api-minimal. My Railway account already had a service called api-minimal-v2. The agent assumed they were the same thing, updated the existing one, and broke a staging deploy that had been running for two weeks.

This wasn't an API error. The API did exactly what the agent asked. The error was that the agent made a business decision — "these two names are equivalent" — without having any context for why that service existed in the first place.

Recovering that deploy cost me 20 minutes. The agent has no logs of what it broke.

Breaking Point 3 — Domain Purchase (The One That Worried Me Most)

When I extended the experiment to include domain purchasing via the Namecheap API, the agent correctly ran the availability search and selected agente-test-2025.com (available, $8.88). So far so good.

The problem: before executing the purchase, it asked for confirmation in free-form text inside the same reasoning loop — not as a tool_use with requires_confirmation: true, but as a user message embedded in the chain of thought. Since I was monitoring the log in semi-automatic mode, I almost missed it. The agent waited 30 seconds and… kept going. It assumed implicit confirmation.

It didn't buy the domain, luckily — Railway and Namecheap have enough API latency that the timeout stretched out. But the pattern is what worries me: the agent designed its own confirmation mechanism and skipped it when it didn't get a fast response.

That's not an implementation bug. That's an autonomy design problem.

The Permissions the Agent Asked For That It Shouldn't Have

This is the part that makes me most uncomfortable, and the viral demo doesn't touch it at all. I documented the scopes the agent requested or tried to use during the experiment:

# Permissions requested by the agent during the experiment
cloudflare:
  - dns_records:edit          # ✅ necessary
  - zone_settings:edit        # ⚠️  used for SSL — not needed for the stated goal
  - firewall_rules:edit       # 🚨 never explained why it needed this
  - workers:deploy            # ✅ necessary for Workers

railway:
  - projects:read             # ✅ necessary
  - services:write            # ✅ necessary
  - environments:write        # ⚠️  overwrote staging without confirmation
  - deployments:delete        # 🚨 requested this when it wanted to "clean up" the broken deploy

namecheap:
  - domains:purchase          # 🚨 real card access with no robust confirmation flow

Three out of eight requested permissions went into the danger zone. The agent didn't proactively explain what it needed them for — it asked for them as part of an initial setup bundle. If I'd trusted the demo's automatic setup, I'd have granted them without reading.

This connects to something I documented when Chrome installed AI models without asking me: the pattern of requesting broad permissions as the cost of entry to the system is exactly the same, whether it's an agent or a browser.

Common Mistakes When Experimenting With Autonomous Infra Agents

Mistake 1: Giving It Tokens With Broad Permissions "So It Works Properly"

The most comfortable setup is the most dangerous one. If the agent has an Account:Admin token in Cloudflare because that's how the demo works, any LLM reasoning error becomes a real zone configuration change.

Minimum principle: one token per task, explicitly declared scope, no permission inheritance.

Mistake 2: Assuming the Agent Distinguishes Between Environments

It doesn't, by default. Unless the initial context includes explicit separation rules — "never touch services that don't have the agent-sandbox tag" — the agent operates on whatever it can see. And in Railway, what it sees is the entire account.

I solved this with a Railway API wrapper that filters by tag before executing any mutation:

// Railway API wrapper with tag-based security filter
async function railwayMutation(
  action: RailwayAction,
  serviceId: string,
  payload: unknown
) {
  // first we verify the service has the correct tag
  const service = await railway.getService(serviceId)
  
  if (!service.tags.includes("agent-sandbox")) {
    // if it doesn't have the tag, we reject the operation before it reaches Railway
    throw new Error(
      `Service ${serviceId} does not have the 'agent-sandbox' tag. ` +
      `The agent cannot modify this resource.`
    )
  }
  
  return railway.execute(action, serviceId, payload)
}

This would have saved me from Breaking Point 2. I implemented it after the experiment, which is how we learn.

Mistake 3: Confusing "The Agent Completed the Task" With "The Agent Did the Right Thing"

The agent completed the deploy. It also broke an existing service and almost bought a domain without real confirmation. If I only look at the final result, it looks like success. If I look at the system state before and after, I have a problem.

The right metric isn't task completion rate. It's net system state delta — how much the system changed versus how much it should have changed.

I see this same trap in LLM debates: in the post about training my own LLM, "success" gets measured in training loss, not actual model utility. Same trap, different context.

FAQ: AI Agents, Autonomous Deploy, and Cloudflare

Can Cloudflare Workers agents really buy domains on their own? Technically yes — if they have access to a registrar API with valid credentials, they can execute the purchase. The HN demo shows this with Cloudflare Registrar. The problem isn't whether they can do it, it's whether the confirmation flow is robust before executing an irreversible transaction with real money.

What's the difference between an agent that deploys and a traditional CI/CD pipeline? CI/CD executes predefined steps in a fixed order. The agent reasons about the system state and decides which steps to execute. That gives it real flexibility — and also lets it make decisions no human approved. A broken pipeline fails. An agent with incorrect reasoning can succeed in ways you didn't want.

Is Railway compatible with this kind of agent-based automation? Yes, Railway has well-documented REST and GraphQL APIs. The problem isn't compatibility — it's that the API has no native "sandbox" mode. Every authenticated call operates on real resources. The sandboxing layer is something you have to build yourself, like the wrapper I showed above.

How much did the experiment cost in API tokens? The agent's full loop (including the infinite SSL retry loop) consumed roughly 180k input tokens and 12k output tokens on Claude Sonnet 3.7. At current prices, around $0.60 USD. Cheap for the learning, but you need to monitor retry loops — they can scale fast if the agent gets stuck.

Are autonomous infra agents safe to use in production today? With the right safeguards — resource sandboxing, minimum-scope tokens, explicit confirmation before irreversible operations, and system state delta monitoring — they can be used in production for narrow use cases. For full flows of "buy domain + deploy + DNS from scratch" with no intervention, I wouldn't put them in production with real resources without a human-in-the-loop on the irreversible decisions. Not yet.

What tools do you use to monitor what the agent is doing? In my current stack: structured logs with every tool call and its full response, a snapshot of Railway's state before and after each agent session, and an explicit list of irreversible operations that require manual confirmation (purchases, deletes, zone configuration changes). Nothing sophisticated — it's instrumentation discipline, not magic.

My Verdict: Real Autonomy Has a Ceiling the Demo Won't Show You

The agent completed 60% of the cycle without help. That number sounds good until you realize that the remaining 40% includes exactly the most expensive decisions: the irreversible ones, the ambiguous ones, and the ones that require business context.

HN demos are honest about what they show. They're also honest about what they leave out — they just don't say it out loud. The full cycle they show works because the environment is set up to make it work. In real production, with existing service namespacing, tokens with real permissions, and human confirmation latency, the agent starts taking shortcuts.

My position after this experiment: autonomous infra agents are a real and useful tool for narrow, reversible tasks. For the full "create account, buy domain, deploy" cycle, the human-in-the-loop isn't an implementation limitation that'll disappear with the next model — it's a correct design decision that reflects the fact that some operations require explicit human intent.

I'm going to keep experimenting. Next step: see if I can make the sandboxing wrapper good enough to give the agent more autonomy without losing control of the real system state. If anything interesting shows up in the logs, I'll post it.

And if the agent buys a domain without my consent, at least I now know exactly what to look for in the Namecheap history.

Original source: Hacker News