Five packages under the @axiru scope on npm, published from AxiruAI on GitHub. The evaluator that answers whether an agent may spend this money, right now, at this amount, runs entirely in your process: no account, no network calls, nothing phones home.
Agent spend guardrails are a deterministic policy check placed between an AI agent and the payment rail it can reach, so every spend attempt is evaluated against budgets and approval rules before money moves. @axiru/agent-spend-guardrails is that check as an Apache-2.0 library: you declare policies, you pass it a spend intent, and it returns allow, require_approval, or deny with a stable reason code and a SHA-256 fingerprint.
The distinction that matters: this is a control plane, not a prompt. Filtering what an agent is told is not a spend control, because the instructions are exactly what an attacker manipulates. A policy decision the agent cannot talk its way past is.
Everything that runs in your process is free forever. The hosted product is the parts that run on our infrastructure: the multi-rail enforcement (Stripe GA enforcing; Stripe DAA and x402 in shadow; USDC on Solana in early access), the real approval queue, the hash-chained evidence ledger, and the audit evidence packs.
| Capability | @axiru libraries Apache-2.0, in your process | Axiru hosted Runs on our infrastructure |
|---|---|---|
| Policy decisions | Evaluated in your process. Free, forever. | The same decisions, made inside the hosted enforcement path. |
| History and velocity data | You supply the rolling-window aggregates. Free. | Computed for you from ingested activity. |
| Approval routing | A string in a return value; you build the workflow. Free. | A real approval queue with named approvers. |
| Evidence | Logs you keep, in whatever store you choose. Free. | A tamper-evident, hash-chained ledger with SOC 2 mapped evidence packs. |
| Rails | Whatever you wire the library into; it returns decisions and never executes transfers. | Multi-rail enforcement: Stripe GA enforcing; Stripe DAA and x402 in shadow; USDC on Solana in early access. |
Five publish under the @axiru scope on npm, licensed Apache-2.0, from the axiru-oss monorepo. The Buzz bridge is a sixth package in a repo of its own, and it depends on the published guardrails package rather than a workspace link.
Flagship
Policy decisions for agent spend as a pure in-process library. Two functions: defineSpendPolicy and guardAgentSpend. Every call returns allow, require_approval, or deny with stable reason codes and a SHA-256 fingerprint. Zero dependencies, zero network calls, no account, nothing phones home.
Ships with preset policies: humanApprovalAboveAmount, perAgentDailyCap, counterpartyAllowlist, businessHoursOnly, velocityCountCap.
Vocabulary
The shared language the other packages speak: OutboundValueTransfer types, policy schema v2, the rail registry, x402 evidence records, runtime type guards, and the reason-code registry.
x402
Policy pre-authorization around x402 402 challenges, with MPP charge-intent mapping. Fail-closed: if the policy check cannot run, the payment does not proceed.
x402
JWS verification of signed offers and receipts, plus receipt-matches-offer checking. One plain caveat: EIP-712 verification requires bringing your own secp256k1 verifier.
AGT
Axiru extension for the Microsoft Agent Governance Toolkit. Payment-action tool calls route to the Axiru policy engine; non-payment tool calls fall through to AGT's own defaults, so the toolkit keeps governing the runtime and Axiru governs the money.
MCP bridge
A gating MCP bridge for Block's Buzz workspace, in its own repo. A Buzz agent's payment tools route through a policy decision, approvals happen with a human, and every decision lands in a hash-chained local log keyed to the agent's Nostr pubkey.
The whole surface of the flagship package is two functions. Here a 12,000 USD payment crosses a 10,000 USD amount rule and comes back as require_approval, with a stable reason code and a SHA-256 fingerprint you can replay.
npm install @axiru/agent-spend-guardrails
import { defineSpendPolicy, guardAgentSpend } from "@axiru/agent-spend-guardrails";
const policies = [
defineSpendPolicy({
name: "Human approval above 10,000 USD",
rules: [{ kind: "amount", currency: "USD", gte: "1000000" }], // minor units
effect: {
kind: "require_approval",
reason_code: "customer.pending.above_autonomous_limit",
reason_text: "At or above the 10,000 USD autonomous limit"
}
})
];
const result = guardAgentSpend({
intent: {
rail: "x402",
action: "pay",
amount: { currency: "USD", minor_units: "1200000" }, // 12,000.00 USD
agent: { id: "agent_procurement_1", model: "claude-sonnet-4-6", scope: "payments.create" },
counterparty: { id: "https://api.vendor.example/invoices", kind: "merchant" },
timestamp: new Date()
},
policies
});
// result.decision -> "require_approval"
// result.reason_code -> "customer.pending.above_autonomous_limit"
// result.fingerprint -> "sha256:..." replay and idempotency keyExecute the transfer only when the decision is allow. On require_approval, hold it and route to a human. On deny, drop it and keep the reasons. The library never touches the money; it only decides.
We wrote up an incident analysis of a prompt-injected agent that moved 174,000 USD with instructions smuggled past its filters in Morse code. The lesson was not that the filters were weak; it is that natural-language filtering is the wrong control plane for money. A deterministic policy decision between the agent and the rail is the right one, and that layer is what these packages open source.
How a Morse code prompt injection got past content filters, and the control that would have stopped it.
These packages are new. There is no adoption story to tell yet, and we will not invent one. What we can promise: the evaluator is extracted from the production engine behind Axiru, the decisions are deterministic and replayable, and the reason codes are stable. Reviews, issues, and hard questions are welcome on GitHub.
Answers here are the same strings emitted in the page's FAQ structured data, so an assistant quoting the page and a person reading it get the identical answer.
Put a deterministic policy check between the agent and the payment rail, and make the rail unreachable except through it. In practice that means budgets scoped to the org, the team, and the individual agent with the most restrictive limit winning, an approval step above a threshold you configure, and a kill switch that revokes authority immediately. Prompt-level guardrails are not a spend control, because the agent's instructions are exactly what an attacker manipulates. The open source package @axiru/agent-spend-guardrails implements the policy decision in your own process.
Apache-2.0. Five packages publish under the @axiru scope on npm from github.com/AxiruAI/axiru-oss. The Buzz MCP bridge, buzz-axiru, lives in its own repo at github.com/AxiruAI/buzz-axiru.
No. @axiru/agent-spend-guardrails has zero dependencies and makes zero network calls. There is no account, no API key, and no telemetry. The evaluation runs entirely in your process.
No. The library returns a decision: allow, require_approval, or deny, with a stable reason code and a SHA-256 fingerprint. It never executes a transfer and it never touches funds or keys. Your code decides what to do with the decision.
Everything that runs in your process is open source and free forever: the policy evaluation, the vocabulary, the x402 middleware, and receipt verification. The hosted product is the part that runs on Axiru infrastructure: multi-rail enforcement, a real approval queue with named approvers, the hash-chained evidence ledger, and the audit evidence packs.
Two, stated plainly. EIP-712 verification in @axiru/x402-receipt-verifier requires bringing your own secp256k1 verifier. And the library does not compute rolling-window history for you: velocity and daily-cap rules need aggregates you supply.
New. They published under the @axiru scope on 2026-08-04. There is no adoption story to tell yet and we will not invent one. The evaluator is extracted from the production engine behind Axiru, the decisions are deterministic and replayable, and the reason codes are stable.
Multi-rail enforcement, the approval queue with named approvers, the hash-chained evidence ledger, and audit evidence packs: Axiru Agent Controls is the hosted continuation of everything on this 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.