An internet-facing AI-agent dashboard exposed a METR model-provider API key, and an attacker used it for three weeks to consume credits worth approximately $600,000. The attacker also added an SSH key to the underlying cloud server, converting a leaked credential into persistent host access.
The $600,000 figure was the credits’ nominal value. The model developer had granted them to METR for free. In its first-party incident account, the nonprofit says the stolen key reached public models and that its investigation found no compromise beyond that key. It also says neither this event nor a separate May attack exposed its most sensitive data.
METR disclosed the March incident on August 31 after investigating with its security consultant, Calif. The organization evaluates frontier AI systems and holds non-public model access and confidential research material, but the researcher whose personal Amazon EC2 instance was breached did not have access to METR’s two most sensitive data categories.
One Dashboard Failed Open
A METR researcher deployed agents on a personal EC2 instance. The service was meant to sit behind Google authentication, yet the application “included a fail-open vulnerability that silently disabled authentication,” METR wrote. The instance remained open to the public internet for several days and contained a key for METR’s general-access public-model account.
METR suspects the attacker found the service by searching recently registered websites, possibly through certificate-transparency data, for names associated with large language models or agents. That discovery route is an assessment. METR did not say its investigation proved how the attacker arrived.
Once inside, the attacker prompted an agent to reveal the model-provider key. The actor then installed an SSH key for persistence and used the stolen API credential for three weeks. This sequence gives defenders two distinct investigation surfaces: activity on the exposed application and host, followed by model-provider usage tied to the credential.
Long description
The upper lane shows the observed attack path. A public EC2 application held a model API key. A fail-open flaw silently disabled Google authentication. The attacker asked the agent to reveal the key, added an SSH key, and used the API credential for three weeks. The lower lane shows METR’s response: stop and image the EC2 instance, revoke and rotate access associated with the researcher, and verify the scope through internal and consultant-assisted forensics. A final note separates the source’s limits from its findings: METR suspected the discovery method and found no category 3 or 4 data access.
The Theft Hid in Noise
The illicit consumption did not immediately stand out because high-volume, irregular model use was normal in METR’s evaluation work. Researchers were accustomed to large token volumes, unusual rate-limit behavior and API errors that did not always represent real consumption.
Two control gaps deepened the blind spot. METR’s internal usage dashboard did not show rate-limited requests across all users, even when those requests occurred. The free credits also removed a natural billing ceiling, and METR says the provider offered no way at the time to set a spending limit on that type of key.
The useful recognition pattern therefore extends beyond spend. Model-usage monitoring should connect the provider key, requesting workload, user or service owner, source environment and expected rate profile. Rate-limited requests belong in that view because rejected traffic may still reveal sustained abuse. A provider invoice alone would have supplied no alert in METR’s case.
Host telemetry is the second half. A newly authorized SSH key on an internet-facing research instance is a persistence event even when the associated application looks experimental or temporary. Inventory and logging should cover personal or externally managed infrastructure whenever it carries organizational credentials.
METR quantified one affected EC2 instance, one stolen key, three weeks of unauthorized use and approximately $600,000 in nominal credits. It did not report broader victims, access to private models or theft of sensitive research data.
Verification Bounded the Incident
METR responded by revoking the researcher’s access, stopping and imaging the EC2 instance, rotating every credential present, and imaging and wiping the researcher’s laptop. It notified the relevant model provider and kept the company informed during the response.
Calif validated METR’s findings and performed a separate compromise assessment. METR also used manual and agent-assisted forensics to determine whether the attacker moved beyond the exposed instance and key. Its conclusion was bounded: the organization found no compromise beyond the one stolen public-model credential.
That conclusion does not erase a second near miss. In May, financially motivated attackers systematically probed METR’s public infrastructure with automated reconnaissance, credential stuffing, OAuth attempts, phishing and scanning for new services. During the same period, a public transcript viewer inadvertently exposed a read-only SQL mechanism that could have reached unpublished evaluation data, including some sensitive model output.
An independent researcher reported the SQL flaw, and METR took the API offline. METR says attackers probed the endpoint in passing, but its evidence showed no indication that they discovered the exploit or accessed non-public data. The organization temporarily shut down nearly all public services and separated its public production environment from internal infrastructure.
Review Every Public Agent Deployment
Begin with exposure. Enumerate internet-facing agent dashboards and experimental services, including workloads in personal cloud accounts or unmanaged devices. For each deployment, record the authentication mode, fail-open behavior, externally reachable routes, credential inventory, service owner and security-review status. Remove organizational credentials from infrastructure that is outside approved management boundaries.
Teach recognition across both the workload and provider account. Alert on newly added SSH keys, unexpected changes to authentication middleware, sustained rate-limit activity, unusual model selection, sharp usage shifts and requests from unapproved environments. METR added abnormal API-key monitoring, broader logging and spend alerts where providers support them. It also reduced credential longevity and permission scopes.
Contain a suspected exposure as a host compromise and a credential compromise. Preserve an image and relevant logs before wiping the system, revoke active access, rotate every credential present, and determine whether the same identity or key touched other resources. METR also formalized security reviews for public researcher deployments and shut down legacy infrastructure that expanded its attack surface.
Run a production verification test on each representative public agent deployment. Send an unauthenticated request through every supported login path, inspect the resulting access decision, then reconcile cloud-host inventory with the provider’s key-usage and rate-limit logs. The expected result is a fail-closed denial, no organizational credential on unapproved infrastructure, an accountable owner for every active key, and alerts that identify abnormal use before it persists for weeks.