You give an AI $100 and a job.
Find the best replacement part for a machine. Check that it fits. Buy it from an approved supplier. Keep the design files private. Have an answer before lunch.
Would you walk away?
Some people would already be reaching for the power switch. Others would wonder why the budget is so small. What interests me is the moment a useful recommendation becomes an action someone else has to live with.
Now change one detail. Halfway through the job, the inspection record supporting the purchase is withdrawn.
The AI still has the money. It still has the instructions. It has already found a part that appeared to qualify. It may even have a signed permission to buy it.
Should the purchase still go through?
That is the question I want to explore: giving AI useful authority over money, data and services, while keeping that authority tied to current rules and evidence.
I build 8DB at 8Braid. Digital Fabric is an application we have built around governed transactions and entitlements. The scenario in this article is a thought experiment about where that foundation could go. It is also an invitation to identify the cases that would break it.
A budget is only the first boundary
The $100 limit is easy to understand. It is also an incomplete description of what you meant.
You did not mean that the AI could spend $100 on anything. You meant that it could complete a particular job, using certain information, through suppliers you accept, under conditions you consider reasonable.
A $30 purchase from the wrong supplier can violate that instruction. So can a free service that uploads your proprietary design files. Staying under budget would make neither action acceptable.
The useful unit of permission is therefore more specific: this agent may perform this action, for this purpose, against these resources, within these limits. The system accepting the action needs to check those conditions against the relevant state.
We already expect software to enforce limits on accounts and transactions. Agents make the surrounding context more complicated. They can interpret documents, choose tools and construct workflows that nobody listed step by step in advance. That flexibility is the attraction. It also creates more ways for an apparently sensible plan to exceed the authority behind it.
Payment protocols are developing around this problem. AP2 specifies signed mandates and deterministic verification. Stripe and Tempo's Machine Payments Protocol addresses programmatic payments. These are substantial pieces of the emerging infrastructure. They also give us existing protocols to work with. AP2 specification, MPP introduction.
The question for a system around them is how the permission stays connected to the conditions that justified it.
What changes while the agent is working?
Return to the replacement part.
At 9:00, its inspection record is accepted. At 9:10, someone discovers that the measuring instrument was out of calibration and withdraws the record. At 9:11, the AI tries to buy the part.
If the purchase requires a currently accepted inspection, the old result should no longer authorize a new purchase. The system needs to recognize which dependency changed and what that means for this action.
An explanation written after the purchase would be useful for an investigation. A check at the point where the action is accepted could prevent the purchase in the first place.
This is one way infrastructure could reduce the consequences of AI errors in real time. The model can propose an action. A separate, deterministic process evaluates whether the action is allowed. The effect depends on the completeness of that process and the reliability of its inputs, so a confident model response is never enough to supply missing evidence.
There is a second complication. Suppose the part has already been ordered under an agreement that created a payment obligation. Withdrawing permission for future purchases does not automatically erase that obligation. The rules need to distinguish authorization, reservation, acceptance and settlement. Otherwise, a feature described as a safety mechanism could become a way to avoid paying for work already commissioned.
Recent research makes this a timely issue. An August 2026 preprint, Beyond the Mandate, examines how valid payment signatures can coexist with manipulated context before authorization. Another recent preprint analyzes how delegated authority must remain consistent with economic and service effects across agent payment protocols. These are research findings about specified models and testbeds, rather than a verdict on every deployment. They identify questions an implementation should be able to answer. Beyond the Mandate, A Formal Analysis of Agent Payment Protocols.
The objection I take seriously: who controls the rules?
There is an obvious objection to all of this.
If software can stop my AI from spending money, reading data or using a service, someone has gained a powerful control point. Calling it governance does not tell me whether that power serves me.
I think that objection belongs in the design conversation from the beginning.
A person choosing a spending limit for their own assistant is exercising control. A platform silently changing the allowed choices may be taking control away. Both could use similar enforcement machinery. The difference lies in who grants authority, who can alter it and what the affected person can do about a refusal.
For the applications we want to build, I would want an owner to be able to inspect the rules, understand a refusal and know which party has the authority to change the decision. If an important fact is disputed, the system should preserve that dispute and offer the defined review path. A neat audit trail cannot make an unfair policy fair.
Privacy belongs in the same conversation. A reviewer might need to check that an allowance was respected without receiving every document the agent considered. The parties need appropriate views of the evidence. Cryptographic integrity, access control and zero knowledge establish different things; choosing a mechanism requires saying what should remain hidden from whom. Our proofs guide explains those distinctions.
Nor should we promise a remote undo button for data. Revoking access can stop subsequent operations through a controlled path. It cannot make an agent forget information that has already been copied out. Keeping computation with the data holder can change that exposure, but the execution environment and permitted outputs still matter.
The standard I would like us to meet is simple to state and demanding to implement: the person granting authority should retain meaningful control, and the person affected by a refusal should have a way to understand and challenge it.
Why this becomes a database problem
The purchase depends on several kinds of information at once: the shape of a part, its inspection history, a supplier relationship, an agreement, an allowance and the current status of supporting evidence.
In 8DB, we are building these capabilities into a common data environment. Digital Fabric demonstrates transaction and entitlement mechanisms on that foundation. The broader database also works with native modalities such as graphs, time series and geometry, alongside governance, protection and provenance. The point is to keep the information needed for a decision connected. Native modalities, programmable transactions.
Our existing components include signed scope, budget and expiry constraints; agreement checks before entitlement redemption; and records of consumption and supporting evidence. The proposed workflow in this article would have to establish that those pieces work together correctly under concurrent requests, changed permissions and interrupted execution.
A conventional architecture can implement these controls too. The comparison worth making is whether putting the relevant state and evidence in one governed environment reduces duplicated policies, synchronization work and opportunities for inconsistent decisions. That is a measurable engineering question.
This connection could support more than purchases. A data owner could grant twenty executions of an approved analysis. A research team could commission an artifact with a specified acceptance checker. A machine could request a service only while its inspection and operating conditions qualify. Money is one resource an agent can consume. Data access and permission to act deserve the same care.
A small experiment with an inconvenient failure case
Before making a large claim, I would start with a deliberately small test.
Two workers each request 60 units from a shared simulated allowance of 100. Each request includes an artifact checked against an agreed, deterministic acceptance rule. For this test, submission creates no payment obligation; an accepted request allocates the allowance. Only one can fit.
The result identifies the input data revision and the checker used. Its acceptance must also agree with the current authority and consumption state. Then we introduce the situations that make a clean diagram messy:
- Both workers submit at the same time.
- One retries because it never received an acknowledgement.
- The process stops between checking the result and recording consumption.
- Required permission changes after computation but before acceptance.
- A result fails the checker, then a corrected submission arrives.
The test should establish which submissions are accepted, why, and what was consumed. It must also show that legitimate work can finish. A system that rejects everything would protect the budget while defeating the purpose of having an agent.
This experiment is proposed work, not a result we are claiming today. We would compare it with a properly transactional, server-authorized implementation and measure correctness, recovery, integration effort and overhead. We would keep actual external payment settlement separate until its reconciliation behavior was tested too.
Passing would establish something useful about that defined workflow. A failure would give us a concrete problem to fix or a limitation to publish.
Where would you draw the line?
I want AI to be useful enough that people can give it a job and get on with their lives. Requiring approval for every trivial step makes that harder. So does asking people to accept unrestricted access as the price of convenience.
Authority with explicit conditions offers a direction worth exploring. It could let us delegate more while preserving the ability to inspect, limit and contest what happens. It could also be implemented badly, concentrating control or making ordinary work needlessly difficult. The technical and human choices determine which future we get.
Here is the feedback I would find most useful: describe one action you would allow an AI to take without asking again, and the condition that should make it stop.
Send me your action and stop condition. A few sentences are enough. Please use a hypothetical or non-confidential example. I will ask before attributing or quoting a private reply.
Ashley Dunfield is the founder and CEO of 8Braid Inc. This is the opening article in AI With Authority, a series exploring what it would take to give agents useful, bounded permission to act.
Continue the series: The Dataset Doesn't Have to Change Hands and I Would Pay for a Good Counterexample.
Continue the technical conversation
Where could this help your work?
Bring a research question, a database workload or an application you want to build. Let’s connect the ideas in this article to an evaluation that matters to your team.
Discuss this work