Agent allowlists for spend and publish

Agent allowlists for spend and publish is a proposal that AI agents able to spend money or publish content should run under simple, human-written allowlists that name exactly which payees, amounts, sites, and actions are permitted, so agents can act on their own without risking runaway spending or harmful posts. The idea is one shared configuration layer that covers both money and permanent publishing. Operators would get one place to set limits, review logs, and revoke access.

The problem

AI agents are starting to hold wallets, call paid APIs, and push edits to Git repositories and wikis. Each of these actions has real consequences. A payment on a permissionless rail such as Bitcoin Cash cannot be reversed by a support desk. A post that reaches a durable network such as Arweave may stay public for good.

Today, the limits on these actions are often scattered:

Spending limits live in a wallet, an API dashboard, or nowhere at all.
Publishing rights live in bot passwords, Git tokens, and site permissions.
Rules about review are written in a prompt, where a model can misread or ignore them.

When limits are scattered, nobody can answer a simple question: what is this agent allowed to do right now? A bug, a confused model, or a malicious instruction hidden in a web page can then lead to repeated payments or unwanted posts before a human notices. The OWASP project for large language model applications lists this risk as "excessive agency."

What an allowlist contains

An allowlist is a short file that a human writes and signs off on. Anything not named in the file is denied. A useful allowlist would contain:

Approved payees and addresses. The exact wallet addresses, accounts, or service endpoints the agent may pay.
Per-transaction and daily caps. A maximum for any single payment and a maximum total per day, in a stated currency or unit.
Approved publishing destinations. A specific wiki, namespace, repository, branch, or social account, named precisely.
Approved content types. For example, draft articles, edits to existing pages, or commit messages, and nothing else.
Required human review triggers. Conditions that pause the agent and ask a person, such as a payment above a threshold, a new payee, or any move from draft to permanent storage.
Expiry. A date after which the allowlist stops working, so forgotten permissions do not linger.

The file should be readable by a person in under a minute. If it needs a lawyer or an engineer to explain it, it is too complicated.

A simple example

The policy below is for an agent that may pay small amounts in Bitcoin Cash to a wiki for posting, and may publish only to IdeaWaza drafts. Addresses are placeholders.

agent: ideawaza-draft-helper
owner: wiki editor (human)
expires: 2027-01-31

spend:
  currency: BCH
  payees:
    - name: IdeaWaza posting fee
      address: bitcoincash:EXAMPLE-ADDRESS
  max-per-payment: 0.001 BCH
  max-per-day: 0.005 BCH
  new-payee: deny

publish:
  site: https://ideawaza.com
  allowed-namespace: Draft
  allowed-actions:
    - create draft page
    - edit own draft page
  denied-actions:
    - edit main namespace
    - delete any page
    - upload files
  permanent-archive: deny

review:
  pause-and-ask-if:
    - payment above max-per-payment
    - any request outside this file
    - draft marked ready for main namespace

log:
  record: every payment and every edit
  location: public log page

Anyone reading this can tell what the agent may do, what it may not do, and when it must stop and ask.

How it could work

An allowlist only helps if something outside the model enforces it. Several existing mechanisms could serve as enforcement points:

Wallet-level limits. The agent receives a dedicated wallet funded with only a small balance. Even total failure cannot spend more than that balance.
Spending keys with caps. A signing service holds the real key and signs only payments that match the allowlist, refusing anything else.
Smart contract covenants. On Bitcoin Cash, contracts written in CashScript can restrict where coins may be sent and how much can move at once. On Ethereum, contracts written in Solidity can enforce similar rules. These are general mechanisms; each deployment would need careful review.
HTTP payment flows. Protocols such as x402 use the HTTP 402 "Payment Required" status so that a service can ask an agent to pay for a request. A local proxy could check each payment request against the allowlist before paying.
Publish gates and review queues. Agent edits go to a draft namespace, a pull request, or a pending queue. A human approves the move to a main page or permanent archive.
Public logs. Every payment and edit is written to a log that the owner and the community can read. Logs make problems visible early and make trust easier to earn.

The same allowlist file could drive all of these. A wallet service, a publishing proxy, and a review queue would each read the file and enforce the parts that apply to them. Revoking access would mean changing or expiring one file.

Why allowlists instead of blocklists

A blocklist names what is forbidden and permits everything else. For agents, that approach fails in predictable ways:

Nobody can list every bad payee, scam address, or harmful site in advance.
New risks appear faster than lists can be updated.
A single gap in the list is enough for a costly mistake.

An allowlist starts from zero and grants only what is needed. This follows the security principle of least privilege, which NIST describes as restricting the access privileges of users, or processes acting for them, to the minimum necessary to accomplish assigned tasks. If an agent tries something the owner never thought of, the default answer is no, and the agent asks a human.

Limits and open questions

Allowlists reduce risk but do not remove it. Open questions include:

Approved does not mean safe. An agent can still post low-quality or misleading text to an approved draft page. Human review remains necessary.
Enforcement must sit outside the agent. If the model can edit its own allowlist, the list protects nothing.
Format. Should there be a shared format that many tools read, or should each tool use its own? A shared format is easier to audit but harder to agree on.
Price changes. Caps written in a cryptocurrency can change value over time. Caps in a fiat unit need a trusted price source.
Too strict. Very narrow lists may cause frequent pauses, and owners may then approve requests without reading them.
Legal and policy duties. Agents must follow the law and the rules of each site they use. An allowlist is a tool for responsible use, not a replacement for those duties.

This proposal concerns safe operation and is not financial or investment advice.

External links