An AI agent that can pay for things is useful. An AI agent that can pay for anything, in any amount, at any moment, is a risk waiting for a bad day. The common way to give them that power is to hand over a card number or load a hot wallet and hope the software behaves. Hope is a weak security model.
There is a better pattern, and it already works on Bitcoin Cash. Instead of trusting the agent to respect a budget, the owner can lock the budget into a contract that enforces the limit at the protocol level. The agent can spend what the contract releases and nothing more. If the agent has a bug, follows a malicious prompt, or has its key stolen, the damage stops at the cap.
Why the Limit Belongs in the Money Itself
Most agent frameworks let a developer write a spending rule in application code, such as a daily maximum. That rule lives in the same process as the agent. If the process is compromised, the rule goes with it. A prompt injection only needs the agent to hold a key that can sign.
A limit enforced by the network is different. Every node checks the rule when a transaction is broadcast, and a transaction that breaks it is simply invalid. No amount of clever prompting changes that outcome. The agent key becomes a narrow permission rather than full ownership of the funds.
The Trouble With a Hot Wallet and Good Intentions
A plain hot wallet gives the agent one powerful key, and whoever holds it can move the entire balance in a single transaction. Owners try to reduce the risk by keeping the balance small and topping it up by hand, which works until someone forgets or automates the top up with the same weak controls.
Cards on file have a similar shape. The limit is usually far higher than the task requires, disputes take weeks, and the number can leak through logs and third party services. Neither approach separates the right to spend a little from the right to spend everything. That separation is exactly what a covenant provides.
What CashScript Brings to the Table
CashScript is a high-level language for writing smart contracts on Bitcoin Cash. It compiles to Bitcoin Cash Script, the native stack language that every node already validates. Developers write readable contracts with named functions and require statements.
The key capability is native introspection, added to Bitcoin Cash in May 2022 and extended with token introspection in the CashTokens upgrade of May 2023. Introspection lets a contract read the transaction that is trying to spend it, including the value and destination of every output.
Covenants in Plain Terms
The CashScript covenant guide defines a covenant in one sentence: a constraint on how money can be spent. A contract can require that an output goes to a specific address, carries a specific amount, or returns the leftover balance to the same contract. If the spending transaction does not match, it fails validation.
For an agent budget, the owner can write rules such as these and have every node enforce them:
- No single payment may exceed a fixed number of satoshis.
- Payments may only go to approved service addresses.
- Whatever is not spent must return to the contract.
- A new allowance unlocks only after a set period.
- The owner can reclaim the full balance at any time with a separate key.
The Allowance Pattern: Mecenas for Machines
The CashScript documentation includes a well known example called Mecenas, originally written by Licho. It sets up a recurring payment: the recipient can claim a fixed pledge once per period, and the remainder must go back to the contract. The funder holds a separate key that can reclaim everything.
Applied to an agent, the design is clear. The owner funds the contract and keeps the reclaim key in cold storage. The agent hot wallet is the recipient. Once per period, the contract releases one pledge, and the agent pays for services out of that small balance. Even if the agent wallet is fully compromised, an attacker can take at most what has already been released.
Per Payment and Per Period Limits
Mecenas gives a per period limit through a relative timelock. The contract checks its own age, so a new claim is possible only after the period has passed since the last one. The guide also describes a streaming variant that keeps state in a CashTokens NFT commitment, so the allowance accrues per block and can be claimed at any time.
A per payment cap is a small variation. The contract lets the agent key sign a spend, then requires that the payment output stays at or below a maximum and that the change returns to the contract. On its own, that cap can be bypassed by many payments in a row, so it works best combined with a time condition. Layering the two limits the budget in both size and speed.
Restricting Where the Money Can Go
Introspection also lets a contract compare an output against known addresses. The covenant guide shows an escrow that can only pay the buyer or the seller. The same technique can restrict an agent to a short allowlist of providers, so a hijacked agent cannot redirect funds to an unknown wallet.
An allowlist written into the contract stays fixed unless the design includes an update path, and every update path needs its own protection. Many owners will prefer the simpler allowance model, and the large balance stays protected either way.
Adding x402 So the Agent Pays Per Request
HTTP has included status code 402, Payment Required, since the early web, but it sat mostly unused for decades. The x402 protocol gives it a job. A server answers a request with a 402 response describing the payment it accepts. The client pays, retries with proof of payment in a header, and receives the resource. No account, subscription, or card form is needed.
This suits agents because they make many small requests to many services. Per request pricing lets an agent buy exactly the data or compute it needs, while the covenant keeps the total under control.
Where a Facilitator or Adapter Fits
In x402, a facilitator is a service that verifies and settles payments so the resource server does not handle blockchain details directly. The x402 project, started by Coinbase, centers on stablecoins on networks such as Base, so Bitcoin Cash is best described as a possible rail rather than an officially supported one.
A community project called x402-bch adapts the protocol to Bitcoin Cash with a specification, Express middleware, an Axios client wrapper, and a facilitator server. In that design, the client sends a batch payment to the server and debits against it across later calls, which cuts the number of on chain transactions, and the facilitator validates payments rather than holding funds. For a capped agent, the flow is simple: the contract releases the allowance, the agent funds a batch with a service, and the service draws it down per request.
When Plain BCH Payments Are Enough
For a simple x402 integration, an ordinary Bitcoin Cash wallet is enough. Fees are typically a small fraction of a cent, and transactions propagate within seconds, which suits small payments. Optional CashTokens NFTs can even serve as on chain receipts for prepaid batches, though a local log covers most needs.
CashScript earns its place when the stakes rise. If an agent runs unattended, holds funds overnight, or reads untrusted content from the web, an enforced limit turns a possible disaster into a bounded loss.
A Practical Setup Checklist
This order keeps risk low while a team learns the pattern:
- Write the allowance contract in CashScript and test it on chipnet, the Bitcoin Cash test network.
- Keep the reclaim key offline and away from every machine the agent runs on.
- Set a period and pledge that match real usage, such as one day of expected API calls.
- Account for the miner fee, since the guide examples use a hard coded fee value.
- Connect the agent wallet to x402 services through a reviewed facilitator or adapter.
- Log every request and payment, and compare the logs against contract releases.
Contract code deserves careful review. A mistake in a covenant is enforced just as strictly as a correct rule, so audits and small test deployments are worth the time.
Freedom Tech Without the Card on File
This approach is freedom technology in a practical form. The owner keeps self custody of the main balance. No processor sits in the middle deciding whether an agent may buy a dataset, and no card number spreads across vendor databases.
The rules are public, the enforcement is open, and the owner can take everything back at any moment. Instead of asking permission from a platform, the operator sets the limits directly and lets mathematics hold them in place.
Giving an AI agent money does not have to mean giving it the keys to everything. A CashScript covenant can release a fixed allowance, cap each payment, and return the rest to a contract the owner controls. Paired with x402 style per request payments, the agent can buy what it needs from open services while a buggy or hijacked agent stays boxed in by rules that every node enforces. Start small, test on chipnet, and let the contract carry the trust.
This article is educational and is not financial or legal advice.
