Under the Surface looks at projects, standards, experiments, and community activity that may not rise to the level of a headline but are still worth noticing. Some are new, some are continuing work, and some are quieter developments that help show what is taking shape across the BSV community.

AI & Agents / Wallet Infrastructure

An autonomous software agent may eventually be able to find a service, decide that it needs the service and pay for it without asking a person to approve every individual transaction.

That creates an obvious question:

How much authority should the agent actually have?

A newly proposed BRC attempts to move the answer into the wallet itself.

Proposed BRC-181, Wallet-Enforced Autonomous-Agent Spend Policy, defines an operator-signed policy that would allow an agent to spend autonomously while preventing it from moving funds outside limits established in advance.

The proposal was opened for discussion on September 22 and remains under review. Its BRC number may still change before acceptance.

The important idea is therefore not the number itself.

It is the separation between an agent being permitted to spend and an agent being given unrestricted control over the wallet that holds the funds.

The operator defines the envelope

Under the proposal, a human operator creates and signs a policy describing what an autonomous agent is allowed to do.

That policy can define several kinds of limits.

A maximum can apply to an individual transaction.

Separate caps can limit total spending over a rolling period or over the entire lifetime of the policy.

Destinations can be restricted through an allowlist.

The policy can also limit transaction frequency, introduce circuit breakers, set an expiry time and define whether certain forms of delegated authority are permitted.

The agent can then operate without asking the operator to approve each transaction individually—as long as every requested action remains within that signed envelope.

The wallet is responsible for enforcing it.

That distinction matters.

The agent is not being trusted to remember the rules or voluntarily obey a prompt telling it not to overspend.

The system controlling the keys checks the rules before allowing the transaction to proceed.

The wallet, not the agent, keeps the spending ledger

Several of the proposal’s more technical requirements are designed to stop an implementation from accidentally weakening those limits.

The wallet maintains counters tracking how much has been spent and how frequently transactions have occurred.

Those counters must survive a restart.

Otherwise an agent could effectively reset a daily or rolling spending limit simply because the wallet process restarted.

The same applies to a freeze or circuit-breaker state. If the wallet has stopped autonomous spending because a defined limit or risk condition was reached, rebooting the software should not silently clear that restriction.

The proposal therefore requires durable state and a monotonic time source for the counters used to enforce policy.

It also specifies an atomic check → reserve → debit process so that several simultaneous spending requests cannot independently pass the same limit before the wallet realizes that their combined value exceeds it.

This is the kind of problem that becomes important only when software begins spending quickly enough that ordinary sequential assumptions no longer hold.

Uncertainty is supposed to fail closed

The proposal also attempts to define what should happen when the wallet is unsure what occurred.

For example, a transaction may have been sent while the wallet loses reliable information about whether the broadcast succeeded.

If the wallet immediately assumes failure and restores the spending allowance, the agent could potentially spend the same authorized capacity again while the original transaction is still propagating.

Proposed BRC-181 therefore takes a fail-closed approach to uncertain transaction state.

When the wallet cannot safely determine whether value has already been committed, it should preserve the restrictive interpretation rather than optimistically reopening the spending capacity.

Similar rules address malformed requests, frozen policies and transaction paths that could bypass the normal enforcement pipeline.

The design is intentionally conservative because a system intended to constrain an autonomous spender has to remain restrictive when its own information becomes incomplete.

This extends ordinary spending authorization

The proposal positions itself alongside several existing wallet standards rather than replacing them.

BRC-116 already provides spending authorization, but proposed BRC-181 argues that an amount ceiling alone is not enough for unattended agents.

Within an authorized amount, an agent could still potentially spend too quickly, send to an unintended destination or exhaust the entire allowance in one action.

The proposed policy therefore adds controls over who can receive value, how quickly value can move, how much can move over time and when the authority expires.

BRC-219 addresses a different case: a wallet has a human available and can present a permission prompt.

That model works well when someone is expected to make the decision.

An autonomous agent may be running overnight, inside a server process or across thousands of small service requests where asking for human approval each time would defeat the purpose of the automation.

Proposed BRC-181 instead lets the human make the higher-level decision beforehand:

You may spend, but only inside these boundaries.

The wallet then applies that decision transaction by transaction.

Revocation remains with the operator

Autonomy is not intended to make the permission permanent.

The proposal includes an immediate revocation mechanism allowing the operator to withdraw the agent’s spending authority.

It also supports policy expiry so that authority can terminate automatically after a defined period.

That creates a useful distinction between giving an agent a private key with unrestricted continuing control and giving it access to a wallet operating under a revocable policy.

The agent can act independently within the policy.

The operator remains the source of that authority.

BRC-166 exposes an unresolved boundary

The proposal is also explicit about one case its current destination model does not handle well.

BRC-166 defines an HTTP 402 payment flow in which a service can generate a fresh receiving address for each invoice.

That creates a problem for a static destination allowlist.

The operator may trust the service, but the particular payment address does not exist when the spending policy is signed.

The payer therefore has no fixed address to place on the allowlist in advance.

Proposed BRC-181 does not attempt to hide that limitation.

Instead, it identifies a possible future direction: authorize a known payee rather than a predetermined destination address, then permit addresses appearing in authenticated invoices subject to separate per-invoice, periodic and rate limits.

That would expand what the operator’s signature authorizes and would need its own threat analysis.

For now, the limitation means the proposal does not fully cover one of the developing payment patterns that autonomous agents may eventually use.

From agent wallets to agent policy

Recent BSV development has increasingly explored how software agents can call wallet infrastructure.

A wallet service can construct transactions, sign messages, perform encryption and expose standardized BRC-100 functions without placing the root private key inside the agent process itself.

Proposed BRC-181 addresses the next question.

Keeping the key away from the agent is useful, but the wallet still needs to decide what requests from that agent it should honor.

A common policy format could make that authority explicit.

The operator defines the limits.

The agent performs useful work inside them.

The wallet enforces the boundary.

That is a different model from either unrestricted machine custody or continuous human approval.

The proposal remains open and may change substantially through review. It is not yet an accepted BRC or evidence that wallets have implemented the policy.

But the problem it addresses is becoming increasingly concrete.

If autonomous software is going to purchase APIs, inference, data, storage or other machine services, the important question will not simply be whether an agent can make a payment.

It will be whether the infrastructure controlling the funds can guarantee that the agent cannot spend beyond the authority its operator intended to give it.

Source: Proposed BRC-181 — GitHub pull request

Update — September 25, 2026