METR 测试环境里，一把模型密钥被取走用了三周：烧掉约 60 万美元赠送额度，验证失效与看板盲区都没拦住In METR's test environment, a provider API key was taken and used for three weeks, burning about $600,000 in donated credits, while a failed-open check and a dashboard blind spot let it run

METR's official security update: in its test environment, a personal EC2 instance was deliberately opened to the public internet behind Google authentication, but a fail-open flaw in the application silently switched that authentication off, leaving the system exposed for days; the attacker also added an SSH key for persistence. Agents held provider API keys in plaintext and could hand them over on request.

One key was taken and used continuously for three weeks, consuming inference credits worth about $600,000 (donated test credits; METR did not pay out of pocket). Free-tier keys had no spending cap at the time, and there was no way to set one; the internal usage dashboard did not show rate-limited request data to all users, so the anomaly hid in everyday noise.

Keys in plaintext in the agent's hands, no cap on credits, authentication that could fail silently, and a dashboard with a blind spot: four defences were decorative at once, and the theft ran for three weeks before anyone noticed.

The case therefore belongs to the Access Control layer: how keys are kept and how spending is bounded set the ceiling on what a single compromise costs.

Keys in custody, not in the model's pocket: raw keys are held encrypted by the gateway; agents carry virtual keys only, never touch and never output a real key.

A cap on every key: budget and rate limits per team, free-tier credits included, no exceptions.

Usage down to each key: dashboards report per user and per key, and anomalous consumption alerts separately instead of mixing into routine rate-limit noise.