Open source · For Buzz · Apache-2.0

Buzz agents get spending tools before they get spending limits.

Point a Buzz agent at a payment MCP server and it holds every tool that server exposes. buzz-axiru sits between the agent and those tools as a gating MCP proxy: a deterministic local policy decides allow, deny, or park for human approval before money moves, and no LLM is anywhere in that decision path.

The one-slot problem

One MCP server per agent. Shell or domain tools, not both.

buzz-acp gives each Buzz agent exactly one MCP server, so the slot is an either/or: the shell tools the agent posts to channels with, or a domain server with the tools it actually works with. buzz-axiru is a proxy, so it fans out behind the slot: as of v0.3 it spawns several downstream MCP servers, merges their tool lists, and intercepts only the payment-class calls. The agent keeps its shell, gains its payment tools, and every payment answers to policy.

Buzz's trust model is deliberate, and the gate does not work around it. It occupies the slot Buzz provides and adds the authority layer inside it: whether this agent may make this payment, decided before the downstream server ever sees the call. The single-slot design is tracked upstream at block/buzz#2899.

Install

One package, wired into the slot Buzz already gives you.

Install the gate globally, point the agent's MCP slot at it, and bind each gate instance to its agent's identity so caps and decisions attach to the right pubkey. The policies.json format, the downstream server configuration, and the full wiring walkthrough are in the repo README.

npm install -g buzz-axiru

# Wire the gate into the agent's single MCP slot
export BUZZ_ACP_MCP_COMMAND=buzz-axiru

# One gate instance per agent, bound to that agent's identity
export BUZZ_AXIRU_AGENT_PUBKEY=<agent hex pubkey>

Read the README on GitHub → · buzz-axiru on npm →

What you get

A policy gate, a ledger, and a human in the loop.

The gate ships with preset controls in policies.json: a per-agent daily cap, a single-payment ceiling that routes to a named approver, a counterparty allowlist, business-hours routing, and a velocity count cap. Around them, four properties do the real work.

A gating proxy in the single slot

The gate occupies the agent's one MCP server slot and intercepts payment-class tool calls. As of v0.3 it multiplexes several downstream MCP servers behind that slot, merging their tool lists, so the agent keeps its shell and gains its payment tools at the same time.

A deterministic decision path

Pure local policy evaluation decides allow, deny, or park for human approval. No LLM in the decision path, no network call to decide, no account, no custody of funds or keys.

A hash-chained decision log

Every decision lands in an append-only log with a SHA-256 hash chain, keyed to the agent's Nostr pubkey. The chain is verifiable end to end from the CLI.

A human approval queue

Parked calls wait for a person: list them, approve them, or deny them from the CLI, with approval requests optionally posted into a Buzz channel via the buzz CLI so the humans see them where the agents already talk.

Scope, stated plainly: the gate governs the tools routed through it, nothing else. An agent holding raw payment credentials in its environment is outside the gate's authority.

Try to break it

The three prompts to throw at it first.

Do not take the gate's word for it. Give your agent these instructions against a test payment server and watch what the ledger records.

Pay a counterparty that is not on the allowlist

The gate returns a structured denial with a reason code. The payment server never sees the call, and the decision is the last line of the ledger.

Pay an amount above the single-payment ceiling

The call is parked verbatim and the agent gets pending_approval. A human approves or denies it from the CLI; the agent's retry does not execute anything.

Split it into ten smaller payments

The velocity count cap and the trailing daily cap evaluate the aggregate, not the single call. Slicing a payment under the ceiling does not slice it past the policy.

Verified status

What it has been tested against, exactly.

Tested hands-on against Buzz 0.5.5 on macOS, including the multi-downstream slot configuration. Not yet verified against a production payment MCP server; verification so far used scripted MCP servers. The packages are new, and we will not pretend otherwise: issues and hard questions are welcome on GitHub.

Next step

The gate is one package. The whole decision layer is open source.

buzz-axiru runs on the published @axiru/agent-spend-guardrails library, and the rest of the Apache-2.0 set, the spec, the x402 middleware and receipt verifier, and the AGT extension, lives on the open source page.

Start in shadow mode first. Move to live enforcement later.

We use cookies for analytics and marketing measurement. You can reject non-essential cookies at any time.

Privacy policy
buzz-axiru | Payment gating for Block's Buzz agents | Axiru Open Source | Axiru