Budgets for agents, not card numbers

Software agents are starting to buy things. They book flights, renew subscriptions, order supplies and pay for data. Almost all of them do it the same way: someone hands the agent a credit card number and hopes for the best. That works in a demo. In production it carries a risk that grows with every task the agent is given.

The problem with handing an agent a card

A credit card is a general-purpose instrument. It can be used anywhere, for any amount, until the bank's limit is reached. An agent that holds one inherits all of that. If a web page contains hidden instructions, or a user tricks the agent with a clever prompt, the agent can spend more than intended, and there is little in the card itself to stop it.

Teams try to plug the gap with guardrails in code, but guardrails live in the same system the attacker is trying to influence. A hard limit belongs somewhere the agent cannot edit.

A budget the agent cannot exceed

A gift card is a balance with a ceiling. If you give an agent a card worth twenty dollars for a task that needs twenty dollars, the worst possible outcome is twenty dollars. Nothing the agent reads, and nothing anyone says to it, can raise that limit. The cap is enforced by the card, not by the agent's judgment.

That property makes gift cards a natural fit for agentic commerce. You can fund each task separately, scope the brand to what the task requires and audit the balance afterwards. See agentic commerce for how the pieces fit together.

Cheaper, and easier to stack

Card payments carry processing fees that add up when an agent makes many small purchases. Gift cards avoid per-purchase card processing charges at the till, and some brands sell them at a discount or run promotions. An agent that knows how to combine a card with a store offer can save real money over a year of purchases.

Because Bidali carries 4,700+ brands in 150+ countries, an agent can pick a brand in the market where it needs to buy, rather than fighting a checkout that only accepts local cards.

How it works for builders

The Gift Card API is designed for programmatic use. A request creates an order against a funded balance, a webhook confirms delivery and the code goes straight to your agent. We are building toward MCP support so agents can discover and buy cards without custom glue code. The API is in early access, and we would like to hear what you plan to build.

For human-in-the-loop flows, Bidali One gives a person one balance across brands, so a user can set a monthly allowance for their assistant and see exactly what it bought.

Starting small

The simplest pilot is a single agent with a single task. Fund a balance for that task, restrict the brands to what it needs, and log every order. Review the results after a week: did the agent buy what it should, at the price it should, and was the balance enough? Then widen the scope to another task or another agent. This approach gives your security team something concrete to review, and it lets you show stakeholders exactly how much an agent could ever spend, which is often the question that decides whether a project moves forward.

Also useful to AI companies themselves

Training and evaluating models depends on people: annotators, red-teamers, beta testers and survey respondents, often in many countries. Paying them by gift card avoids the friction of international transfers and lets each person pick a brand they use. It is quick to send, simple to track and easy to scale as a program grows.

Agents will spend real money whether or not we are ready for it. Giving them a budget they cannot exceed is the safest place to start.