API key exposed in an application: an autopsy of a defect, and $600,000 at METR

A tester sent us their project because its online database refused to connect. Opening it, we saw their access key in plain text inside the application. What that costs elsewhere, and what we changed the same day.

An exposed API key is a service password left in plain text, readable by anyone opening the file. Evaluation institute METR reports (Update on Security at METR, August 31, 2026) that a key stolen from an application published without effective authentication was used over three weeks to consume credits worth around $600,000.

What a key is, in one sentence

Your application often needs to communicate with an external service: an online database, email sending or payments. That service does not know your application; it knows a character string proving the request comes from you. Anyone possessing that string can do what your application does: read customers, write on their behalf and spend from your account. It must therefore live outside code, in a vault the program consults when needed.

What happened to an evaluation institute

METR evaluates AI systems for a living, so this story does not concern a distracted small business. In March 2026, attackers stole an access key left in a deployed application whose authentication no longer worked and spent three weeks consuming credits that would have cost around $600,000, the provider had donated them, so financial loss remained theoretical. A second episode in early May targeted a public viewer. Two lessons take few words: protection can switch off without warning, and abnormal consumption can run for three weeks before anyone sees it.

Our own defect, found by a tester

In late August, a beta tester sent their project, a mobile application built themselves, because its online database refused to connect. The database address and private key were hardcoded. Our responsibility was twofold. First, we had never told them: for existing software taken over in Maestro, the online-database card could not appear because it depended on a stage that workflow never reaches. Second, nothing prevented the key entering online backup. They had done nothing foolish: their AI assistant wrote code this way, the application worked, and no screen ever explained the difference between a stored key and one pasted into a travelling file.

What we changed, and refused to do

Moving the key into storage is proposed, never imposed: the product shows where it is, explains the risk and moves it with your agreement. When a private key remains in code, online backup is refused if its destination is public or unknown, and flagged if private. The online-database card now appears for taken-over software without depending on an unreachable stage. All of this was built and published August 30, 2026 in version 0.1.13, and what we know about your data is on its dedicated page. We rejected two easier responses. Moving the key ourselves without asking: a tool independently touching production-service access creates failures its owner cannot explain. And blocking everyone by principle: many taken-over projects have good reason for a public key there, and a tool crying wolf every time it opens ends up ignored.

Why it happens so often

Veracode measured in its July 28, 2026 report that 44% of code-generation tasks produce a vulnerability, almost unchanged from the previous year. An assistant writing quickly writes what works, and a key pasted into a file works. Nothing on screen distinguishes a healthy application from an open one: both launch, both show your data, and that is the problem. The check must therefore come from the tool when code is written and when it leaves.

In practice, tonight

Search project files for key, token and secret, then look at what follows: a long meaningless character sequence is a key. Your system's text search is enough; no code reading is needed. If one is in a file shipped with the application, regenerate it at the provider, then store the replacement in service settings. Next check what your database shows without a password: the test takes two minutes. A tester accidentally did us this service; nobody guarantees you the same luck.