Your agents need corporate cards

Give the agent a spending identity

An employee corporate card gives a person permission to spend company money for a defined job. The company keeps the funding, sets the limit, reviews the purchases and withdraws access when the job changes.

A research agent should have an identity you can recognize on the account, a spending allowance and a control you can use when it starts doing the wrong work.

On Vaaya, an API key provides that identity. Give separate agents separate keys. This is delegated access to the account's funding, rather than a payment-network card issued in the agent's name. A key does not work at every merchant, and creating another key does not create another funded balance.

The account owner still pays. The agent gets permission to buy the tools its work needs.

Translate the employee policy into agent controls

Map each part of the employee's spending policy to a control the owner can set. This illustrative comparison describes Vaaya's current key controls.

Employee card practice	Agent equivalent on Vaaya
Put a name on the card	Name a separate API key for the agent
Set an allowance	Set a daily, weekly or monthly ceiling for that key
Limit permitted purchases	Choose the tool categories the key may use
Review expenses	Review the key's calls, status and charges
Freeze a card temporarily	Pause the key's billed calls, then resume it
Replace exposed credentials	Rotate the key's secret
Withdraw spending access	Revoke the key

Tool categories describe API work, such as Data, Search, Media and the LLM router. They are not merchant category codes. Permitting Media does not approve every possible creative task, and permitting Data does not establish a business reason to enrich every contact. Your application supplies that narrower task policy.

Core utilities remain available outside the metered category restrictions. A category allowlist should therefore be read as a policy for categorized tool spending, not a claim that the credential can do nothing else. See the spending controls overview for the underlying controls.

Put the limits around the job

Name keys for work you will recognize later: sales-research, campaign-creative or support-triage. Use a separate key when a task needs its own budget or may need to stop independently.

Use a policy plan like this illustrative example to decide which keys the business needs.

Agent	Budget period	Initial paid categories	Reason to review
Sales research	Week	Search and Data	Paid enrichment repeats on the same accounts
Campaign creative	Month	Media	Revisions continue after the selected draft is approved
Support triage	Day	LLM router	A retry loop creates repeated model calls

Choose amounts from the work you intend to permit. Calendar periods reset at their boundary: a daily allowance is not a rolling twenty-four-hour allowance. A campaign spanning a reset can use allowance on both sides. Maintain a campaign total in your application when the business budget must cover the whole assignment.

Keep a per-call maximum as well. One permitted purchase can still be too expensive for the job. Vaaya's API reference documents max_cost_cents for supported calls and returns the actual charge, so the application can compare its estimate with what happened.

For agents that keep running, see budgeting long-running and short-lived agents. A persistent agent and a single export job need different rules for renewal and stopping.

Give the worker its own key

The primary account key belongs with the owner or the service that manages agents. A worker should receive the separate key created for its assignment.

Vaaya's agent-management API restricts policy changes and key creation to owner-level credentials, including the primary key. A sub-agent key cannot mint a replacement key with a larger allowance. Copying the primary key into every worker defeats that separation before the first paid call happens.

Keep the secret in the deployment's secret store. Use the key's label or your own agent identifier in logs; avoid copying the secret into prompts or task reports. Several workers sharing one key also share its policy and attribution, which makes later investigation less precise.

OAuth-connected agents have a different control model. A connection appearing on the Agents page does not itself mean it has an individual key ceiling. Use separate API keys for the per-agent limits described here.

Review purchases against delivered work

The key's activity shows calls and charges. Your application should connect those calls to the task and its output: the account researched, the image accepted or the support ticket handled.

A successful API call can produce work nobody uses. Review repeated purchases, unfinished jobs and paid retries alongside the totals. Keep the transaction identifier with the task record so someone can follow a charge back to the request without reconstructing the entire agent conversation.

Pause a key when you need to inspect it. Pause prevents subsequent billed calls; it does not cancel a render already submitted or stop the worker process. Rotate an exposed secret, and revoke access when the assignment ends.

The money supporting these allowances belongs in the business's treasury plan. If the worker runs in a customer's environment, decide who funds it before distributing credentials; client-site agent deployments need that agreement too.

Open Agents, create a separate key for one worker, set its ceiling and permitted tool types, and review its first completed task before expanding the allowance.

Questions

Does Vaaya issue a payment-network card to each agent?

The corporate-card analogy describes delegated spending authority. A Vaaya API key identifies an agent and applies its spending policy; it is not an issued card number that works at every merchant. Keys on the same account draw on the owner's shared funding.

Which agent spending controls are available today?

Named keys, daily, weekly or monthly calendar spending ceilings, tool-category restrictions, per-key usage history, pause and resume, secret rotation and revocation are available. Per-call maximum costs add a separate purchase-level check. These per-key controls do not automatically apply to every OAuth connection.

Does pausing an agent cancel work already submitted?

Pausing refuses subsequent billed calls on that key. It does not promise to cancel a provider job already running, reverse a completed purchase or stop the agent's local process. Handle those actions separately.