Step 1
Install the gate
npm install -g buzz-axiru
Node 22 or newer. Apache-2.0, no account, nothing phones home.
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: 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.
Get running
Install to verified gate in five steps.
Everything below is copy-pasteable. One property to hold onto throughout: the gate fails closed. A missing agent identity, a missing key, or a downstream server that will not start refuses to serve rather than run degraded, so a setup that passes verification is a setup that is actually enforcing.
Step 2
Write a starter policy
export BUZZ_AXIRU_AGENT_PUBKEY=<agent hex pubkey or npub> buzz-axiru quickstart --harness buzz
quickstart detects your Buzz shell server, writes a starter policies.json in the current directory, and prints the wiring steps for your setup. It never prompts; every choice has a flag. Edit the caps and the counterparty allowlist to your own numbers before anything goes live.
Step 3
Wire your harness
3a. Raw buzz-acp in a terminal: one export, then restart the agent.
export BUZZ_ACP_MCP_COMMAND=buzz-axiru
3b. Buzz Desktop: that variable is on the app's reserved list, so the export does nothing under the Desktop app. Quit Buzz Desktop completely first (adopt refuses to run while the app is open), then:
buzz-axiru adopt
adopt automates the one wiring path that works under the Desktop app: a custom harness that passes --mcp-command as a command-line flag. It shows you the change and asks before writing anything. Reopen Buzz, check the custom harness's model setting matches the model your agent should run (a custom harness carries its own model choice), and restart the agent.
Known Buzz Desktop limitation
Buzz Desktop currently has no working setting for an agent's MCP command. The BUZZ_ACP_MCP_COMMAND variable is on the app's reserved environment list, and setting mcp_command in the app's managed-agents.json does not hold either: the Desktop app supplies its own value for the same variable, and its value wins the duplicate-env race. What works is a custom harness that passes --mcp-command as a flag, which buzz-axiru adopt sets up for you. This workaround is required until Buzz Desktop exposes this setting.
Step 4
Verify from the outside
buzz-axiru quickstart --check
Loads the config, starts every configured downstream server exactly the way serve does, and reports identity, tool coverage, and spend controls. buzz-axiru doctor runs the same diagnosis. NOT READY is a real answer: fix it before the agent goes near real money.
Step 5
Verify from the inside
Ask the agent itself, in its channel, to call its axiru_gate_status tool and report what it sees. An agent behind the gate answers with the gate's identity and policy state; an agent that cannot call the tool is not wired through the gate, whatever the config says.
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. 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. And the gate fails closed: a missing key or a downstream server that will not start refuses to serve rather than run degraded.
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. buzz-axiru verify checks the chain end to end from the CLI.
A human approval queue
Parked calls wait for a person: buzz-axiru pending lists them, approve grants them, and reconcile resolves an ambiguous approved execution with provider evidence instead of retrying it into a possible duplicate payment. Approval requests can be posted into a Buzz channel via the buzz CLI, so the humans see them where the agents already talk.
Behind the slot, the gate is an enforcement point, not an advisor: the downstream payment server runs behind the proxy, its credentials never enter the agent's environment, and a denied call never reaches it. There is nothing for the agent to fall back to. 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, and the Buzz Desktop wiring findings above are field-verified against the current Desktop app. 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. The same gate also wires into Claude Code and Codex.
Start in shadow mode first. Move to live enforcement later.