Perspectives
A shared API key is not a budget
One key, one bill, and no owner.
By Ehsan Gazar, 16 September 2026
Somebody on your team pastes a provider key into a new service. It works on the first try, which is the part worth worrying about. Three months later the bill has doubled and nobody can say which service did it.
That is not a billing problem. It is a missing door.
One key, four teams
A provider API key is a bearer token. Whoever holds it can call anything the account can call, for as long as the account has money, and the provider will not ask which team they are on.
So the key spreads. It goes in a service, then in a second service, then in a notebook, then in a contractor's environment because that was faster than issuing another one. Every copy has the same authority as the original.
Now look at what you can no longer do.
You cannot attribute the spend, because the invoice is one number for the account. You cannot cap one use without capping all of them. You cannot revoke the contractor's copy without breaking the two services, so the copy stays live. And a key that reaches a public repository can spend the whole balance before anybody reads the alert.
None of that is a failure of the provider. They sold you a credential, and a credential is all it is. The structure that decides who may spend what is yours to build. Most teams discover that at the point where they need it to already exist.
A cap that belongs to the key
The fix is not a spreadsheet of which team uses which key. It is making the key the thing that carries the limit.
Every key in Vatan has its own budget, and the budget is either for its lifetime or for the calendar month. A key for a nightly job gets a monthly cap that resets. A key handed to a contractor for one piece of work gets a lifetime cap and stops.
The cap is checked before the provider is called, so a key that has spent its allowance does not reach the model at all.
Keys group into teams, and a team carries its own budget on top of the keys inside it. That buys the thing a shared key cannot. You can say this team may spend this much this month, without saying anything about anybody else, and without one number on an invoice being the only evidence.
One rule surprises people, and it is the right way round. A member who belongs to no team reaches everything. Joining a team is what narrows what you can see and spend, rather than what grants it, so adding structure is always a restriction and never an accidental promotion.
Refusals that name the fix
The interesting part of a spend control is not the refusal. It is whether the refusal sends the right person to the right page.
A gateway that answers "payment required" and stops has told you almost nothing. There are at least three different reasons behind that status, and the correct action differs for each.
So the checks run in a fixed order, and the order is the design. The organisation's balance is checked first, because if the account is empty then no key can spend whatever its budget says, and "top up" is the right instruction. The team's budget is checked next. If the team is out, moving to another key inside that same team changes nothing, and suggesting it sends somebody around a loop. The key's own budget is checked last.
Each refusal then names the thing that was actually hit. A team refusal says which team, because a message that says a budget was reached without saying whose is a support ticket. A monthly cap says when it resets. Borrowing the lifetime budget's wording would send somebody to raise a ceiling they did not need to raise. That happens on the last day of the month, at the moment it was about to fix itself.
The source address is checked before the money, for the same reason. Telling somebody their budget is spent when the real answer is that they are calling from the wrong network sends them to top up an account that was fine.
Where the cap stops
A budget here caps starting a request, not finishing one.
The check runs before the provider is called and the meter runs after it answers. So the last request a key is allowed to make can carry it past its ceiling. On a real key with a budget of one hundredth of a cent, the final figure was $0.0001126580.
That overshoot is one request wide, and it is bounded by the most expensive single call that key can make. It is not a rounding error to be hidden, and it is written into the code that implements it rather than into a footnote. A system that said "budget" and meant "hard limit" would be claiming something it does not do. The first person to find that out would be the one who trusted it.
What one door does not fix
It does not tell you whether the spend was worth it. Attribution says which service spent the money; only you can say whether that service should have.
It does not stop a team writing a loop that burns a month of budget in an afternoon. It bounds the damage to that key and that month. That is the difference between an incident and a postmortem, and it is not the same as prevention.
And it puts one more system between your code and the provider, which is a real cost and should be counted as one.
A credential you cannot cap, attribute, or revoke on its own is not really a credential. It is a shared password with a bill attached, and the bill arrives long after the decision that caused it.