Vibe-Coded and Vulnerable: What the METR API Key Theft Teaches Healthcare AI Security Teams

AI Security

METR — Model Evaluation and Threat Research, the non-profit that evaluates frontier AI models for agentic capability — disclosed two security incidents on August 31, 2026. The first resulted in approximately $600,000 in consumed AI credits. The second was a sustained, agent-automated attack campaign that came within a bug report of accessing unpublished evaluation data on frontier models.

Neither incident involved sophisticated nation-state tradecraft. Both involved failure modes that are increasingly common in organizations deploying agentic AI: vibe-coded infrastructure with invisible security debt, no spend monitoring on AI credentials, exposed endpoints in newly deployed services, and attackers using agents to automate the same vulnerability discovery that defenders are still doing manually.

METR disclosed these incidents publicly and shared findings with AI companies in advance of publication. That transparency is worth acknowledging — and the incident details are worth reading carefully, because the failure modes aren't unique to AI safety research organizations.

Incident 1: A Vibe-Coded App, a Fail-Open Vulnerability, and $600,000 in Consumed Credits

In March 2026, one of METR's researchers ran AI agents on a personal EC2 instance that was intentionally made publicly accessible behind Google authentication. The instance contained an API key for METR's general-access account — access to public models, not internal frontier model data. The researcher had no sensitive system access.

The problem was the app itself. It was vibe-coded — built with AI assistance — and it contained a fail-open vulnerability that silently disabled authentication. The agent orchestration dashboard was exposed to the public internet for several days with no authentication required and no alert fired.

Attackers found it using a targeting method that deserves specific attention: they scanned certificate transparency logs for recently-registered websites with high-signal keywords related to LLMs and agents, specifically hunting for vibe-coded sites likely to contain exposed model provider API keys. This is not opportunistic scanning — it's a deliberate, systematic technique for finding the exact class of infrastructure that the current AI deployment wave is producing at scale.

Once they found METR's instance, the attack was straightforward. They prompted the exposed agent directly to reveal its model provider API key. They added an SSH key for persistent access. Then they used the stolen credentials to run inference against publicly-available models for three weeks, accumulating what would have been approximately $600,000 in charges — had METR been paying for the credits rather than receiving them from the model provider.

METR didn't catch it for three weeks because their normal operations consume large volumes of tokens, and there were no spend caps or anomaly alerts on the compromised key. When you can't distinguish attacker usage from your own baseline, you have no detection signal.

Angle 1: Vibe-Coding as Infrastructure Security Risk

The term "vibe-coded" is doing real work in METR's disclosure. It describes a development pattern where AI-assisted code generation produces functional-looking output that contains security flaws the developer never intended and may not recognize. The fail-open vulnerability in this case — code that silently disables authentication rather than failing closed — is exactly the kind of subtle, high-consequence flaw that AI code generation produces when the developer isn't explicitly prompting for security properties.

Fail-open is a specific and well-documented failure mode: when an error occurs in an authentication or access control mechanism, the code defaults to allowing access rather than denying it. It's the opposite of the correct behavior. It's also the kind of flaw that passes functional testing — the app works, users can log in, features behave as expected. The security property that's broken is invisible unless you test for it specifically.

For healthcare organizations deploying agentic AI: the vibe-coding risk is not hypothetical and not limited to research organizations. Healthcare AI deployments increasingly involve custom dashboards, integration layers, workflow automation tools, and agent orchestration interfaces — many of which are being built with AI code assistance by developers who are not security engineers. Every one of those components that sits in front of a credential, an API key, or a clinical data endpoint is a potential fail-open waiting to be found.

The OWASP AST10 framework we covered last week explicitly calls out over-privileged skills and weak isolation as top risks for agentic deployments. The METR incident adds a third dimension: the development practices that produce the infrastructure those skills run on. Secure by Design isn't just for software vendors — it applies to internally-developed agentic infrastructure as well.

Angle 2: Certificate Transparency Logs as an Attack Surface

The attacker's initial reconnaissance method is the most technically novel element of the March incident. Certificate transparency (CT) logs are a public, append-only record of every TLS certificate issued by participating certificate authorities. They exist to improve the integrity of the CA ecosystem — anyone can monitor them to detect unauthorized certificates issued for their domains.

Attackers are now using CT logs offensively: scanning for recently-registered domains with LLM and agent-related keywords, then probing those sites for exposed API keys and agent infrastructure. The logic is sound. Organizations deploying new AI infrastructure register new domains, obtain certificates, and deploy — often without the same security review process applied to production systems. The CT log is a real-time feed of exactly that new infrastructure.

For healthcare security teams: CT log monitoring is already a recommended practice for detecting phishing domains and unauthorized certificate issuance for your own domains. The METR incident adds a defensive use case — monitoring your own recently-issued certificates to ensure that newly deployed infrastructure hasn't been indexed by attackers before your security team has reviewed it. Any domain you register for an AI tool, agent dashboard, or API endpoint is visible in CT logs within minutes of certificate issuance. If your deployment process doesn't include a security review before that certificate goes live, you're racing an attacker who's already watching the feed.

Angle 3: No Spend Caps, No Detection Signal

Three weeks. That's how long the March incident ran before detection — not because METR lacked monitoring sophistication, but because they had no spend anomaly alerts on the compromised key and their normal operations consumed enough tokens that attacker usage didn't stand out.

This is a detection gap that is structural in most AI deployments. API keys for model inference don't come with detection out of the box. Most organizations set up keys, grant them to applications or researchers, and treat them like any other service credential — managed in a secrets store, rotated on a schedule, but not actively monitored for usage anomalies. When an attacker steals a key and uses it at a volume that blends with normal operations, there is no alert.

The fix METR implemented — spend alerts and caps on keys where possible — is the correct first step, but it requires knowing what "normal" looks like for each key. That requires per-key usage logging with enough history to establish a baseline, anomaly thresholds set at a meaningful level, and alerting routed to someone who will act on it. For organizations where AI API spend is a line item managed by finance rather than security, none of that infrastructure typically exists.

For healthcare: if your organization uses AI APIs — for clinical decision support, coding assistance, ambient documentation, or security tooling — the credential management question is whether you have per-key spend monitoring, caps, and anomaly alerting. If the answer is "we rotate keys on a schedule," that's access control, not detection. The METR incident shows that three weeks of attacker API usage can be invisible without the latter.

Angle 4: Attackers Using Agents to Automate Vulnerability Discovery

The May 2026 incident is the one with broader implications. METR describes it as a sustained external campaign by a likely financially motivated threat actor, using agents to automate vulnerability discovery across their publicly accessible infrastructure. The specific techniques: credential stuffing authentication providers, attempting OAuth token grants, scanning newly deployed services, and phishing staff.

The agent-automation angle is what makes this significant. CISA's Vulnerability Review, which we covered last week, explicitly identified AI-enabled vulnerability discovery as the reason they published a pre-AI baseline now — because AI is automating the full exploitation pipeline. The METR May incident is a documented real-world example of that prediction in practice. Attackers used agents to systematically probe infrastructure at a scale and speed that would have required significantly more human time and skill without automation.

The nearly-exploited SQL endpoint adds specificity to the risk. METR's public transcript viewer had a read-only SQL query mechanism built in. A bug in the component could have allowed access to unpublished evaluation data. The database accidentally included sensitive model data. An independent security researcher found and reported the issue before the attackers did — but the attackers had probed the endpoint. The margin between a near-miss and a breach was a bug report arriving first.

For healthcare: the May incident maps directly onto the threat model for any organization running publicly accessible AI infrastructure — patient-facing AI tools, provider portals with AI features, API endpoints for AI-assisted clinical workflows. Attacker-automated scanning of newly deployed services is not a future threat. It's the current operational baseline for financially motivated threat actors targeting AI infrastructure.

Angle 5: The Healthcare Parallel

The failure modes in both METR incidents are not specific to AI safety research. They're the failure modes of AI deployment at pace, which is what healthcare is doing right now across clinical AI tools, ambient documentation systems, AI-assisted coding, and agentic workflow automation.

Vibe-coded infrastructure is in healthcare environments. Clinical operations teams, revenue cycle groups, and IT departments are building AI-assisted workflow tools with the same development patterns METR describes — AI-generated code, deployed quickly, not reviewed for security properties like authentication failure behavior. The fail-open pattern doesn't announce itself. It ships.

Certificate transparency exposure is healthcare's problem too. Every new AI tool deployment that gets a domain and a certificate is visible in CT logs. Healthcare organizations are deploying AI tools faster than security review cycles can keep up. The gap between "domain registered" and "security team aware" is the window the METR attacker used.

API key monitoring is absent in most healthcare AI deployments. Healthcare organizations using AI APIs for clinical documentation, coding assistance, or decision support typically manage those credentials as service accounts — not as actively monitored detection surfaces. The METR incident demonstrates what three weeks of undetected attacker usage looks like even in a security-aware organization.

Agent-automated probing is coming for healthcare AI infrastructure. METR is a frontier AI safety organization — a high-value target. Healthcare AI infrastructure, particularly anything connected to EHR APIs, clinical data, or patient-facing tools, is equally high-value for financially motivated actors seeking model access or data. The same agent-automated scanning techniques used against METR will be used against healthcare AI endpoints.

The METR disclosure is a useful document for healthcare AI security programs precisely because it's specific. It names the failure modes, describes the attack techniques, and quantifies the impact. The question for healthcare security teams is not whether these risks apply — they do — but whether the controls that METR lacked (authentication testing for AI-built apps, CT log monitoring for newly deployed services, per-key spend monitoring, agent-automated probing detection) are in place in your environment.

What METR Did After

METR's post-incident response is worth noting. After the March incident they updated policies around putting METR credentials or data on non-METR infrastructure, improved monitoring, and added spend alerts on keys where possible. After the May incident they took the SQL endpoint offline and reviewed their database configuration. They shared findings with AI companies they work with before public disclosure.

The transparency is the right model. Security incidents in AI infrastructure are not going to become less frequent as agentic deployment accelerates. Organizations that disclose clearly, describe failure modes specifically, and share findings upstream are contributing to the collective defense. The details in METR's disclosure are more useful to the security community than a generic "we had an incident and have taken steps to address it" statement.