How Spending Policies Actually Work at the Infrastructure Level

It's easy to think of a spending policy as a static setting — "$500 a day" — that gets checked like a form validation. In practice, the harder and more important part is what happens under real conditions: concurrent requests, edge-case amounts sitting exactly on a limit, and requests that arrive milliseconds apart against the same wallet.

When an agent asks Valta for permission to spend, the request goes through a real evaluation, not a cached assumption: is the agent frozen? Does an active policy exist for this agent? Does the amount fall inside the configured per-transaction cap? Would it push the day's total over the daily limit? Only if every one of those checks clears does the spend get approved — and the approval itself, along with the balance deduction, happens inside a single locked database transaction, not as separate steps.

That locking detail matters more than it sounds like it should. Without it, two spend requests arriving close together could each check the daily total, both see "we're still under the cap," and both get approved — quietly busting a limit that was supposed to be a hard guardrail. Locking the wallet row for the duration of the check-and-deduct forces the second request to wait and re-check against the first one's already-recorded spend, not against a stale snapshot.

We didn't just take that for granted — we had it independently stress-tested by a paid third-party QA engagement specifically built around trying to break it: seeded spends up to just under the cap, then two simultaneous requests sent at once for an amount that could only fit once. The result held exactly as designed — one approved, one correctly rejected, and the wallet balance matched the math precisely. That's the kind of thing you want proven under real pressure, not just reasoned about on paper.

The other half of "how policies actually work" is what happens when a spend is denied or needs a human. A hard denial never touches the balance — no partial deduction, no phantom transaction. A request that crosses a "requires approval above" threshold pauses instead of failing outright, and shows up for a human to decide. Either outcome gets written to the audit log the same way: permanently, with the reasoning attached.

None of this is exotic. It's careful, boring engineering — the kind that has to be right before anyone lets an AI agent near a real budget.