Cap one account, leave the rest up

One account is consuming past what you sold. Tokens, orders, messages, tool calls, a third-party check you pay for per request. Tonight, three proofs, and you do them in a console you administer. Name that account and the counter you can see for it. Cap it, or stop it, without stopping anyone else. Then prove a new request from that account is refused, and a request from a different account still succeeds. If the name, the cap, or either proof needs a vendor on the phone, you do not have a cap. You have a chart, and a chart does not refuse the next call.

This is one identity inside a product you run. It is not the evening the feature's own monthly ceiling has already been crossed and the feature is still answering. That evening — attribute the dollars, stop the path that can grow without a new user, refuse new work over the cap in words the user can see — is when the monthly cap is already spent. The feature can be inside its budget tonight and still be one account away from leaving it. It is also not the design argument about why an enthusiastic user is the expensive one. What makes an AI feature expensive to run asks you to decide a ceiling, in tasks or tokens, before launch, and to decide what happens when it is reached. This article starts when that decision was never enforced, or was enforced as a number somebody can read and nobody can apply to one login.

The control that matches the missing stop is not a cloud-waste percentage. OWASP's API Security Top 10 for 2023, risk API4:2023, is titled Unrestricted Resource Consumption. The definition they print: "Satisfying API requests requires resources such as network bandwidth, CPU, memory, and storage. Other resources such as emails/SMS/phone calls or biometrics validation are made available by service providers via API integrations, and paid for per request. Successful attacks can lead to Denial of Service or an increase of operational costs." An API is vulnerable, on their page, if at least one of a listed set of limits "is missing or set inappropriately (e.g. too low/high)." The list is execution timeouts, maximum allocable memory, maximum number of file descriptors, maximum number of processes, maximum upload file size, the number of operations in a single client request, the number of records returned per page, and "Third-party service providers' spending limit" (OWASP, API4:2023 Unrestricted Resource Consumption). Eight rows. A token cap that leaves the email integration, the phone-lookup, or the model bill uncapped has closed one row. Name the row you closed, and name the rows you did not.

What they say to do about the paid row is short, and the second sentence is the one people skip. "Configure spending limits for all service providers/API integrations. When setting spending limits is not possible, billing alerts should be configured instead." A spending limit refuses. A billing alert informs. The same section also says to "limit/throttle how many times or how often a single API client/user can execute a single operation," with validating a one-time password, or requesting password recovery, as the examples. The unit is a single client or user, and a single operation. An organization-wide monthly number is a different object, which is why the monthly-cap article exists beside this one. OWASP rates prevalence as Widespread and detectability as Easy. Those are their ratings of the weakness. They are not a count of accounts, and they are not a probability that the login in front of you is the one spending.

How large a share of cloud spend people say is wasted, which is a different question, is what Flexera asked. The Flexera 2025 State of the Cloud Report is a survey of 759 cloud decision-makers and users worldwide, fielded in the winter of 2024. "All numbers and percentages are rounded to the nearest whole number." The sentence on waste: "Estimated wasted cloud spend on IaaS and PaaS has decreased to 27% this year." The same section: "Since reaching a high of 32% four years ago, estimated wasted cloud spend on IaaS and PaaS has decreased, reaching a low of 27% this year." A different line, which they keep separate: "Respondents reported that wasted software spend in public cloud was 24%." And the budget line in the key findings: "organizations are exceeding budgets by 17%" (Flexera, 2025 State of the Cloud Report). 27% is IaaS and PaaS. 24% is software spend in the public cloud. 17% is their summary of budget performance. 32% is the high they attribute to four years earlier, not a second measurement of this year. Flexera sells cloud and IT-asset management, and the report invites reuse under a Creative Commons attribution license. The figures are estimates respondents gave. They are not an audit of invoices.

None of those four numbers is a cap, and none of them is one account. 27% is not a share of your token bill, not a share of one customer's requests, and not a threshold you paste into a rate limiter. 24% is not the part of an AI invoice that is "the model being chatty." 17% is not the amount by which this account overshot a plan you sold. Do not tell a customer that about a quarter of their spend is waste because a 2025 survey of 759 people estimated that for IaaS and PaaS, or for software, depending on which line you grabbed. Do not set the cap at 27% of anything. The only use of the set is the contrast OWASP already drew. Flexera's 27% is a number people notice afterwards. API4's spending limit is a refusal you configure before the next request. A noticed number does not stop the account.

Do the three proofs against one account you can point at, not against the idea of runaway cost. First, the name. In the console you or the company administer, you can see the identity — the user, the key, the workspace, the tenant — and a counter for it since a time you write down. Tokens, orders, messages, or the third-party calls. A partner who says "they're a power user" has described a feeling. You have not named the account until the counter is on a screen you opened. Second, the cap. You set a limit on that identity alone, or you disable it, from that same console. Everyone else keeps the path they had. If the only control that exists is an organization ceiling, lowering it stops the quiet accounts with the loud one, and you have made a different decision: you have taken the product down a notch for everybody. That wider stop, when the next answer itself can hurt someone, is when to turn a live AI feature off. It is allowed. It is not this proof. Third, the two requests. You send one as the capped account and it is refused, in a way the account holder can see, not as a spinner that eventually spends. You send one as a different account and it succeeds. You write both results down. If you cannot send the second request, you have not shown that the rest stayed up.

Three moves that look like a cap and leave the account spending. Minting a fresh key for everyone else and leaving the old key, which the heavy account still holds, valid until the vendor's monthly reset. Putting a banner in the admin UI that says "review usage" and changing no limit. Asking the model, in that user's next prompt, to be more concise, which spends another call in order to discuss the spend and does not bind the call after that. A billing alert you forwarded to yourself is the fallback OWASP names when a spending limit is not possible. It is evidence you noticed. It is not evidence the next request will fail. If the provider really offers no per-account limit, write that down as the finding. Do not describe the alert as the cap you could not find.

What a console an operator can actually open looks like, as a product shape, is narrower than a waste survey. Gigbase, the agency workspace we built, has subscription plans and role-based access for agencies, admins, and team members, and an admin dashboard with subscription monitoring. That is a place an operator can see an account. It is not a meter on one customer's tokens, and it is not a refusal. Nothing in that description is a headcount, a duration, or a result figure, and it should not be spoken as a rate. 27% will not appear on that dashboard. If your own admin screen cannot name one account's counter, the Gigbase shape is the gap, not the evidence that you already have the cap.

There is a version of this where hiring the cap is the wrong purchase. No account is running past what you sold, because you do not have accounts yet. Nothing is in production, so there is no counter to read and no request to refuse. You are still choosing who will build, and the conversation you are in is that choice. The criteria, when that is the actual decision, are the ones on the page for a top saas development company. They do not rank anyone, including us. Or the buyer wants a slide that says FinOps and does not have a console to open. A slide that quotes 27% and has never named an account is a brochure. Or a customer has already seen another customer's data. A spend cap does not close a leak, and the first hour of that incident is a different article.

When one account is already past what you sold and you cannot stop it yourself, the missing object is specific. A counter you can read, a limit that binds that identity, and a refusal you have watched while a second identity still works. A startup software development company that expects this will have put the meter and the per-account stop in a console you administer before the second customer existed, because the proofs take nothing they were not already operating. One that can only email a vendor to ask for a pause is telling you who holds the product. Where the next slice is one capability and the acceptance sentence names the cap, an AI integration sprint is the shape that can require the three proofs as the definition of done. The sprint's published deliverables include cost and latency instrumentation per request. Instrumentation is the reading. The refusal is the decision on top of the reading. Do not accept a dashboard as the cap. Where you are not sure which accounts can spend at all, a two-week AI readiness assessment maps the systems before anyone scopes a rebuild. The findings are yours. They are not a promise that a wasted-spend estimate applies to you, and they are not a rate.

Before you tell anyone the bill is under control, do the three proofs on one real account. Name it and its counter. Cap or stop that account alone. Show that its next request fails and that a different account still works. A chart you forwarded is not a refusal. The screen that says the month is fine does not say which login is allowed to end it.

A sign-in on that account which the owner did not make is a different row. Show the login they did not make names it, shows it refused or ended, and shows a sign-in they make still succeeding. A counter is not a sign-in. A spend refusal does not say who authenticated.