A nightly batch job classifies internal documents, some of which contain personal data. It has a named owner. It runs in the organisation's cloud account, in an approved region, with a contracted provider. Its logs reach the platform team, and a failure pages their on-call engineer.
An orchestration agent schedules the job. It has a tool that queries a compute marketplace, and authority to pay. One evening it finds GPU capacity from a provider the organisation has never used. The hourly rate is lower, the hardware is newer, and the listed location is in another country. The agent is set up to finish the job within its window at the lowest cost, so it prepares to move the job.
The owner approved where this job runs and with whom. Nobody approved this choice. The owner needs to know several things before it goes ahead.
What BlackRock describes
BlackRock's September 2026 paper The Machine-Native Economy describes a possible future. In it, agents query real-time compute marketplaces, compare available capacity on price, performance, latency, location and hardware, and then provision whatever best suits a given workload (p. 9).
The paper is careful about how far along this is. It describes agentic payment activity as nascent and compute-market liquidity as limited (pp. 9–10). It also says contract-design and market-structure problems still have to be worked out, including standards for settling and delivering contracted capacity (p. 8).
The paper's main interest is digital-asset markets, and I will leave that side alone. The infrastructure question is narrower. If an agent can find and pay for capacity, an existing approval can be reopened by the agent's next purchase: this workload, this owner, this region, this provider. That can happen without anyone revisiting the decision.
Comparing capacity and committing to it
When the agent compares options, it reads price, performance, latency, location and hardware. When it buys, the organisation accepts much more:
- where data and intermediate files are processed and stored
- who at the provider can reach them
- what the contract says about deletion and liability
- what support exists at 2 a.m.
- what transfer, storage and minimum-commitment charges apply
- who is responsible if the capacity disappears halfway through a job
A listing may show some of this. The agent's ability to read those terms does not mean anyone has approved them.
Recommending capacity is useful work. Being authorised to commit the organisation to that capacity is a different permission. It needs a defined boundary and an accountable owner before any agent holds it.
Trace the purchase before trusting the price
The assumption I would worry about most is: "Our existing cloud controls will cover this." Region policies, spending caps, identity boundaries, logging and incident routing are usually attached to the organisation's own cloud accounts. A purchase made through an outside marketplace, or paid through a separate payment route, may never pass through them, while the workload owner assumes it did. This is a failure mode to examine. It is not a report from any environment, and I am not predicting it will always be the first thing to go wrong.
The practical test is to follow one proposed purchase through five checkpoints.
Who authorised it? Does the limit on the agent's authority still apply when its payment tool reaches an outside marketplace?
Where does the charge appear? Can finance reconcile it to this workload and its owner? Or does it land on an account nobody checks against the job?
Where does the workload run? This means the data, intermediate files and outputs, including any copies left behind after the job ends.
What does monitoring receive? Do logs and metrics from the new capacity reach the responsible team? Or does the job go quiet?
Who gets the incident? If the capacity is withdrawn at 3 a.m., is an accountable person alerted? And do they have the access and a documented way to finish the run?
If the answers hold after the move, automation may be reasonable. If they disappear at the edge of the organisation's account, the lower rate is beside the point. Passing the test does not settle every legal, contractual or operational question. It shows whether the organisation can still see and control the workload after the agent has moved it.
What stops a move, and what can be managed
Some of the questions a purchase reopens are boundaries. A cost saving should not override them without review.
Location comes first. If data or processing would leave an approved location, a person with authority over that boundary reviews it before the move. In the hypothetical, the listed country ends the discussion until that happens.
Access is next. I would stop the move if the provider needs permissions, credentials or data access that have not been approved and tested.
Operational ownership matters for production. Someone must own the response when the capacity fails, and the route back to an approved option.
Authority to spend has to cover total exposure, not just the advertised rate. Storage, data transfer and minimum commitments can turn a cheaper rate into a larger bill. An alert after the money is spent is not a cap.
Other questions can be managed with conditions.
Performance can be trialled against what the workload actually needs, which for this job means finishing inside the batch window. The trial needs a stop or recovery path that suits the workload, because automatic rollback is not always possible:
- A stateless batch job can often be stopped and rerun on approved capacity while time remains.
- A job that writes state as it goes needs a tested way to reconcile or discard partial output.
- Where there is no credible way back, the trial becomes a hard stop.
Support can scale with impact. An experiment does not need a production support contract. An important service needs an escalation path that matches the cost of an outage.
Cost variation is acceptable if total cost is measured, a cap is enforced and someone reviews the result.
When existing controls are enough
Organisations already let some automation act without a person approving each decision: autoscaling, schedulers that choose spot or preemptible capacity, and tools that buy capacity commitments. None of these is safe by nature. They can reasonably operate without per-decision approval when five conditions are defined and enforced:
- the provider
- the location
- access
- spending exposure
- recovery
When an agent's choices stay inside boundaries like these, requiring a human click on each one would add delay without adding control.
The argument stops holding when the agent can create a commitment outside that boundary. My rule is: automate selection within an approved set, and require review when a selection would change the set or its terms.
Within the set, dynamic prices are acceptable if total exposure is bounded and enforced before purchase. An agent may also propose a new provider, and gathering the evidence for that addition is work it can do well. The provider must still pass the organisation's approval criteria before the agent commits a production workload to it.
Two workloads, one rule
A small experiment. A data scientist wants to benchmark a model on synthetic data. Nothing personal or confidential is involved, there is no production dependency, and a small spending cap is enforced before purchase. For work like this, the organisation can pre-approve a broad class of providers and terms. For example, it could approve any provider that meets a defined minimum profile, accepts a standard set of terms, bills through a route finance can reconcile, and never receives real data. Best-effort support is fine, and recovery means stopping. A rule that forced a procurement review here would be the wrong rule. This one gives the agent real freedom because the requirements are light and can be enforced.
The production batch job. Here the approved set is narrow, and the new provider sits outside it. The agent can flag the provider and assemble the evidence for assessment. Tonight's run stays where it is. If the provider is later approved and added, future runs can use it without anyone clicking approve.
The wording of the rule is the same for both jobs. What differs is how large the approved set is, and what it costs to get into it.
The strongest objection
Suppose a marketplace publishes standardised, machine-readable terms: processing location, certifications, support tier, deletion commitments, a price ceiling. Why should anyone review the provider individually, rebuilding the procurement delay the agent was meant to remove?
The objection is partly right. What matters is whether requirements are met before the commitment is made, not whether a person pressed "approve." But three different things need to be kept apart:
- A machine-readable claim is what the provider says about itself.
- Qualifying evidence is what the organisation relies on to decide whether a provider belongs in the approved set, such as an audit report, an attested configuration or a contract clause. It supports a judgement made in advance. It does not, by itself, make any individual purchase comply.
- A purchase-time control is what keeps each transaction inside the set. Examples are a hard spending limit, a block on unapproved regions, or a rule that the agent can pay only providers already on the list.
A provider can be qualified by evidence and then bought from automatically, but only through controls that enforce the boundary at the moment of purchase. A price ceiling or a region restriction may be enforceable that way today. How a provider escalates support, or deletes data in practice, is much harder to verify or enforce by machine, and BlackRock's own paper treats contract and delivery standards as unfinished. Where claims, evidence and controls line up, policy can be the review. Where they do not, the gap keeps the provider outside the approved set until someone assesses it.
A question for your own environment
Agents buying compute is still a developing possibility. The failure mode described here can arise wherever an automated process is allowed to commit spending on terms outside its original approval.
Before an agent in your environment gets a payment tool, take one real workload and one plausible cheaper offer. Then ask the five questions for a purchase the agent might make tonight:
- Would the agent's authority to spend still be limited when it reaches the marketplace?
- Could the charge be reconciled to the workload and its owner?
- Would the data and processing stay within an approved location?
- Would monitoring reach the responsible team?
- Could an accountable person respond to an incident and recover the run?
The purchase may go through different systems from the job it replaced, and that is acceptable. Where any answer is no, the agent should recommend the capacity and wait for review.