Paybond
Safe spend controls for AI agents
Start new thread

Paybond CLI - Safe agent spend from the terminal

by•
Paybond CLI is new: one command line for safe AI agent spending, in TypeScript and Python. Run paybond login to get into sandbox in minutes. From there: scaffold paid-tool guardrails with paybond init, wire Claude, Codex, or any MCP host with paybond mcp install, and validate credentials and agent setup with paybond doctor. Every command supports JSON output for scripts and coding agents. Same rules everywhere: budgets, approval before spend, outcome checks, and audit-ready records.

Add a comment

Replies

Best
Maker
📌
AI agents are starting to spend money on their own APIs, tools, bookings, vendor actions, and most teams have no real safety layer for that. It’s exciting… until an agent buys the wrong thing, overspends, or completes a task you can’t prove later. So we asked: what if spending worked more like giving an employee a company card? - Set a budget - Approve before money moves - Check the work actually happened - Refund if it didn’t - Keep one clear record for the team That’s Paybond. What’s new today: the Paybond CLI. Instead of wiring everything through docs and SDK calls first, you can now start from the terminal: npx -p /kit paybond login From there you can scaffold guardrails, install MCP config for Claude/Codex, and run paybond doctor to sanity-check your setup. We kept it short on purpose: one CLI, same flow in TypeScript and Python, built for developers and coding agents. If you’re building agents that can take real-world actions, we’d love your feedback. Try it here: CLI reference: Thanks for checking it out.

Congrats on the launch 🚀 Paybond looks super practical, I’ve been wanting a smoother way to handle payments, and this feels like something I’d actually use.

Maker

 

Thanks!

Paybond is built for when AI agents start spending on APIs, tools, and vendor actions, budgets, approval before spend, and a clear record after. Sandbox is the fastest way to see if it fits your stack. Would love your feedback once you’ve tried it.

Maker

 Thanks, reall appreciate. The sandbox login takes about a minute: npx -p /kit paybond login. Happy to hear what you’re building and whether the CLI flow clicks for you.

This is the half most agent-spend tools skip. Gating the transaction is easy, verifying the work actually happened

is the hard part, and intent escrow with signed evidence before settlement is a clean answer. Nice.

Reading the thread, the thing I would flag for anyone adopting this: your safety is now only as tight as the completion rule you write. "API returned 200" will happily pass on garbage data, so the real work shifts to defining

predicates that actually capture "done", quality fields, artifact hashes, the vendor ID you expected, and most teams will under-specify those on day one. The disputes-to-human path covers the ambiguous tail, but a library of strong default completion rules per common tool or vendor would keep people from writing a loose predicate and assuming they are covered. Is that on the roadmap, shareable rule templates the way you already scaffold guardrails

in the CLI? Really like where this sits. Congrats on the launch.

Maker

 Thanks! you are right about the predicate quality cliff. As of today Paybond already has managed completion templates (completion_v1, completion_budget_v1) with versioned publish and preview in the console, including evidence_schema and schema_field checks so teams can require typed evidence instead of a single loose status field. Tenants can also block raw predicates and allowlist only approved templates.


What we do not have yet is the library you are describing which is the strong default completion rules per common tool or vendor that is scaffolded the way the CLI does for spend guardrails. That is currently on our roadmap and very aligned with how we want teams to start safe.

Thanks for calling it out!!

 Love that you block raw predicates and allowlist only approved templates. Making typed evidence_schema the default is exactly what stops a team from writing one loose rule and assuming they're covered. One thing worth building in early when you do the per-vendor library: vendor responses change shape over time. An API that returns a clean status plus quality fields today can quietly reshape its payload a few months later, and a completion rule written against the old shape will start passing again on incomplete work. That's the scariest failure mode, because nobody gets alerted, the rule just silently goes loose. Versioning each template against the vendor's API version, plus a signal when the evidence stops matching the expected schema, would make a shared library something teams can actually trust instead of set-and-forget.

Either way, this is the right shape for the problem. Looking forward to seeing that vendor template library land. Congrats again on the launch.

Maker

Thanks again for pushing on this, the vendor completion template library is live now.

We shipped a shared completion preset catalog with archetypes (api_response_ok, webhook_confirmed, artifact_attested, cost_and_completion) plus vendor packs (stripe_charge, ach_travel_booking, x402_delivery_receipt, etc.) that scaffold the same way spend guardrails do:

From the CLI you can run:

paybond policy templates

paybond init completion --preset ach_travel_booking

paybond policy validate-evidence --preset stripe_charge --vendor-file vendor.json

Each vendor pack pins a vendor_contract (api_version, schema digests, quality fields) at intent create. When a vendor payload stops matching the expected shape, Harbor surfaces it in schema_validation and Signal emits COMPLETION_* drift codes (passed_with_drift, pack_stale); so you get a signal before a loose predicate silently passes incomplete work.

Docs:
Contract pinning & drift:
Raw catalog:

Happy to add more vendor packs if you have a specific tool/API shape in mind.

The company card framing fits this problem well. From the payments side, how does the refund actually settle? Are you holding funds in escrow and releasing or refunding from that, or is it a real charge to the vendor that then needs a chargeback? Those are very different to claw back once a vendor has captured the payment.

Maker

 Paybond uses intent escrow. Funds are authorized up front, then released to the payee if evidence passes, or returned if it fails. The refund happens before final settlement, not after payment have been captured and needs to be reversed.

Interesting launch! 🚀

I like the idea of treating AI agents more like employees with spending limits instead of giving them unrestricted payment access.

I'm curious: if an agent needs to make multiple related purchases during a single workflow, can Paybond handle conditional approvals (approve up to a total budget) without requiring manual confirmation for every individual transaction?

Maker

 Thanks, that is exactly the workflow we designed for. Yes. You do not need manual confirmation on every purchase if your policy allows it. Typical pattern: one funded intent with a total budget, then multiple related tool calls in the same workflow reuse that intent. Each call still authorizes spend, but Gateway policy auto passes routine purchases inside your limits and only pauses for human approval when thresholds, caps, or anomaly rules trigger.

The company card framing fits well. The part that stands out is verifying the work actually happened and refunding if it didn't, most agent spend tools stop at gating the transaction. How do you check completion, agent self reporting or an external signal?

Maker

 

Thanks. It is not pure agent self reporting. Your integration submits signed structured evidence, and Paybond evaluates it against the completion rule on the intent. You define what counts as done: response fields, vendor IDs, webhook results, artifact hashes for receipts or logs, and similar signals your app collected. Paybond enforces that rule and releases or refunds from there. Ambiguous cases go to human review through disputes, not automatic agent resolution.

If Paybond is the layer that approves spend and verifies delivery, what happens when the agent's own judgment about whether "the work got done" conflicts with Paybond's check, like the agent thinks the API call succeeded but the actual result was garbage data. Who's the source of truth there, and does that get flagged back to a human or resolved automatically?

Maker

 

Great question. Paybond splits this into two steps. First, it authorize spend before the tool runs using budget, policy, and human approval when required. Second, it evaluate signed evidence against the completion rule you attached to the intent, not the agent’s internal sense that the work succeeded. If evidence fails the predicate, for example garbage data when your rule checks quality fields, settlement goes to refund, not release. If the outcome is genuinely ambiguous, disputes freeze settlement and route to human review in the console. That is not resolved automatically by the agent. The source of truth is the agreement and the evidence evaluation, not the agent’s judgment. The agent can be wrong. Paybond enforces what you defined up front.

Putting a spend-control layer between an autonomous agent and real payment rails is the right boundary to harden, since 'the agent bought the wrong thing' is fundamentally an authorization problem, not a prompt problem. Is the limit enforced as a hard preflight gate at the credential boundary so an over-budget call physically cannot execute, or is it detection and alerting after the charge has already cleared? And does Paybond hold the real payment credentials and hand the agent only scoped, revocable tokens, or does the agent still keep the real keys with Paybond just observing from the side?

Strong boundary. The piece I’d pressure-test is the run record after a blocked, refunded, or approved spend: request, policy version, approver, external completion signal, and what the agent is allowed to retry.

Since the CLI already speaks JSON, can that receipt be exported back to the MCP host as part of the agent’s run log?