# What to do when an AI tool exposes your provider keys

> Respond to exposed AI provider keys: revoke the credentials at their source, inspect usage, replace shared access, and distinguish alerts from hard limits.

Author: [Flavio Copes](https://flaviocopes.com/about/) | Published: 2026-11-01 | Topics: [AI](https://flaviocopes.com/tags/ai/) | Canonical: https://flaviocopes.com/agent-vendor-key-breach/

You paste an API key into an AI tool so it can call a model for you. Later, the tool reports unauthorized access to stored credentials.

Removing the key from that tool doesn't invalidate a copy someone already took. The credential belongs to the model provider, and that is where you need to revoke it.

This guide covers that response, including the checks to make before reconnecting a tool. It applies to hosted coding services and model gateways that accept your own provider keys. Use the vendor's notice to identify the affected product and time window; a local client and a hosted account can store credentials in different places.

## Find the credential's actual owner

An AI application can involve several accounts. You might sign into the app through GitHub, pay the app for a subscription, and separately give it an Anthropic key.

Those connections give different kinds of access. Changing your GitHub password doesn't revoke an Anthropic key. Cancelling the application's subscription doesn't necessarily stop requests billed to your model-provider account.

Start a small inventory:

| Item | What to record |
| --- | --- |
| Vendor connection | Which workspace or hosted product received the key |
| Issuing provider | OpenAI, Anthropic, Google, or another issuer |
| Credential identity | Key name or ID, without copying its secret |
| Scope | Project, workspace, account, and any restrictions |
| Other users | Applications or people sharing that same credential |

Use names and identifiers in your incident note. Keep the secret itself out of the note, screenshots, and support messages.

If you don't know which key was stored, inspect the connections and your provider's key inventory. A useful key name can make the answer immediate. A shared key named `default` makes the investigation harder.

## Revoke at the provider

Once a key is exposed, treat replacement as a new credential, not an edit to its label.

Disable or delete the affected key using the issuer's supported controls. Then replace it in the legitimate applications that still need access. Confirm that the old credential is inactive in the provider's account.

For a confirmed exposure, leaving the old key active while you finish a long migration also leaves it usable by someone else. Work out the affected applications promptly and accept that an interrupted integration may need attention.

Anthropic documents [workspace key management](https://support.claude.com/en/articles/9796807-creating-and-managing-workspaces-in-the-claude-console), including disabling or deleting a key. Google's [Gemini API key guide](https://ai.google.dev/gemini-api/docs/api-key) explains key management and restrictions. OpenAI documents [deleting project API keys](https://developers.openai.com/api/reference/resources/admin/subresources/organization/subresources/projects/subresources/api_keys/methods/delete); use the key controls for the project that issued your credential.

An application may also have its own access token for a gateway. Revoking that token stops that access path; it doesn't revoke an upstream provider key that was copied separately. Trace both layers if both were involved.

## Inspect usage without delaying containment

Look for requests outside your normal pattern. Compare the provider's usage records with when your application was active, and check any available breakdown by project, key, or model.

A request count alone can be misleading. A few large requests can cost more than many small ones. Check token usage and spend as well, and note the reporting delay before deciding the incident has stopped.

Save the relevant time window and request identifiers where available. Contact the provider through its official support channel about unauthorized usage. Describe what you observed and what you revoked. Avoid assuming a refund or account decision before the provider responds.

Also inspect changes to the provider account itself if its audit features expose them. A model key and an administrative credential have different reach. The response should follow the permissions that credential actually had, rather than assume every key can change billing or read every project.

For a team, give one person responsibility for reconciling the inventory. Otherwise two people can each believe the other rotated a shared connection.

## Give each integration its own access

When reconnecting, create a credential dedicated to that tool and environment. If you use the same tool for a test project and production, separate those credentials too.

That improves revocation and attribution. You can remove a disposable experiment's access without breaking a production service, and a usage spike has a narrower place to investigate.

Use the provider's available restrictions. For Google API keys, the key guide describes restricting a key to the Gemini API. Other providers organize access through projects, workspaces, endpoint permissions, or service accounts. Check what the specific credential supports.

A scope label isn't a spending guarantee. It can limit which resources a key reaches while still allowing significant usage within that scope. Test the restrictions with a harmless request before depending on them.

Avoid giving an ordinary coding integration an administrative key just because it works. Administrative automation should have its own narrowly controlled path.

## Check what a budget setting actually does

A dashboard can show a monthly budget and still accept requests beyond it.

OpenAI's [rate-limit and spend guide](https://developers.openai.com/api/docs/guides/terraform/rate-limits-and-spend) explicitly distinguishes spend alerts from enforced limits: an alert notifies recipients, but doesn't stop API requests. Request and token rate limits constrain throughput separately.

For every provider, read the behavior of the setting you enabled. Ask whether it is an alert, a request-rate limit, or an enforced spend cutoff. Check the scope and how quickly it takes effect.

Even a real cutoff can have conditions, such as in-flight work or delayed accounting. An alert should reach someone who can act, and the response should identify exactly which integration can be stopped.

## A broker changes where authority lives

A gateway can keep the upstream key away from a coding client. The client gets a narrower gateway credential, while the gateway calls the provider.

That can centralize revocation and policy enforcement. It also gives the gateway authority to spend through the upstream account. Review what its client credentials can request and whether users can bypass it with a direct key.

A secret manager helps control retrieval, but retrieving a secret into another process gives that process access to it. A design that never returns the raw key can reduce copying while still authorizing model calls. Decide what operations it permits and how you stop them.

Before reconnecting a hosted integration, make the failure exercise concrete. Identify the new credential by name, revoke a test connection, and confirm that only the intended tool loses access. Keep that inventory current when someone adds another provider or workspace.