The viral story about people using a McDonald’s chatbot as a free coding assistant sounded plausible. It was a hoax. Fast Company reported no evidence of the exploit, and McDonald’s had no AI customer assistant in its app.
But a real incident at METR (pronounced “meter”), an AI research nonprofit, shows why the story resonated. In March, an attacker obtained a model provider API key from an agent running on a researcher’s personal cloud server. Over three weeks, the stolen key consumed approximately $600,000 in credits. METR did not have to pay because the credits had been donated.
The lesson is bigger than API-key protection. Companies cannot control AI spending unless they can connect consumption to authorized work and determine whether it produced useful results. AI FinOps must begin in engineering, long before finance receives the invoice.
When abuse looks like a busy week
METR’s researchers were accustomed to high token volumes and API errors during evaluations. A fail-open authentication bug exposed the application, and the credits had no spending ceiling. METR believes the attacker found the application through certificate transparency logs. The attacker then prompted the agent to reveal its provider API key.
The activity blended into legitimate usage until someone noticed that the increase did not correspond to an evaluation.
One agent task can trigger many model calls, tool invocations, retries, or subtasks. Low volume thresholds generate alerts during legitimate work. High ones can let abnormal activity continue. An agent stuck in a loop or using an unnecessarily expensive model can create similar spikes.
Futurum’s September survey of 1,636 technology decision-makers found that 46.9% reported AI spending overruns, and 43.3% of those organizations absorbed the excess and reconciled it later. Reconciliation explains what was spent. It can’t show whether the spending was authorized, useful, or avoidable.
A usage alert only tells you that spending changed.
Put limits between agents and spending
An agent with access to a provider credential can expose it or misuse its authority if its environment is compromised or its behavior is manipulated. That’s what happened at METR. This resembles the confused deputy problem described by Norm Hardy in 1988, in which a program with legitimate authority is induced to misuse it on someone else’s behalf.
I treat every model as untrusted code, so I separate an agent’s ability to request work from the credentials authorizing spending. Keep the provider key in a secured AI gateway that agents cannot read directly. Give agents narrowly scoped, short-lived credentials, and have the gateway restrict approved models and enforce per-task budgets.
The gateway becomes a critical security boundary requiring hardened access, restricted cloud permissions, and monitoring.
Limit agent retries, execution time, tool calls, and spending. A workflow that enters a loop should stop or request intervention. Provider-level spending limits add another layer where available.
Scoped credentials limit authority, spending caps constrain exposure, and execution limits prevent runaway workflows.
Make every dollar traceable to a task
Give every production task a unique identifier and log its model calls, retries, and tool invocations. Compare gateway records with the provider’s usage report, and store logs separately so an intruder cannot easily alter them.
If provider usage exceeds gateway records, investigate. The cause could be unauthorized calls, missing logs, retries the gateway didn’t record, asynchronous operations, or accounting-window differences. Treat unexplained usage as a potential incident until you know the cause.
Each workload needs a technical owner and a business owner. That changes the question from “Why did the bill rise?” to “Which workload generated the spend, was it authorized, and what did it accomplish?”
Measure what the money bought
Authorized spending can still be wasteful. A workflow may stay within its limits yet produce outputs that need extensive correction or are never used. A cheaper model may generate more failures and retries, while a more capable model may reduce human intervention.
Define an acceptance rule for each task type before launch. It might be a schema check, a quality threshold, or reviewer approval. Then divide total workflow cost, including calls, retries, and human-review time, by the number of accepted results.
Consider 1,000 tasks. A small model costs one cent per call and initially succeeds on 60%. A larger model costs ten cents and succeeds on 95%. Assume each failure is retried once at the same price and success rate, and a reviewer spends five minutes correcting remaining failures at $60 an hour.
The small model’s initial calls cost $10 and retries cost $4. Of the tasks, 160 still need review, costing $800. The total is $814. The larger model costs $100 for initial calls and $5 for retries. Two or three tasks need review, costing about $12.50. The total is about $118.
If review corrects all remaining failures, all 1,000 tasks are accepted. Cost per accepted task is about 81 cents for the small model and 12 cents for the larger one. These figures are illustrative and don’t come from client work. The outcome depends on the assumed success rates, retry policy, and review time.
Price per call is incomplete. Five minutes of review costs $5, equivalent to 500 calls to the small model. Human intervention can outweigh the apparent savings from cheaper models.
Workflow design matters. We built a compliance-screening agent for a network of more than one million experts. Its reports carry citations for reviewers to check. The team’s work moved from research to review, and vetting now runs three times faster.
Make AI FinOps an operating discipline
Security should investigate unexplained usage. Engineering should address rising cost per accepted task, repeated retries, and inefficient model choices. Business owners should decide whether results justify the expense. Spending exceptions need a documented reason, independent approval, and an expiry date.
Before an AI pilot reaches production, ask the team to trace one task from beginning to end. Which credentials authorize its calls? What prevents it from running indefinitely? Can every billable request be attributed to a task? What makes the output acceptable, and what does it cost?
If those questions cannot be answered, the organization does not yet have a complete picture of its AI spending.
The goal is spending that is authorized, explainable, and justified by the work it produces. That responsibility starts with system design.
______
About Amit Kumar Jena
Amit Kumar Jena is Head of AI Development at Kanerika, a data and AI consulting firm headquartered in Austin, Texas. He leads the company’s AI and machine learning engineering, including production AI agents, large language model applications, retrieval-augmented generation systems and enterprise AI deployments. His work focuses on agent security and governance in production systems.
Join our LinkedIn group Information Security Community!
——————————————————-
Click Here For The Original Source.
