Is it safe to give your API key to a third-party AI tool? It can be, but it is a trade, not a setting. When you paste an OpenAI, Anthropic or Google key into a coding agent console, a chat interface, an IDE plugin or a gateway, that tool's vendor becomes a holder of a credential to your provider account. Whatever happens to the vendor's systems can now happen to your bill. Ask how the key is stored, encrypted, scoped, rotated and deleted; on your side, give each tool its own scoped key with a provider spend limit, record who holds it, and rehearse revoking it.
This guide sets out what you actually hand over, the questions that separate a careful holder from a careless one, and the controls on your side that still work when the holder fails. The answers apply to every tool, including the one written by the team that publishes this post.
What you hand over when you paste a key
A provider API key is a bearer credential: whoever presents it is treated as you. OpenAI's API reference calls the key a secret, says not to share it, and says not to expose it in client-side code such as browsers or apps1. Every third-party tool that asks for one is asking to become an exception to that rule, so the question is how good an exception it is.
Where the key ends up depends on the kind of tool:
| Kind of tool | Where the key usually lives | Who can use it | What a leak exposes |
|---|---|---|---|
| IDE plugin or local agent | A config file or keychain entry on your machine | Any process running as you | One key, through your machine |
| Chat interface | Browser storage, or the vendor's server | You, and the vendor if stored server-side | One key, through the browser or the vendor |
| Hosted agent console or team workspace | The vendor's database, used server-side for the whole team | Everyone in the workspace, and the vendor's systems | Every key every admin added to the workspace |
| AI gateway or control plane | The vendor's database, used server-side on every request | Your applications, through the vendor's own keys | Every provider key the organization connected |
The bottom two rows are the important ones. A hosted tool concentrates many customers' keys in one place, which is useful for the customers and attractive to an attacker. What happens when a BYOK platform is breached models that in detail.
A recent example
On 17 October 2026, OpenCode disclosed a breach of its OpenCode Console, the service that lets teams share access to models through centrally managed provider credentials. OpenCode said the incident was related to a large-scale distillation attack that affected 1.4% of Console users, and only users who had linked external providers2. According to Infosecurity Magazine, the notification email described unauthorized access to a legacy system OpenCode was decommissioning, and said third-party provider keys saved in a workspace may have been exposed; OpenCode notified Anthropic, OpenAI and Google3. BleepingComputer reported users describing unexpected charges and, in some cases, Google suspending projects for activity consistent with hijacked resources2. The investigation was ongoing at the time of writing; our summary of the incident tracks what has been published.
The point here is not this vendor. It is that the incident followed exactly the path in the table: keys stored server-side for a team, exposed together, usable directly at the providers.
Questions to ask before you hand a key over
Ask these in writing, and keep the answers with your vendor record. A vendor that holds keys well can answer each in a sentence.
Storage and encryption
- Where is the key stored, and is it encrypted at rest? Look for authenticated encryption, not a database setting.
- Where does the encryption key live? OWASP's guidance is not to store keys next to the secrets they encrypt unless those keys are themselves encrypted4. If the encryption key is in the same database, a database dump is a key dump.
- Is each stored key bound to your account? A sealed value bound to its tenant and row cannot be copied into another tenant's row and used there. BYOK credential architecture explains the mechanism.
- Are old systems, backups and exports covered by the same answers? The systems a vendor is retiring are the ones least watched.
Who and what can read it
- Can anyone see the full key after it is saved — you, your admins, the vendor's support staff, an internal admin tool? The right answer is no one; a console should show the last four characters.
- Does any API, export, log line or infrastructure-as-code state file ever contain it?
- Is the key ever sent to a browser or desktop client, or used only server-side?
- Is every view, change and use of a key in an audit log you can read?
Scope and lifecycle
- Can you limit which of your teams, projects or environments use the key?
- Can you replace it without an outage, and does the tool remind you that replacing it there does not revoke it at the provider?
- When you delete the key, or close the account, is it deleted from every store, including backups, and when?
- If your key fails, does the tool fall back to its own provider accounts? That changes whose terms your traffic runs under; What is BYOK in AI? covers the question.
When something goes wrong
- Is there a contractual breach-notification commitment, with a time limit? A statement on a web page is weaker than a clause in a data processing agreement.
- Will the notice include the earliest possible exposure time? You need it to bound the usage review at your provider.
- Does the vendor have a way to tell you which of your keys were exposed, rather than "keys may have been exposed"?
What to do on your side
The vendor's answers decide how likely a leak is. Your own setup decides how much a leak costs. These steps work whichever tool you choose.
- Create a dedicated key for each tool. Never paste the key your own services use. Then revoking the tool's access cannot break production, and the provider's usage reports separate the tool's traffic from yours.
- Scope it at the provider. Put it in its own OpenAI project, which OpenAI describes as a way to isolate work5; or in its own Anthropic workspace, where keys are tied to the workspace they were created in and cannot be moved6; or in a dedicated Google Cloud project with API restrictions, which Google says reduce the impact of a compromised key7.
- Set a spend limit at the provider. OpenAI's project hard limit fails requests with a
429once reached, though recorded spend can slightly exceed it while the limit updates8. An Anthropic workspace can carry its own spend limit below the organization's6. This is the one control that applies to a stolen key used directly. - Set an expiry where the provider supports it. OpenAI strongly recommends setting an expiration date on project keys5.
- Record the arrangement. Which tool holds which key, who created it, which project or workspace it lives in, and when it should be rotated. An AI credential inventory gives a format.
- Rehearse revocation. Revoke and replace the key once before you rely on the tool. OpenAI says a revoked key stops working within a few seconds1; time how long the tool takes to pick up the replacement.
- Watch usage at the provider, not only in the tool. Google notes that monitoring API usage helps alert you to unauthorized use7. The tool's dashboard cannot show traffic that never went through it; signs your AI API key is being abused lists what to look for.
Local tools are holders too
An IDE plugin or command-line agent that keeps your key on your own machine avoids the vendor's database, but moves the risk to your machine. A key in a config file is readable by any package, script or process running as your user. In August 2026, OSV published an advisory for an npm package presented as an Anthropic setup helper that rewrote the Claude CLI's settings file to send prompts and the API key to a third-party domain; the advisory says any computer that installed it should be considered fully compromised and secrets rotated from a different computer9. AI supply chain attacks in 2026 collects similar cases.
For local tools, the same rules hold: a dedicated, scoped, limited key per tool; nothing in a repository; and a periodic look at the tool's settings files for base URLs and helpers you did not set. AI coding agents and secrets exposure goes further.
Giving a tool something other than a provider key
Some tools can call models through a gateway instead of holding your provider key: you give the tool a key issued by the gateway, and only the gateway holds the provider credential. That narrows what each tool holds — a gateway key can be limited, rotated and revoked without touching the provider key — but it does not remove the holder. It moves all your provider keys to one place, the gateway, which then has to answer every question above. Choose it because that one place is better defended and better governed than many tools, not because the risk went away.
How INFRO handles the keys you give it
INFRO is a holder of this kind: customers connect their own provider keys so INFRO can route requests to their providers. These are its controls today, as documented in Connect a provider, Authentication and the audit log:
- Storage. Each provider credential is encrypted with AES-256-GCM under a key held as a Worker secret outside the database, with the organization and connection bound in as additional authenticated data. It is never shown again after saving; the console shows the last four characters.
- What tools get instead. Applications and coding agents such as Claude Code and Codex (coding agents) use INFRO gateway keys, stored only as a SHA-256 digest. A gateway key can be limited to chosen providers or IP ranges — a request from elsewhere returns
403 ip_not_allowedbefore any provider call — belongs to one environment, can expire, and can be rotated with an overlap of none, 1 hour, 24 hours or 7 days. - Limits. Hard budgets per organization, project, member and key are checked before the provider is called, and refuse with a
402. - Accountability. Key and connection changes are in the audit log; two-factor authentication is available for the console, and SSO on the Business plan. INFRO's data processing agreement commits to notifying a breach without undue delay and within 48 hours of becoming aware.
The limit of all of this is the warning above: INFRO's controls govern traffic that goes through INFRO. A provider key stolen from INFRO, or from anywhere else, can be used directly at the provider. Connect INFRO with a dedicated key, scoped and spend-limited at the provider, exactly as you would for any other tool.
Summary
Giving a third-party tool your API key makes it a holder of a credential to your account. Ask the vendor where the key is stored, under which encryption key, who can read it, how it is scoped, rotated and deleted, and how a breach is notified. Then assume any holder can fail: give each tool its own scoped key with a provider spend limit, record it, watch usage at the provider, and know you can revoke it in seconds.