A Free API Key Still Needs a Budget Boundary

A research dashboard was supposed to sit behind Google authentication. A bug silently removed that protection, an outsider asked an agent to reveal its model-provider key, and the stolen credential kept working for three weeks.

The model usage would have cost about $600,000 at commercial prices. The provider had granted those credits to the research organisation for free, so this was not a $600,000 invoice. That qualification matters. It also sharpens the engineering lesson: a key can carry enormous authority even when nobody sees money leaving a bank account.

On 31 August 2026, Model Evaluation and Threat Research, better known as METR, published an unusually candid account of this incident and a separate May attack. The details are useful because nothing in the first chain required an exotic failure. It joined a personal cloud server, a quickly built app, authentication that failed open, a long-lived secret, and monitoring that could not separate expected heavy use from theft.

Most teams running AI experiments have some version of that stack. Keep the experiments, but design them so one quiet mistake cannot inherit an organisation-sized account. Blaming one style of programming would miss the system around it.

What happened, with the price tag in the right place

The incident began in March 2026. According to METR’s security update, a researcher without access to its most sensitive information ran agents on a personal Amazon EC2 instance. The server was deliberately reachable from the internet and was meant to be protected by Google authentication. It held a key for METR’s general-access account, which provided inference on publicly available models.

The app had what METR called a fail-open vulnerability. In plain English, an authentication error produced access instead of denial. The dashboard spent several days on the public internet without the intended login check. METR suspects the attacker found it by searching recently registered sites, possibly through public certificate-transparency records, for names associated with language models or agents.

After finding the dashboard, the attacker prompted an agent to disclose its model-provider API key. METR also found that the attacker added a Secure Shell key, which provided a persistent route back to the server. The stolen provider credential was then used for three weeks to consume credits on public models.

METR valued those credits at about $600,000, while stating that the unnamed model developer had supplied them for free. Infosecurity Magazine reported the same distinction on 1 September: the number was the commercial value of the consumed service, not a direct loss paid by METR. Headlines that turn it into a $600,000 bill overstate what the disclosure says.

The narrower truth is still serious. Someone outside the organisation obtained a reusable credential and exercised it for weeks. The account’s unusual consumption blended into real research workloads. There was no natural invoice shock because the credits were free, and METR said it could not set a spending limit on keys of that type at the time.

METR revoked the researcher’s access, stopped and imaged the cloud server, rotated the credentials found there, and imaged and wiped the researcher’s laptop. It alerted the model company and worked with a security consultant to assess the scope. The Hacker News account published on 1 September independently matches the disclosed sequence and the limit METR placed on the evidence: the stolen key concerned public models, and the organisation found no sensitive information accessed in either of the two incidents it described.

That limit should survive every retelling. This was not reported as a theft of hidden model weights, confidential customer data, or unrestricted frontier-model access. METR separated its data and credentials into sensitivity classes, and said the March researcher had no access to the highest two classes. A real control worked there. The mistake was allowing a lower-tier credential to remain broader, longer-lived, and less observable than its experimental job required.

The practical headline is therefore smaller than “$600,000 breach” and more useful: free capacity hid the cost signal that might have exposed a stolen key. Engineering teams should not rely on an invoice to be their intrusion alarm.

The dashboard was public before anyone meant it to be

Teams often picture authentication as a gate in front of an application. The gate asks for identity, receives an answer, and either opens or stays shut. That picture omits the code that decides what happens when the identity service times out, a configuration value is missing, or middleware fails to initialise.

A fail-open design treats such failure as permission to continue. Sometimes developers choose that behaviour for availability. If a personalisation service is unavailable, showing a generic page may be sensible. Authentication is different. When the application cannot establish who a visitor is, granting the visitor the protected session converts a reliability problem into an access-control failure.

The dangerous part is the silence. A dramatic login error attracts attention. A dashboard that loads normally produces no visible reason to investigate. The operator may see the page through an existing session and assume the intended protection remains in place, while a visitor arriving without that session receives the same access.

This is why a browser check from the developer’s laptop is weak evidence. The browser may carry cookies, use a corporate network route, or arrive through a different hostname. The useful test starts from an unauthenticated client outside the trusted network and asks one blunt question: can it reach any protected function when the identity dependency is absent, misconfigured, or returning an error?

METR’s account supplies a concrete answer for one experimental service. The application was intended to be public behind Google authentication, yet a bug silently disabled that authentication for several days. Once the agent dashboard was exposed, the attacker did not need to break the model provider directly. The dashboard already possessed the credential they wanted.

That changes how a team should review a prototype. The question is not only whether the app stores secrets safely in source control. Ask whether any function reachable through the app can return, print, infer, or spend those secrets. An agent with access to its process environment may be able to answer a request such as “show me the provider configuration” even if the key never appears in HTML or a Git repository.

Agent interfaces make this boundary easier to miss because ordinary language reaches a component that can inspect files, environment variables, logs, and tools. A form field may look like a chat box, but its effects resemble a remote administration surface. If an anonymous visitor can ask the agent questions, every capability behind the agent must be considered anonymously reachable until an enforced control proves otherwise.

Putting another instruction in the system prompt does not close that route. “Never reveal secrets” can improve behaviour, but the model remains one fallible interpreter. The stronger design keeps unnecessary credentials out of the process, masks them from logs, and gives the runtime an identity whose provider permissions are limited to the experiment’s exact task.

The first control is still simple: authentication must fail closed. If the identity provider, reverse proxy, policy engine, or configuration cannot confirm access, the protected route returns an error. Availability can be restored by repairing the dependency. Access granted during uncertainty cannot be taken back after a key has been copied.

One API key joined four separate kinds of authority

An API key is often described as a secret string. That description explains how to store it, but not how to judge the damage if it leaks. A better model treats the key as a bundle of authority with four dimensions: which services it can call, how much it can consume, how long it remains valid, and how clearly its use can be attributed.

In the March incident, the service dimension was limited to public-model inference rather than METR’s sensitive model access. That reduced the possible harm. The consumption dimension remained large because the granted credits had high commercial value and no available hard spending limit. The time dimension allowed three weeks of use. Attribution was weak enough that hostile traffic blended into the organisation’s normal high-volume evaluations.

A credential can be narrow on one dimension and dangerous on another. Read-only database access may still expose an entire customer table. A model key restricted to public models may still burn scarce capacity, trigger provider abuse controls, or interfere with legitimate work. A key valid for one service can remain risky if it lasts a year and every experiment shares it.

Teams get into trouble when they replace this authority map with a binary label such as “sensitive” or “not sensitive.” METR reasonably treated public-model credentials as less sensitive than keys for non-public models or disabled safeguards. Less sensitive did not mean harmless. The March response still required credential rotation, machine forensics, partner notification, and a scope assessment.

Shared keys make that assessment harder. Suppose ten researchers and six continuous-integration jobs use the same provider key. A sudden traffic increase proves that the account was used, but not which workload produced it. Revoking the key interrupts every legitimate user at once. Leaving it active preserves the attacker’s access. The convenience saved during setup returns as uncertainty during response.

Per-workload credentials cost more setup time and buy much better evidence. A key named for one experiment, issued to one controlled runtime, and tagged with an owner can be revoked without guessing who else depends on it. Its normal traffic has a recognisable shape. An alert can point to a person and a repository instead of a general account.

Expiry turns a forgotten secret into a bounded mistake. If a weekend prototype receives a credential that expires on Monday, discovery on Tuesday may still require investigation, but the route has already closed. A key with no expiry depends on someone remembering it after the demo, the paper deadline, or the employee’s departure. Memory is not a dependable revocation system.

Provider support varies. Some model platforms expose project-level budgets, rate limits, allowed models, network restrictions, and separate service accounts. Others provide only a bearer key tied to a broad account. The absence of a provider control does not make the risk disappear. It means the team must narrow the surrounding path with a gateway, short issuance workflow, local quota, controlled network, or smaller account.

OWASP’s Secrets Management Cheat Sheet frames secrets as a lifecycle rather than a one-time storage problem. Creation, distribution, rotation, revocation, expiry, and monitoring all matter. A vault protects a key at rest, but a running agent still needs some way to use the credential. The runtime boundary and the key’s authority determine what happens next.

For AI workloads, price belongs on that authority map. Tokens can be consumed at machine speed, and a useful research account may have limits far above a normal developer’s daily use. A free grant removes procurement friction without removing resource value. Budget controls should describe how much one workload may cause, not how much finance expects to pay this month.

Normal traffic can hide theft when normal has no shape

METR routinely runs large evaluations that use many tokens. The organisation also sees unusual rate-limit and API errors during work with pre-deployment models. Against that background, the attacker did not need to make traffic look small. It only had to make hostile consumption look like another large experiment.

METR said its internal usage dashboard did not show rate-limited requests to all users at the time. It also lacked the natural ceiling that a paid bill might impose. The result was a three-week detection gap even though the stolen key generated substantial activity.

“Alert on high usage” sounds obvious until a legitimate job is high usage. A fixed threshold that catches every evaluation becomes noise. Engineers mute it, route it to a low-priority channel, or accept that it fires throughout the week. The control exists on paper and disappears in practice.

Useful detection needs workload context. A training run may consume a large number of tokens from one known runner during a booked window. An interactive research dashboard may produce smaller bursts from a particular region. A stolen key used by a different client, around the clock, or across unfamiliar models creates a different shape even when total volume alone looks plausible.

Start by naming the expected shape before deployment. Record the owner, purpose, allowed models, usual request rate, maximum concurrency, expected geography when that signal is meaningful, and end date. None of these fields needs to predict traffic perfectly. Together they give an investigator something stronger than “this key belongs to research.”

Spend alerts help because they translate consumption into a unit people understand, but an alert is not a hard boundary. METR said it added spend alerts where possible after the incident. That should shorten detection. A provider budget or gateway quota goes further by limiting what one stolen credential can cause while the alert is waiting for a human.

Rate limits need the same care. A generous account-wide limit protects the provider from overload, not the organisation from one experiment consuming the whole allowance. Per-key and per-project quotas preserve capacity for other work. A low default can be raised for a planned evaluation, then brought back down when the run ends.

Alerts also need an owner with authority to act. A message sent to a channel of 200 people has no owner. The useful route reaches the person named on the key and a security or platform responder who can suspend it if the owner does not answer. The alert should include the credential identifier, recent usage change, affected provider project, and a safe revocation link. It must never include the secret value.

Free credits deserve the same monitoring as paid credits. Their replacement cost may be zero on an invoice, but their abuse can consume a research grant, damage a provider relationship, trigger account suspension, or give an attacker a platform for other activity. Cost is one consequence. Authority is the underlying asset.

The strongest metric measures unowned or unexplained use rather than total monthly tokens. A planned experiment can justify a spike. A key that has no current owner, no booked run, and no expiry should not be allowed to create one.

An experiment needs a smaller blast radius than production

Prototype culture often reverses the sensible security order. Production receives separate accounts, network controls, managed identity, and reviews. Experiments receive one shared key because the code is temporary. Yet experiments change faster, use less-tested code, expose novel interfaces, and are more likely to run on personal infrastructure.

Temporary code is not temporary authority. The script may be deleted tomorrow while the credential it printed into a log remains valid for months. A demonstration server may have no important database while holding a key that reaches an organisation-wide model account. The small app becomes a side door into a much larger resource.

METR’s March case joins those conditions cleanly. The researcher had no access to the organisation’s most sensitive categories, which constrained the incident. The personal EC2 instance still contained a general-access provider key. The app’s authentication failed, and the agent could disclose what the process knew.

A safer experimental environment starts with a dedicated provider project or account. Give it only the models the test requires and a quota sized for the next run. Issue one credential to one workload. Store it through a managed secret path rather than copying it into a source file, shell history, notebook, or chat message.

Keep the public application separated from internal systems. In its May incident, METR found a different risk around a public transcript viewer: a read-only query interface had a bug that could have reached unpublished evaluation data, and sensitive model material had accidentally entered a database intended for less-sensitive content. METR said attackers probed the endpoint but found no evidence that they discovered the bug or accessed non-public data.

After that near miss, METR described an isolated public production environment, architecturally separated from internal infrastructure. This is the durable control. A public app will eventually have a bad route, a mistaken deployment, or an authentication fault. Separation makes the question “what can this service reach?” answerable before the bug arrives.

The same pattern applies to one engineer’s AI dashboard. Put it in a cloud account or project with no route to production networks. Do not mount the developer’s home directory. Do not inherit their broad cloud session. Send model requests through a narrow identity, and deny access to unrelated secrets even if the agent asks politely.

Personal infrastructure creates an additional ownership problem. An organisation may not have central logs, endpoint controls, backup policy, or a reliable way to revoke access. METR responded by clarifying rules around organisational credentials and data on non-METR devices or infrastructure, and by formalising security review for researchers deploying public applications.

That does not require turning every notebook into a production launch review. Use a threshold. Local work with fake credentials and no public listener can remain lightweight. A public endpoint, organisational key, sensitive dataset, or tool that can modify another system triggers a short review before deployment. The review checks boundary and authority, not formatting.

This is a natural application of The Secure Harness: Shipping Production Code with AI Coding Agents. Fast-moving code should keep moving, but it should carry an experiment-sized identity, budget, and route to the rest of the organisation.

Treat the key leak as an incident, not only a billing error

A surprising model bill often sends teams first to finance or provider support. Those calls matter, but a leaked credential is a security incident even if the provider refunds every charge. The key may have been copied from a server that also held other credentials, source code, logs, or cloud access.

METR did more than revoke the model key. It stopped and imaged the EC2 instance, rotated credentials present on it, examined the researcher’s laptop, and brought in a security consultant for an independent compromise assessment. The added SSH key justified that wider scope because it showed the attacker had established another access path on the host.

The first response step is containment with preservation. Disable the exposed route and revoke the known credential, but keep enough evidence to establish what happened. Cloud audit logs, provider usage records, instance snapshots, identity logs, deployment history, and secret-access events can distinguish one stolen key from a broader host compromise.

Rotation must follow reach, not convenience. If several secrets existed on the machine, rotate each one that the attacker could have read. If the host had a cloud instance role, inspect what that identity allowed and expire active sessions where supported. If a shared key appeared in a notebook or shell history, search controlled repositories and logs for copies without broadcasting the secret into more tools.

A new key in the same unchanged server is not recovery. The attacker may still have a session, an SSH key, a scheduled task, or access to the deployment account. Rebuild from a known source after closing the entry path. Then issue a narrower replacement credential and verify that the old one returns a denied result.

Usage records can reveal more than cost. Which models were called? From which network locations? At what times? Were requests merely inference, or could the account create files, tools, fine-tunes, or other durable resources? The provider’s product changes the questions, so incident runbooks should list the relevant audit and revocation endpoints before anyone needs them.

Do not infer data theft from token volume alone. In the METR case, the organisation said it found no compromise beyond the single public-model key in March and no sensitive information accessed in either disclosed incident. That finding came from investigation. It would be wrong to turn a large usage number into an unsupported claim about stolen internal material.

The reverse assumption is equally weak. A provider saying “no unusual bill remains” does not prove that the host is clean. Billing evidence and compromise evidence answer different questions. Close both.

After containment, fix the system that made the incident quiet. METR added monitoring, reduced noisy alerts, created public-deployment review, shortened credential longevity, reduced permission scopes, and added spend alerts where possible. These changes address the chain rather than one visible symptom.

A useful post-incident question is: which single control would have limited harm even if every earlier control failed? A hard per-project quota could have limited consumption. A short expiry could have shortened the three-week window. A runtime without access to the raw key could have blocked disclosure. Separate telemetry could have made the usage stand out. Defence improves when several independent answers exist.

What to change before the next public demo

You do not need a large security programme to apply the lesson. Most of the useful work happens when a key is requested, when the app becomes reachable, and when the experiment ends. Put checks at those three moments.

The following sequence is intended for engineering teams, research groups, and small companies running model-backed prototypes. Adapt the numbers to the workload, but keep the boundaries explicit.

1. Give the experiment its own provider identity. Create a separate project, service account, or key for one workload. Name an owner and an expiry date. Do not lend it the team’s general key because the prototype is expected to last only a day.

2. Set the smallest useful authority. Allow only the required models and operations. Remove access to fine-tuning, file stores, administration, private models, or unrelated tools when the experiment does not need them. If the provider cannot scope a key, place a controlled gateway between the workload and the broader account.

3. Put a real ceiling on consumption. Set a provider budget, per-key quota, rate limit, or gateway allowance sized for the run. An alert at 50 percent and 80 percent is useful; denial at the agreed maximum is better. Free credits still receive a ceiling.

4. Keep the raw secret away from the agent. Prefer a broker or service that performs the allowed request without revealing the credential value. If the process must receive a key, do not expose general environment inspection, arbitrary shell access, or logs containing that environment to untrusted prompts.

5. Test authentication from outside. Use a fresh unauthenticated client on an external network. Confirm that protected routes deny access when the identity service works, when it returns an error, and when its configuration is missing. A failed identity check must never produce the application page.

6. Separate the public runtime. Place the service in an account or network segment without routes to production, internal databases, employee devices, or broad secret stores. The server should know only what the public experiment needs.

7. Describe normal use before launch. Record the expected dates, models, request range, owner, and approximate token volume. Route usage and spend alerts to that owner plus someone who can suspend the credential. Test the alert with a harmless threshold before public traffic arrives.

8. Close the experiment deliberately. Revoke the key, remove public DNS and listeners, archive required logs, destroy the temporary runtime, and record completion. An expiry date is a backstop, not a reason to leave abandoned infrastructure running.

9. Practise the leak path. With a fake credential, rehearse revocation, provider-log retrieval, host isolation, and key replacement. Confirm that responders can identify other secrets the runtime could reach. A ten-minute tabletop will expose missing ownership faster than another policy document.

This sequence does not make a prototype invulnerable. It changes the maximum consequence. A broken login may still expose an unfinished interface, but the interface holds a narrow credential with a short life and a hard quota. Monitoring points to one owner. The public host has nowhere useful to move next.

Teams should also search for existing exceptions. List provider keys with no owner, no last-used date, or no expiry. Find public cloud instances outside managed accounts. Review dashboards that rely on an upstream authentication proxy and test their error behaviour. These are ordinary inventory tasks, but they uncover the combinations that make quiet incidents possible.

Start with the keys attached to agents. A conventional application may use a secret for one fixed API call. An agent can choose tools, inspect context, and respond to language supplied by strangers. That added flexibility raises the value of keeping raw credentials outside its view and enforcing limits in code the prompt cannot change.

Free capacity still belongs inside a harness

The number makes the METR incident memorable, but the absence of a bill explains part of the delay. About $600,000 of commercial-value credits could be consumed without a matching financial alarm because the provider had granted them for free. Expected research traffic was already large. The stolen use had room to hide.

The incident also shows that partial boundaries matter. METR separated public-model access from more sensitive model and organisational information, and reported no access to its highest sensitivity classes. That did not prevent the key theft, yet it constrained what the stolen credential represented. Security is often the difference between an exposed experiment and an organisation-wide compromise.

The next improvement is to make that lower tier cheap to lose. Give each experiment its own identity. Limit models and operations. Add a quota that reflects the job rather than the account’s total capacity. Expire the credential. Keep public code away from internal routes, and make failed authentication produce denial instead of a working dashboard.

Monitoring then has a clear subject. The question stops being “is all research usage high?” and becomes “is this three-day experiment behaving within its declared shape?” An alert can reach an owner who knows whether a run is active. Revocation can stop one workload without breaking everyone else’s work.

Fast experiments are valuable. So are free research credits. Neither requires a standing organisation-wide key on a personal internet-facing server. The practical standard is modest: experimental code gets experimental authority, and experimental authority comes with an end.

That is the lesson worth carrying past this week’s headline. Price can reveal abuse, but price is a poor security boundary. Build the boundary around what the credential can cause, then let the invoice serve as one signal among several.

For more calm, practical security explanations, join the newsletter. It is one email per month.

Sources

• METR: Update on Security at METR, accessed 2026-09-02
• Infosecurity Magazine: Attackers Steal METR API Key and Burn $600,000 in AI Credits, accessed 2026-09-02
• The Hacker News: Attackers Steal METR API Key and Consume AI Credits Worth About $600,000, accessed 2026-09-02
• OWASP Cheat Sheet Series: Secrets Management, accessed 2026-09-02