Paybond
Safe spend controls for AI agents
73 followers
Safe spend controls for AI agents
73 followers
Your AI can now buy tools, APIs, and services on its own. That’s useful — but risky without rules. Paybond is the safety layer in between: you set a budget, nothing gets spent without approval, Paybond checks the work actually got done, and you can get money back if it didn’t. Every approved spend is logged in one clear record your team can review later. Developers can get started in minutes with the Paybond CLI — log in, set guardrails, and connect a coding agent or MCP host from the terminal.
This is the 2nd launch from Paybond. View more
Paybond CLI
Launched this week
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.
Free
Launch Team
Paybond
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.
Paybond
@angelika_dev 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.
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.
Paybond
@syed_noor4 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!!
@damilare_olaleye 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.
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?
Paybond
@prashant_patil14 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?
Paybond
@mohithkarthikeyam
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?
Paybond
@ansari_adin
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?