An AI Agent Leaked Its API Key. METR Says $600,000 In Credits Were Used

September 3, 2026

METR says an exposed AI-agent dashboard let an attacker extract a provider key and use $600,000 in donated credits. Here is what failed and what remains unclear.

An attacker found an exposed AI-agent dashboard, prompted the agent to reveal its model-provider API key, and used that credential for three weeks. METR says the consumed credits were worth about $600,000—but the provider had donated them, so METR did not receive a $600,000 bill. The incident shows how ordinary authentication, secret-management, and monitoring failures can turn an AI agent into a credential-disclosure path.

Research note: Published September 3, 2026. Reporting and documentation were checked through 7:30 AM Central Time.

Who This Is For

This guide is for developers, founders, security teams, AI researchers, and anyone deploying an agent that can reach model credentials, cloud resources, files, or administrative tools.

It is also useful for people comparing a hosted AI workspace with a self-managed agent stack. Running your own dashboard can give you more architectural control, but it also makes you responsible for authentication, internet exposure, secrets, budgets, alerts, software review, and incident response.

The main lesson is not “never use agents.” It is that an agent must be treated as an application operating inside a security boundary—not as a trustworthy colleague who can safely see every secret its process can reach.

What Is Confirmed

METR’s primary security update describes two separate incidents involving external attackers earlier in 2026. METR is a nonprofit that evaluates frontier AI systems, including long-horizon agent capabilities.

For the March incident, METR confirms that:

The number needs careful wording. METR says the model developer had granted those credits free, so the organization did not pay a $600,000 invoice. The figure represents METR’s estimate of the credits’ value, not a verified cash loss.

METR also confirms why the usage was not recognized immediately. Its normal evaluation work generates unusual token volume and rate-limit behavior; its dashboard did not expose every user’s rate-limited requests; and free credits produced no natural spending ceiling. High consumption looked too much like legitimate high consumption.

The Register, The Hacker News, and ITPro subsequently covered the disclosure. Those reports establish attention, but the incident facts still come primarily from METR’s own investigation.

The Second METR Incident Was Different

METR’s May incident should not be blended into the API-key story.

In May, METR says financially motivated attackers conducted a sustained campaign against its public infrastructure. The campaign used agents for automated vulnerability discovery, credential stuffing, OAuth-token attempts, service scanning, and phishing.

During roughly the same period, METR discovered that its public transcript viewer exposed a read-only SQL query mechanism. A bug could theoretically reach unpublished evaluation data, and some sensitive model data had accidentally been placed in a database that was supposed to contain only less-sensitive material.

An independent researcher reported that flaw. METR took the API offline and paid a bounty. METR says the attackers probed the endpoint in passing but that its evidence shows no indication they discovered the exploit or accessed non-public data.

That distinction matters: a system can contain a serious data-exposure path without evidence that an attacker used it. The confirmed March impact was stolen model access and resource consumption. The May event was a dangerous near-miss involving public infrastructure and incorrectly separated data.

What Is Still Unclear

METR’s disclosure is unusually specific, but it does not answer every forensic question.

Public evidence does not identify:

METR says its consultant validated its findings and performed a compromise assessment. The public article does not include the consultant’s complete report or raw evidence.

The safest conclusion is narrow: once the attacker reached the exposed agent dashboard, the agent was able to disclose a provider credential it could access. The disclosure does not prove that every agent will reveal every environment variable, that the model independently chose to steal anything, or that a hidden instruction in an ordinary web page caused this incident.

Was This Prompt Injection?

Not in the most commonly discussed sense.

Indirect prompt injection usually means an agent encounters malicious instructions inside untrusted content—such as a web page, email, document, issue, or tool response—and treats those instructions as commands. The attacker in METR’s account instead had direct access to the exposed orchestration interface and prompted the agent to reveal its key.

That is still an AI-specific disclosure route. A traditional dashboard bug might expose a configuration page or shell. Here, natural language became another interface for extracting a secret available to the agent runtime.

The practical boundary is simple: if a model can read a secret, assume a user, injected document, compromised tool, malicious plugin, debugging request, or unexpected agent behavior may cause that secret to appear in output. Prompt policies can reduce risk, but they do not replace access control.

This complements—not duplicates—evidence that AI reasoning logs can contain API keys and that exposed AI servers and MCP tools create independent attack surfaces. The METR incident adds a confirmed operational chain from public exposure to conversational secret extraction and sustained resource abuse.

Why “It Was Behind Login” Was Not Enough

Authentication only protects a service when the entire request path fails closed.

A fail-open condition does the opposite. If an authentication component is missing, misconfigured, unreachable, or returns an unexpected error, the application continues as though access were allowed. A login screen may exist in the intended architecture while the deployed route is still public.

This is why visual verification is weak security evidence. Seeing a Google sign-in page during one test does not prove every route, protocol, host, deployment mode, or error path enforces authentication. The deployed service has to reject unauthorized requests when identity checks fail, not merely when they succeed with the wrong user.

METR suspected the exposed instance was discovered through recently registered domains or certificate-transparency data associated with high-signal AI terms. The broader lesson is that an obscure hostname is not private. Automated scanners can discover new services quickly, and AI-themed dashboards are attractive because they may contain valuable provider keys.

Why The Key Had Such A Large Blast Radius

An API key is usually a bearer credential: whoever possesses it can use the authority attached to it. The provider may not know whether a request came from the intended application or an attacker.

Four controls determine the blast radius:

  1. Scope: Which models, endpoints, projects, data, and administrative functions can the key reach?
  2. Lifetime: How long does the credential remain valid without rotation or expiration?
  3. Quantity: What rate, token, or spend limits apply?
  4. Detection: Can the owner distinguish legitimate high usage from theft quickly?

METR’s account shows all four interacting. The key was for public models rather than its most sensitive model access, which limited confidentiality risk. But the credential remained usable for weeks, free credits lacked a natural billing stop, and anomalous usage blended into high-volume evaluation traffic.

Google Cloud’s API-key guidance recommends restricting keys, isolating them by application and user, monitoring usage, rotating them, deleting unneeded keys, and moving to stronger short-lived identity mechanisms where possible. The OWASP Secrets Management Cheat Sheet likewise emphasizes least privilege, rotation, revocation, expiration, auditing, and centralized handling.

No single one of those controls is sufficient. A perfectly stored but unlimited key can still be abused after runtime compromise. A tightly capped key can still expose data within its allowed scope. An alert can reduce dwell time but cannot erase requests already made.

The CREDIT Check For AI-Agent Secrets

Use the CREDIT check before connecting an agent to a model provider or another paid API.

C — Close Every Unnecessary Public Route

Inventory domains, subdomains, IP addresses, tunnels, load balancers, preview deployments, notebook servers, dashboards, WebSocket endpoints, and alternate ports. Require authentication at a dependable enforcement layer and test that failures deny access.

R — Restrict And Rotate Every Credential

Give each workload its own key, use the narrowest available model and endpoint permissions, and prefer short-lived credentials. Rotation must include deletion or revocation of the old secret; creating a replacement while leaving the exposed key active does not contain the incident.

E — Enforce Rate And Spend Ceilings

Set provider quotas, project budgets, request-rate limits, concurrency limits, and automated circuit breakers. Free or prepaid credits still need limits because attackers value compute even when the account owner will not receive an invoice.

D — Detect Behavior, Not Just Billing

Alert on new source networks, unusual models, long-running bursts, repeated rate-limit errors, atypical hours, unexpected user agents, and changes in output-token patterns. A cost alert alone may be silent when credits are free or usage has not yet reached the billing system.

I — Isolate Public Tools From Sensitive Systems

Treat a research dashboard, demo, transcript viewer, or prototype as hostile-facing infrastructure. Separate its identity, network, database, secret store, cloud account, and provider project from internal and sensitive environments. METR says it created an isolated public production environment after the incidents.

T — Test The Real Failure Paths

Test expired sessions, unavailable identity providers, malformed headers, alternate hosts, direct-IP access, forgotten routes, and a synthetic secret that the agent can see but should never disclose. Review logs and alerts after the test. A passing happy-path login is not enough.

What To Do If An AI API Key May Be Exposed

Treat suspicion as a credential incident, not as a prompt-engineering problem.

  1. Revoke or delete the suspected key immediately. Do not wait to finish the root-cause analysis.
  2. Rotate related credentials. Check environment files, process variables, shell history, logs, snapshots, images, notebooks, agent memory, tool configuration, and co-located secrets.
  3. Stop public access. Disable the service or place it behind verified authentication while preserving evidence needed for investigation.
  4. Review provider usage. Compare models, timestamps, source networks, token patterns, projects, and rate-limit events with known workloads.
  5. Check persistence. METR says its attacker added an SSH key, so reviewing only the provider key would have missed continued host access.
  6. Contact the provider and your incident-response owner. Ask about revocation timing, abuse investigation, logs, billing exposure, and preservation requirements.
  7. Rebuild from a trusted state when appropriate. Removing one credential from a compromised host does not prove the host is clean.
  8. Prove the fix. From an unauthorized network and a fresh browser, verify that the service rejects access and that old credentials fail.

If regulated, customer, employee, or confidential data might have been reachable, involve qualified security and legal personnel. This article is general technical education, not incident-response or legal advice.

Does Using A Hosted AI App Avoid This Risk?

A hosted product changes who operates the infrastructure; it does not eliminate every security or privacy risk.

When you use a hosted AI workspace, you typically do not deploy the agent dashboard or store the underlying provider API key yourself. That can remove an entire class of self-hosting mistakes from your personal environment. The provider instead becomes responsible for its application boundary, authentication, secrets, routing, monitoring, and vendors.

The tradeoff is that active requests still leave your device for processing. You must evaluate the hosted service’s history model, retention statements, provider disclosures, training rules, account controls, and incident response. The private AI chat versus local AI comparison explains why “hosted” and “local” are architectural choices rather than automatic privacy grades.

Self-hosting can offer greater control, and fully local inference can keep more content on your hardware. But a cloud VM running a local-looking dashboard is not fully local, and a model downloaded to a server does not secure the surrounding web application. The runtime, network, secrets, authentication, tools, and logs determine the real boundary.

What This Means For OpenVeil

OpenVeil is an 18+ hosted, privacy-focused AI workspace. Normal private-chat history is kept in the user’s browser, and OpenVeil does not maintain a server-side chat-history record for those sessions. OpenVeil also states that it does not use prompts, uploads, images, audio, selected local-history context, or outputs to train foundation models.

That is a different product boundary from deploying your own public agent-orchestration dashboard. A user can access chat, web search, files, voice, image tools, video tools, and custom personas without installing a model server or managing a model-provider API key.

The METR incident does not prove that OpenVeil or its providers had a similar breach. It also does not mean browser-local history protects secrets inside a compromised device, malicious extension, uploaded file, active request, provider system, or separate infrastructure service. Active requests still require processing by OpenVeil and necessary AI, search, upload-processing, hosting, routing, security, billing, and infrastructure providers.

OpenVeil is not fully offline, anonymous, zero-log, HIPAA compliant, or a substitute for a secrets manager, secure coding review, network isolation, or incident response. Its relevant fit is narrower: adults who want hosted AI convenience and a browser-local normal chat-history model without operating their own AI infrastructure.

Before trusting any provider—including OpenVeil—use the AI privacy-claim checklist and separate content retention from infrastructure security.

What This Incident Does Not Prove

METR’s disclosure does not establish that:

The confirmed chain required several conditions: a publicly reachable service, fail-open authentication, a credential accessible inside the agent environment, sufficient key authority and lifetime, and monitoring that did not quickly separate abuse from expected usage.

Breaking any one of those links might have reduced the impact. Strong systems try to break several.

FAQ

Did METR Lose $600,000?

METR says the consumed model credits would have been worth approximately $600,000, but the provider had granted those credits free. The public disclosure does not describe a $600,000 invoice or cash payment by METR.

Did The AI Agent Reveal Its Own API Key?

METR says an attacker prompted the agent directly to reveal its model-provider API key. Public evidence does not specify exactly where the agent read the key or reproduce the prompt and response.

Was Sensitive Model Data Stolen?

METR says it believes no sensitive information was accessed in either incident. Some sensitive model data was theoretically reachable through a separate May transcript-viewer flaw, but METR says its evidence indicates attackers did not discover that exploit or access non-public data.

Would A System Prompt Saying “Never Reveal Secrets” Have Stopped It?

That instruction may reduce casual disclosure, but it is not a dependable security boundary. The stronger design is to keep the secret outside the model’s readable context, scope it narrowly, limit its lifetime and usage, and detect abuse.

Can A Stolen AI API Key Expose Chat Data?

It depends on the provider and key permissions. Some keys authorize only new inference requests; others may reach stored files, logs, fine-tuning data, assistants, projects, or administrative functions. Check the exact permission model instead of assuming every AI key has the same blast radius.

Is A Private Cloud Dashboard Safe If Its URL Is Secret?

No. Certificate-transparency logs, DNS records, IP scanning, crawlers, referrers, shared screenshots, browser history, and configuration mistakes can reveal a service. Access control must enforce identity even when an attacker knows the exact URL.

Is OpenVeil A Replacement For A Self-Hosted Agent Stack?

Only for users whose goal is a hosted AI workspace rather than operating arbitrary autonomous infrastructure. OpenVeil provides chat and media tools with browser-local normal chat history, but it is not a general agent hosting platform, secrets manager, or network-security product.

Bottom Line

METR’s disclosure is a concrete warning about layered failure. The agent did not create the public exposure, the long-lived credential, the missing spend ceiling, or the noisy monitoring environment. But once an attacker reached the dashboard, conversational access became a route to the secret, and the stolen key remained valuable for weeks.

Protect AI credentials with architecture, not trust: fail-closed authentication, inaccessible secrets, narrow scopes, short lifetimes, spend limits, behavior alerts, isolated public services, and tested revocation. If you do not need to operate that infrastructure yourself, a hosted workspace may reduce your personal deployment burden—but it still deserves a precise review of processing, retention, and provider boundaries.

Sources

Prepared by the OpenVeil editorial team from the cited primary disclosure, current technical guidance, and contemporary coverage. Material claims are attributed; inferences and limits are labeled.

When privacy, account control, uploads, and search matter, OpenVeil gives you a private AI workspace designed for that job.