Should a Coding Agent Buy Its Own Domain? Where the Approval Belongs

If a coding agent on your team can complete a purchase, the approval should live where the money moves: inside the tool interface, not in a prompt instruction. That is the practical answer, and the evidence for it now comes from two directions at once. Vercel’s CLI, per its own changelog, can buy a domain but refuses to do so unattended, returning a structured error that hands confirmation back to the operator. Meanwhile, recent measurements show that the alternative, telling the agent in a prompt to respect a budget, performs weakly and sometimes in the wrong direction. If you run Claude Code, Codex, or Cursor in any workflow that touches paid APIs, domains, or cloud resources, the question is no longer whether to gate spending but which mechanism does the gating.

The rest of this piece maps agent actions to gating mechanisms and gives you audit questions for each.

One changelog, one question: who says yes to a purchase?

Vercel’s changelog entry, Agents can now buy domains with the Vercel CLI, documents something new for coding-agent CLIs: a complete purchase path. The interesting part is not that an agent can search for a domain. It is that the vendor claims to have designed the refusal as carefully as the purchase.

According to the changelog, when the command runs non-interactively, as it would inside an agent loop, the tool declines rather than charging: vercel domains buy “returns a structured, machine-readable error and the suggested next commands, so the agent hands the confirmation back to you, prohibiting it from spending money without your approval.”

That sentence deserves a slow read, because it describes a specific architecture. The agent is not told “please don’t buy without asking.” The command itself refuses when no human is present, and it refuses in a machine-readable form, with next commands the agent can relay, so the operator can approve explicitly and rerun. The approval boundary sits in the tool, below the model entirely.

The same changelog says the CLI “ships an agent-facing skill covering the discovery, pricing, and purchase workflow, so agents will follow the full sequence without being told the steps.” This is the part that should get your attention as a buyer of guardrails rather than a reader of announcements: the vendor encoded the entire path from search to checkout as a skill, and then put the one irreversible step behind an interface gate. The skill teaches; the tool decides.

Two caveats before building on this. First, Vercel’s changelog is the only source for this flow. No independent test of the refusal behavior is cited, so nothing outside Vercel demonstrates that the structured error behaves as described in pricing edge cases or failure modes; on renewals, the changelog documents nothing beyond the purchase-time auto-renew option. Second, the changelog itself is a marketing surface: Vercel sells domains, and a pleasant agentic purchase path is in its commercial interest. Treat the flow as a design pattern worth demanding from every vendor, not as a verified implementation.

Four layers of control, only two enforced

The reason the Vercel pattern matters more than any prompt rule is structural. A handbook-style analysis of Claude Code lays out the taxonomy directly: “instruction, permission enforcement, sandboxing and operating-system isolation are four distinct layers of a control stack, only two of which are enforced, and conflating them is the most common cause of loss of control.”

Instruction is what you write in a system prompt, an AGENTS.md, or a SKILL.md. It influences the model’s output distribution. Nothing compels it. Permission enforcement, sandboxing, and OS isolation are different in kind: they constrain what an action can do regardless of what the model intended. An illustrative case of the conflation is a team that writes a prompt rule against purchases and believes its spending is gated: instruction doing a job only enforcement can do.

Spend approval fits this taxonomy cleanly. A line in your agent’s prompt saying “never purchase anything” is instruction. A CLI that returns a structured refusal when run without a human is permission enforcement. A network sandbox that cannot reach a payment endpoint is isolation. These are not stronger and weaker versions of the same control; only some of them can fail silently when the model is confidently wrong, and instruction is the one that can.

What the measurements say about the alternatives

Three independent results quantify why the prompt-first alternatives underperform, and each points at a different layer.

Prompt-level budgets fail measurably. EcoAgent-Bench, a benchmark of 304 real-derived tasks in which every task specifies priced actions and an explicit budget, tested what happens when agents see their budget in the prompt. The finding: “merely exposing a budget in the prompt is insufficient; budget awareness must enter the action-selection rule itself.” The response was “weak and sometimes reversed”: the sweeps compared tight, medium, and loose budgets rather than budget versus no budget, and the clearest reaction ran the wrong way, with Gemini raising unnecessary deep-research use to 19.4% at the loose budget on tasks where cheap evidence already sufficed (EcoAgent-Bench). A budget stated in natural language is information the model can use or ignore; a budget wired into the code that selects the next action is a constraint it cannot.

Skills drift like copied dependencies, because they are copied dependencies. Skill Constellations, a supply-chain study of agent skills on GitHub, defines the surface plainly: “Agent skills are SKILL.md instructions and scripts that AI coding agents such as Claude Code and Codex run with the permissions of their user.” Within ten months the format appeared in 259,596 repositories holding 1,612,846 distinct skills (Skill Constellations), and half of all SKILL.md files on GitHub are verbatim copies of another file. Only 11.1% of changes to a clone group stay consistent across every observation window (Skill Constellations), and consistency collapses once a group spans several owners. The practical consequence: the “same” skill your agent runs today may diverge from the copy you reviewed, and the skill executes with your permissions. If a purchased skill encodes a purchase workflow, its provenance is a spend-control question. The Claude Code handbook makes the same point categorically, treating third-party skills, plugins, marketplaces, channels, and MCP servers as software supply-chain dependencies that must be governed as such.

Safety fixes at the model layer can backfire. Agent MechSuits, a study of representation-level safety steering for multi-turn CLI agents, reports a substantial safety gain with a generation-quality cost. Averaged across the evaluated models, steering cut the attack success rate from 85.99% to 13.36%; the same method “increases the average collapse rate to 18.54%, compared with 2.24% for the vanilla agent,” (Agent MechSuits) producing “degenerate outputs rather than clean safety-aware refusals.” The tempting shortcut this tests: instead of gating the tool, tune or steer the model to be more careful. In this result the steering did suppress harmful actions, but it refused by degenerating output rather than declining cleanly. The mechanism is different from a spend gate, but the lesson transfers: suppressing a dangerous action is not the same as refusing cleanly, and an approval boundary needs a refusal the operator can read.

One more contrast clarifies the boundary. Model-to-model review is genuinely useful elsewhere: Claude Opus 4.7 reviewing Codex GPT-5.5 drafts raised pass rates from 71.6% to 89.7%, and self-review reached 84.5%, in a study of cross-model code review. But that mechanism operates on code correctness, where a second model can check the work. Nothing analogous exists for purchase approval in this evidence: a second model asked “should we buy this domain?” is still a model, still unenforced, and still one layer too high. Capability cannot substitute for an enforced gate on irreversible actions.

Mapping agent actions to gating mechanisms

The decision framework falls out of the evidence above. Classify each action your agent can take by reversibility and blast radius, then assign the weakest mechanism that is still enforced for anything irreversible.

Two of these rows deserve the supporting patterns behind them. For routing judgment to a person, Human Tool models “humans as MCP-style callable interfaces that can be selectively invoked when human judgment, creativity, or contextual reasoning provides comparative advantage.” Approval becomes a tool call the agent makes, not a mood it has. For separating what the model proposes from what executes, TDD Governance describes “a layered architecture that separates model proposal from deterministic engine authority,” formalized in a machine-readable manifesto across planning, generation, repair, and validation stages. That is the same separation the domain-purchase gate implements: the agent proposes, a deterministic component disposes. Interactive confirmation also has precedent at the requirements stage of agent workflows, as in the Shift-Up framework, where an assistant elicited requirements from humans before downstream phases ran.

The evidence supports full autonomy only for the top rows: actions where a wrong choice costs a redo, not a charge.

Audit questions before you trust any of it

For each gating mechanism you adopt, these are the questions the evidence says to ask:

Interactive confirmation

• Does the confirmation reach a human out of band, or can the agent answer its own prompt in the same session?
• What happens on timeout: safe default refusal, or proceed?

Structured refusal with next commands (the vercel domains buy pattern)

• Is the refusal machine-readable, so the agent relays it faithfully instead of paraphrasing?
• Do the suggested next commands require an explicit human action, or could the agent execute them itself? If the “next command” is something the agent can run, the gate is decorative.
• Does the vendor document renewal and pricing behavior, or only the first purchase?

Action-layer budget caps

• Is the cap enforced in the code that selects the next action, per EcoAgent-Bench’s requirement, or merely shown to the model?
• What is the unit of the cap: dollars, tokens, calls? Priced actions need priced caps.

Skill governance

• Where did the skill come from, and is it a verbatim copy of something upstream? Half of GitHub’s SKILL.md files are.
• Can you pin and diff it like a dependency, and would you notice when a clone group drifts (only 11.1% of changes stay consistent, per Skill Constellations)?

The bypass question, for every mechanism

• Does the agent hold raw API credentials that route around the gated CLI? Whether the gate survives a raw API call with a token you already hold is undocumented; audit for it. An enforced gate on one client is advisory if the agent can reach the same endpoint with a token you handed it for another purpose.

What this evidence cannot establish

Be precise about the limits, because they change how much weight the framework carries:

• The central worked example is vendor-asserted: one changelog, with no independent test of the structured refusal, no usage data, and nothing beyond the purchase-time auto-renew option on renewals or pricing edge cases. Re-verify the flow yourself before treating it as load-bearing.
• No cited source documents an equivalent gate in Cursor or Codex CLIs. The framework applies to them; the worked example does not.
• The supporting research is benchmarks and taxonomies, not tests of vercel domains buy. EcoAgent-Bench measured budget behavior in 304 benchmark tasks (EcoAgent-Bench); it did not measure production agent spending.
• The MechSuits result (a collapse rate of 18.54% versus 2.24%, alongside an attack-success reduction from 85.99% to 13.36%, Agent MechSuits) is evidence that model-layer steering trades harmful actions for degenerate outputs, not evidence about spend gating specifically. It qualifies the case for model-layer fixes; it does not prove interface gates work.

Where the approval belongs

Gate agent spending at the tool interface, not the prompt. For any money-moving action, require interactive human confirmation or a structured non-interactive refusal with suggested next commands. Enforce budget caps inside the action-selection layer, where the measurements say they must live. Govern agent skills as supply-chain dependencies, because that is what the copy-drift data says they are. Keep prompt-level rules, but treat them as advisory documentation of intent, useful for the common case and irrelevant in the failure case that matters.

My judgment, with the limits stated: if your agent today operates under a prompt line like “do not make purchases,” you have instruction where you need enforcement, and the handbook’s taxonomy says that conflation is the most common way control is lost. I would not wait for an incident to move that boundary. The cheapest version is a wrapper that refuses paid commands non-interactively and emits the next step for a human; you do not need a vendor to ship it, though the Vercel changelog suggests vendors are starting to understand that the ones who do will have the better answer to a question every team running agents is about to be asked: who said yes to this charge?

Frequently Asked Questions

How does the Vercel CLI handle domain purchases when run by an agent without a human present?

According to the changelog, when the command runs non-interactively, as it would inside an agent loop, the tool declines rather than charging: vercel domains buy “returns a structured, machine-readable error and the suggested next commands, so the agent hands the confirmation back to you, prohibiting it from spending money without your approval.”

Why are prompt-level budgets considered insufficient for controlling agent spending?

The finding: “merely exposing a budget in the prompt is insufficient; budget awareness must enter the action-selection rule itself.” The response was “weak and sometimes reversed”: the sweeps compared tight, medium, and loose budgets rather than budget versus no budget, and the clearest reaction ran the wrong way, with Gemini raising unnecessary deep-research use to 19.4% at the loose budget on tasks where cheap evidence already sufficed (EcoAgent-Bench). A budget stated in natural language is information the model can use or ignore; a budget wired into the code that selects the next action is a constraint it cannot.

What is the primary risk associated with using third-party agent skills for purchase workflows?

Within ten months the format appeared in 259,596 repositories holding 1,612,846 distinct skills (Skill Constellations), and half of all SKILL.md files on GitHub are verbatim copies of another file. Only 11.1% of changes to a clone group stay consistent across every observation window (Skill Constellations), and consistency collapses once a group spans several owners. The practical consequence: the “same” skill your agent runs today may diverge from the copy you reviewed, and the skill executes with your permissions. If a purchased skill encodes a purchase workflow, its provenance is a spend-control question.