How to Prevent Runaway AI API Credential Costs

An AI API key is not just a login string. It is a pathway to metered computing capacity, and a copied key can continue authorizing requests long after an attacker leaves the application where it was exposed. Cost control therefore belongs in the security design of every AI system, including temporary research tools and internal prototypes.

METR's 2026 disclosure gives this risk a concrete shape. An internet-accessible agent dashboard had a fail-open authentication flaw, meaning the application remained available when its access control failed. METR reported that an attacker reached the dashboard, prompted an agent to reveal a model-provider credential, added an SSH key for persistent host access, and used the stolen credential for three weeks. The consumed credits were valued at approximately $600,000, although METR did not pay that amount because the provider had supplied the credits at no charge.

The useful lesson is not the headline value or the development style of one application. Several independent controls failed to stop the same path. A durable prevention plan assumes that an interface, host, or key may eventually be compromised and limits what can happen next.

Define the blast radius before deploying an agent

Classify an AI application by what an untrusted user could reach through it, not by whether the team calls it a prototype. An experiment becomes operationally significant when it accepts internet traffic, can call a paid or scarce model, can reach nonpublic data, or can invoke tools with effects outside its own process. A short lifespan does not reduce those capabilities.

Create a small deployment record before exposure. Name the owner, public endpoints, cloud account, models, credentials, data stores, tool permissions, expected usage range, expiry date, and shutdown procedure. This inventory makes forgotten experiments discoverable and gives an incident responder a reliable map. Public services should run in an environment architecturally separated from internal systems so that a defect in a viewer or dashboard does not create a route to sensitive infrastructure.

METR's disclosure described a second flaw in a public transcript viewer: a read-only SQL mechanism could be manipulated to expose unpublished evaluation data, and some sensitive output had entered a database that was expected to contain only public-model results. METR said available evidence did not indicate that attackers discovered the exploit or accessed nonpublic information. The episode still shows why intended data classification is not enough. Isolation must cover where records are stored, how queries are scoped, and whether restricted material can be placed in a public-facing data store.

Set one rule that is easy to enforce: internet exposure or access to live credentials automatically triggers a baseline security review. The review can be lightweight, but it should confirm deny-by-default authentication, managed hosting, named ownership, logging, credential boundaries, and an end date.

Keep raw secrets outside the agent's reach

An application may need permission to call a model, but the model does not need to read the reusable credential. Store secrets outside prompts, transcripts, environment inspection tools, files the agent can open, and command output the agent can return. Instructions such as "never reveal this key" are not a security boundary because a language model processes untrusted instructions and can be manipulated into disclosing accessible information.

Place a broker or narrowly defined service between the agent and the provider. The agent requests an allowed operation; the broker holds the credential, validates the request, applies policy, records usage, and returns only the necessary result. Limit the broker to approved models and operations. Where provider features permit, issue separate credentials for each application and environment, reduce permission scopes, and use short lifetimes.

Separate identities make both containment and investigation easier. If one key serves multiple experiments, high usage has many plausible explanations and revocation disrupts unrelated work. A key dedicated to one workload has a smaller behavioral range, a clear owner, and a practical kill switch. Short-lived credentials also reduce the period in which a copied value remains useful, while narrowly scoped permissions limit what the attacker can do during that period.

Host access needs its own boundary. The METR attacker added an SSH key after entering the exposed system, so rotating only the provider credential would not have removed persistence. Monitor changes to remote-access configuration, restrict who can add keys, and treat a new persistent access method as an incident even when API consumption still looks ordinary.

Turn budgets into enforced safety limits

A spending alert is useful, but an alert is only a request for a person to investigate. Prefer a hard provider or broker limit that rejects further use once the approved budget is exhausted. Apply limits at multiple levels when available: organization, project, application credential, and time window. A monthly account ceiling alone can still allow a damaging burst early in the period.

Some providers or account arrangements may not expose a direct spending cap. METR said it could not place one on the affected key at the time, and donated credits removed the rising invoice that might otherwise have triggered attention. In that situation, recreate the boundary in the calling layer. A credential broker can count requests or tokens, enforce daily and per-run allowances, limit concurrency, and suspend access when a threshold is crossed. Granted or prepaid capacity should be treated as an asset with a replacement value even when current cash billing is zero.

Choose thresholds from the credential's declared purpose. A scheduled evaluation, an interactive dashboard, and a batch job should not share the same limits. Define an expected maximum for a single run, a rolling hourly or daily ceiling, and a maximum rate of failed or rejected requests. Document who can approve a temporary increase and when that exception expires. Otherwise, emergency overrides quietly become the normal operating envelope.

Enforcement must fail closed. If the authentication service, policy check, usage counter, or approval lookup is unavailable, the system should deny or sharply restrict the protected operation. A degraded monitoring service should not silently convert a limited credential into an unlimited one.

Detect behavior that a bill cannot show

High token volume is not automatically suspicious in research or evaluation work. METR explained that legitimate experiments could generate substantial usage, rate-limit responses, and provider errors. Its internal dashboard also did not show every user's rate-limited requests during the incident. That combination allowed unauthorized activity to blend into familiar operational noise.

Build baselines around identity and purpose instead of watching only total account volume. For each application credential, retain the request time, model, outcome, token or usage quantity, originating workload, and responsible owner where those signals are available. Include failed and rate-limited attempts, because reconnaissance and attempted consumption may never appear in successful-use totals. Do not place the raw secret in logs.

Useful anomaly rules compare current behavior with the deployment record. Examples include activity outside the workload's schedule, sustained use after a planned experiment ended, an unfamiliar origin, a model the application was not approved to call, an unusual ratio of errors to successes, or a sudden change in request rate. These signals are more actionable than a generic "high usage" alert because they explain which expectation was violated.

Tune alerts without deleting important evidence. Noisy rate-limit messages should be grouped and summarized, not omitted from the dashboard. The target is a manageable alert stream backed by complete searchable events. Every alert needs a named responder, severity, investigation deadline, and automatic escalation path. An unowned warning is only stored telemetry.

Design an agent dashboard for decisions

A useful operations dashboard should answer four questions quickly: which credential changed behavior, what it is allowed to do, how much value is currently at risk, and which action will contain it. Present usage and failures by credential, application, model, and time window rather than only as an organization-wide total. Show hard-limit consumption, temporary exceptions, credential age, last rotation, owner, and whether the associated deployment is still approved.

Place security and cost signals together. A burst of provider errors, a new SSH key, an authentication failure, and continued API use may look minor in separate tools but form a clear incident chain when correlated. Preserve enough history to compare current behavior with the same workload's normal pattern and to reconstruct the sequence later.

The dashboard should provide or link directly to tested containment actions: disable the application credential, stop the workload, remove public access, and contact the provider. Destructive controls need appropriate authorization, but they should not depend on finding an undocumented command during an active incident. Record who took each action and when.

Rehearse a credential response drill

Run a tabletop or controlled drill around a copied key. Start with a credible signal, such as sustained off-schedule traffic plus repeated rate-limit errors. Ask the on-call responder to identify the owner, confirm the affected provider account, disable the credential, stop or isolate the workload, and check the host for persistence. The team should then rotate related credentials, preserve logs and a forensic image where appropriate, notify the provider, and determine whether data or other systems were reachable.

Revocation is the first containment step, not the end of the investigation. METR's response included stopping the compromised instance, creating a forensic image, rotating credentials, examining and wiping the researcher's laptop, informing the model company, and using external security assistance. The exact sequence will vary, but the principle is stable: remove current access while preserving enough evidence to determine how the compromise happened and what else must change.

Measure the drill by elapsed time and missing information. How long did discovery, ownership lookup, revocation, host isolation, and provider contact take? Which logs were incomplete? Could responders distinguish granted credits from billed usage? Update the deployment template, dashboard, and runbook after each exercise.

Implementation checklist

• Inventory every internet-facing agent service, its owner, expiry date, cloud environment, credentials, data, and tools.
• Require deny-by-default authentication and a baseline review for public exposure or live credential access.
• Keep provider secrets outside model-readable context, transcripts, tools, and retrievable files.
• Use per-application credentials with the narrowest available scope and practical lifetime.
• Route calls through a broker when direct provider controls cannot enforce the required policy.
• Set per-run and rolling usage ceilings; add a hard stop wherever the provider or broker supports it.
• Monitor successful, failed, and rate-limited requests by credential and expected workload.
• Alert on behavioral mismatches, not just aggregate cost or token volume.
• Correlate model usage with authentication and host-persistence events in the agent dashboard.
• Give every alert a responder, deadline, escalation route, and tested containment action.
• Rehearse key revocation, workload isolation, evidence preservation, provider notification, and recovery.
• Retire credentials and public endpoints when the experiment ends, then verify that traffic has stopped.

Runaway API cost is best prevented by overlapping limits. Secret isolation blocks easy extraction, narrow identities reduce blast radius, enforced budgets limit consumption, behavioral monitoring shortens detection, and response drills make revocation routine. None depends on correctly guessing how the next attacker will enter. Together, they turn a stolen key from an open-ended resource into a contained, observable incident.