METR — Model Evaluation and Threat Research — is the non-profit that evaluates frontier AI models for their ability to carry out long, agentic tasks. It has now published an account of two security incidents of its own.

The first one is worth reading closely, because the way the credential left is new.

The attacker prompted the agent

A METR researcher was running agents on a personal EC2 instance that was supposed to sit behind Google authentication. The application had a fail-open flaw that silently disabled authentication, and the agent orchestration dashboard sat publicly accessible for several days.

In March 2026, the attacker prompted an agent to reveal its API key. Not a config file, not a repository, not an environment variable read off a compromised host — they asked the thing holding the credential, and it told them, because answering is what it does. Every agent framework puts credentials somewhere the agent can reach, which makes that context a credential store with a natural-language interface and no access control worth the name.

Any path that lets an unauthenticated party talk to the agent is therefore a path to whatever the agent holds. We have written about a refusal being the thing an attacker wanted; this is the inverse and simpler problem — compliance is the thing an attacker wanted.

The attacker also added an SSH key for persistent access, which is the ordinary half of the story.

How they found it

METR suspects the instance was discovered by looking through recently-registered websites — certificate transparency lists are named — for high-signal keywords relating to LLMs or agents.

Certificate transparency is a defensive mechanism. Every TLS certificate issued is logged publicly so that misissuance can be caught. It is also, read the other way, a real-time feed of newly-created internet-facing things, searchable by name.

If you stand up something at an obviously AI-flavoured hostname, you are announcing it. The window between a certificate being issued and the service being hardened is a window somebody is watching.

About the $600,000

METR says the consumed credits would have been "approximately $600,000 in bills had it not been provided to the non-profit for free by the model provider", over roughly three weeks. The provider is not named.

So: no money changed hands. The figure is a list price for donated credits, and headlines that render it as "$600,000 stolen" will be wrong. METR was careful about this and the carefulness deserves to survive the retelling.

What the number does tell you is scale — three weeks of unmetered frontier-model inference is a lot of compute, and the account was for publicly available models, not anything privileged.

Nothing sensitive was reached. METR's words: no sensitive information is believed to have been accessed, and no evaluation data or research results were taken.

The second incident is the near-miss

In May 2026, METR's infrastructure was systematically probed, and an inadvertently exposed read-only SQL query mechanism in its public transcript viewer could have given access to unpublished evaluation data. The database, meant to hold only non-sensitive models, had accidentally included sensitive model data.

An independent security researcher found and reported it. METR found no indication that the probing party discovered the exploit or accessed any non-public data.

Publishing the one that did not happen, alongside the one that did, is the part of this disclosure that should be normal and is not.

Why it matters that it was METR

Say this without smugness, because the smug version is wrong.

METR's job is measuring whether frontier models can do dangerous things autonomously. If any organisation should have an intuition for what an agent with credentials can be talked into, it is this one. It still had an auth check fail open on a researcher's instance for several days.

That is not an argument that METR is careless. It is an argument that the failure mode is genuinely hard: the instance was personal, the authentication was thought to be in place, and the failure was silent. Every one of those three conditions exists in most research organisations right now.

What to do

  • Assume anything in an agent's context can be read out of it. Scope credentials to the narrowest thing the agent needs and give them short lives, because the agent will disclose them if asked nicely.
  • Test that authentication fails closed. A silent auth bypass looks exactly like a working system. Deliberately break the identity provider in staging and confirm the app refuses rather than proceeds.
  • Set spend alerts. METR added them "where possible" after the fact — an admission worth noting, because for donated or credited accounts the billing signal that would have caught this in a day may not exist.
  • Watch your own certificate transparency footprint. If a hostname announces what it is before it is hardened, either harden first or do not name it that.
  • Treat researcher-run personal infrastructure as production. It held a production key.

What is not established

  • Who did this. No attribution is offered.
  • Which provider. METR does not name the model provider, and the credit arrangement is not described in detail.
  • Whether the two incidents are connected. March and May are described separately and nothing links them.
  • What the compute was used for. Three weeks of frontier inference bought something; nothing published says what.
  • Whether the fail-open flaw was in METR's own code or a dependency. The account describes the behaviour, not the source.