How to create and fund a wallet for an AI agent

There are two ways to open a wallet for an agent, and which one you use depends on who is at the keyboard. If a person is, the person signs up and installs the MCP server, and the agent inherits an account with a policy. If nobody is, the agent opens a provisional account for itself, spends a small starter credit to prove it can do the work, and hands its person a link to claim the account later. Both paths end in the same place: an account someone owns, a key the agent uses, and a set of limits on that key. What follows is each path in the order the commands run, then the four ways to put money behind it.

Path A: a person opens it

Install the MCP server into the agent you run. The installer handles Cursor, Claude Code, Claude Desktop, and Codex, writes the configuration, and opens a browser tab to sign in.

npx @vaaya/mcp install

For a Claude Code session that should talk to the hosted server directly, the one-line alternative is:

claude mcp add --transport http vaaya https://vaaya.ai/mcp

Then create a key for the agent. Name it after the agent, restrict it to the categories the agent needs from Data, Search, Scraping, Media, Compute, LLM router, and Outbound, and give it a monthly limit. That key is the wallet as far as the agent is concerned. It does not hold money; it holds permission to draw on the account inside those limits, plus the obligation to state a maximum cost on every call.

Path B: the agent opens it

This is the path for an agent running unattended, or one that was told to get on with a task and has just discovered it needs a paid search. There is no human present to click anything, so the agent registers itself.

First, it registers an OAuth client. The registration is dynamic; nothing has to be pre-approved.

POST https://vaaya.ai/oauth/register
Content-Type: application/json

{ "client_name": "research-agent", "grant_types": ["refresh_token"] }

The grant_types field is not optional in practice. The default grant is the authorization-code flow, which then demands redirect URIs the agent does not have.

Second, it opens the account with the client_id it just received:

POST https://vaaya.ai/api/v1/signup/agent
Content-Type: application/json

{ "client_id": "..." }

The response carries an access_token, a refresh_token, a user_id, a $1 starter credit that is spendable at once and expires in 24 hours, and a claim_url. The agent should write the refresh token and the user id into whatever persistent memory it has before it does anything else, and treat the refresh token as a password: a file only its own process can read, never a repository, never a chat message, never a log line. If it suspects the token leaked, the grant can be revoked at the connected-apps page and the damage is bounded by the per-call ceiling on every request in the meantime. It should not re-register. Re-registering forfeits the history and grants no new credit.

Third, when its person appears, the agent hands over the claim link. One Google sign-in merges the provisional account into the person's account. The agent's tokens keep working through the merge, and its history comes with it. Claim links expire after 24 hours, so the agent should not memorize one; it can mint a fresh link at any time with a bearer-authenticated GET to /api/v1/signup/claim-url.

If the person is present but the agent is the one driving, there is also a device flow: register with the device-code grant, post to /oauth/device/code, show the person the verification link, and poll the token endpoint. An agent already connected over MCP can call the anonymous vaaya_onboard tool and get the exact links for either path.

Funding it

Four sources, and the agent sees them as one balance. It never knows which pot a call drew from.

1. The welcome credit. Every claimed account has a welcome credit of up to $10, spendable with no card on file. This is what lets an agent make its first real calls minutes after signup. For an agent that opened its own account, the $1 starter credit plays the same role for the first 24 hours, and the welcome credit applies once a person claims it.

2. The GitHub-backed credit line. Connect GitHub and the account receives a credit line sized from public contribution history. This is the pot that needs a card, because the card is how it settles: at the end of each week, the card is charged for what the agents drew. Nothing is deposited in advance, and the line grows with reliable settlement. The mechanics are in can AI agents have credit.

3. Prepaid packs. $10, $30, or $100, bought outright, for anyone who wants a hard prepaid bound or wants to stay card-free. Packs sit on the same balance as everything else.

4. No account at all. Vaaya's pay-per-call endpoints are listed at /.well-known/x402. An agent that already holds USDC on Base can pay them directly with the x402 protocol, with no signup, no key, and no policy other than whatever its own wallet enforces. This is the right path for an agent that is itself an on-chain payer and wants a single endpoint. It is the wrong path for an agent that will use twenty tools and needs a limit, which is what the account is for.

The first call

With any of the above in place, the agent's first paid call is two tool invocations. consult takes a description of the outcome and returns a plan: which providers can do it and what each one costs per call. use executes one line of that plan, and requires a max_cost_cents the agent sets from the price it was just quoted.

{
  "service": "exa",
  "action": "search",
  "params": { "query": "MPP Tempo Stripe machine payments launch", "numResults": 10 },
  "max_cost_cents": 5,
  "intent": "primary sources for a protocol summary"
}

The result comes back with a receipt: what was charged, on which key, and the transaction it can be traced to in the agent history. If the price had been above five cents, the call would have been refused before reaching the provider, at no charge, with the reason returned to the agent. That refusal is the wallet doing its job.

How this differs from a wallet the agent controls

Coinbase's AgentKit and Privy's server wallets give an agent a key it controls on-chain, and they ship policy engines alongside because a funded key with no policy is a liability. That model is right when the agent is itself a market participant that needs to hold and move value: a trading agent, an agent paying other agents, an agent that will sign transactions on a chain for reasons beyond buying an API call. The account model described here is right when the agent is an employee: it needs to buy things for its principal, inside a budget, from vendors the principal would approve of, with a record the principal can read. The agent holds nothing and can lose nothing. What it has is a key, a list, and a number.

The definitions behind all of this are in what is an AI agent wallet. Everything an agent needs to open an account without a human is at vaaya.ai/llms.txt.

Questions

Can an AI agent sign up for Vaaya on its own?

Yes. The agent registers an OAuth client at /oauth/register, then posts its client_id to /api/v1/signup/agent. It receives tokens, a $1 starter credit that expires in 24 hours, and a claim link. A person claims the account later with one Google sign-in, and the agent's tokens and history carry over.

How do I fund an AI agent without a card?

A claimed account has a welcome credit of up to $10 that needs no card. Prepaid packs of $10, $30, or $100 also need no card. The GitHub-backed credit line is the one that needs a card, because the card settles what the agents draw each week.

Do I need crypto to fund an agent on Vaaya?

No. Vaaya settles with providers on x402, Stripe MPP, and Tempo behind the account. The agent holds no keys and no tokens. If you prefer, an agent with its own USDC on Base can pay the x402 endpoints directly with no account at all.