# Is it safe to give your API key to a third-party AI tool?

URL: https://infro.io/blog/third-party-ai-tools-key-storage
Author: INFRO Editorial (https://infro.io/blog/editorial)
Publisher: INFRO
Published: 2026-10-21
Last modified: 2026-10-21
Last reviewed: 2026-10-21 (next review due 2026-11-20)
Topic: Security and governance
Format: Guide

> It can be, but it is a trade: the tool becomes a holder of a credential that spends money on your provider account, and a key stolen from it works directly against the provider, outside any limit the tool enforces. Ask how the key is stored, encrypted and scoped, who can read it, how it is rotated and deleted, and how a breach is notified; on your side give each tool its own scoped key with a provider spend limit, record it, and rehearse revoking it.

Key takeaways:
- Pasting a provider key into a tool makes that tool's vendor a holder of a credential to your account, with every risk the vendor carries.
- A key stolen from any holder works directly at the provider, outside every limit the tool enforces; provider-side scope, spend limits and revocation are the backstop.
- Ask where the key is stored, under which encryption key, who and what can read it back, how it is scoped, rotated and deleted, and how a breach is notified.
- Give every tool its own dedicated, scoped key with a provider spend limit, write down who holds it, and revoke it once before you rely on it.
- Local tools store keys in files on your machine, which any package or process you run can read.

**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 apps[1]. 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](https://infro.io/blog/byok-platform-breach-blast-radius) models that in detail.

> **Warning: A stolen key does not go through the tool**
> Whatever limits a tool enforces — budgets, model lists, rate limits — apply only to requests sent through that tool. A key copied out of it can be used directly against the provider, from anywhere, until you revoke it at the provider. The only controls that apply to that traffic are the provider's: the key's scope, the provider spend limit, revocation, and the provider's own usage reports.

## 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 providers[2]. 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 Google[3]. BleepingComputer reported users describing unexpected charges and, in some cases, Google suspending projects for activity consistent with hijacked resources[2]. The investigation was ongoing at the time of writing; [our summary of the incident](https://infro.io/blog/opencode-console-breach-what-happened) 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 encrypted[4]. 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](https://infro.io/blog/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?](https://infro.io/blog/what-is-byok-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.

1. **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.
2. **Scope it at the provider.** Put it in its own OpenAI project, which OpenAI describes as a way to isolate work[5]; or in its own Anthropic workspace, where keys are tied to the workspace they were created in and cannot be moved[6]; or in a dedicated Google Cloud project with API restrictions, which Google says reduce the impact of a compromised key[7].
3. **Set a spend limit at the provider.** OpenAI's project hard limit fails requests with a `429` once reached, though recorded spend can slightly exceed it while the limit updates[8]. An Anthropic workspace can carry its own spend limit below the organization's[6]. This is the one control that applies to a stolen key used directly.
4. **Set an expiry where the provider supports it.** OpenAI strongly recommends setting an expiration date on project keys[5].
5. **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](https://infro.io/blog/ai-credential-inventory) gives a format.
6. **Rehearse revocation.** Revoke and replace the key once before you rely on the tool. OpenAI says a revoked key stops working within a few seconds[1]; time how long the tool takes to pick up the replacement.
7. **Watch usage at the provider, not only in the tool.** Google notes that monitoring API usage helps alert you to unauthorized use[7]. The tool's dashboard cannot show traffic that never went through it; [signs your AI API key is being abused](https://infro.io/blog/signs-ai-api-key-abused) lists what to look for.

> **Example: One tool, one key, three limits**
> A five-person team wants to try a hosted coding agent. It creates an OpenAI project called `agent-trial`, issues a key there with a 90-day expiry, and sets a monthly hard limit of $300 on the project. It records the key in its inventory with the tool's name and an owner, and on day one revokes it and issues a replacement to time the swap. If the tool is breached, the most the stolen key can spend in a month is the project limit, and revoking it touches nothing else.

## 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 computer[9]. [AI supply chain attacks in 2026](https://infro.io/blog/ai-supply-chain-attacks-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](https://infro.io/blog/ai-coding-agents-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](https://infro.io/docs/providers), [Authentication](https://infro.io/docs/authentication) and the [audit log](https://infro.io/docs/org/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](https://infro.io/docs/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_allowed` before any provider call — belongs to one [environment](https://infro.io/blog/gateway-key-controls-environments), 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.

## Questions

### Is it safe to paste my OpenAI or Anthropic key into an AI tool?

It is a trade, not a yes or no. The tool's vendor becomes a holder of a credential that spends on your account. It is reasonable when the vendor can answer how the key is stored, encrypted, scoped and deleted, and when you give it a dedicated key with a provider-side spend limit that you can revoke without breaking anything else.

### What are the main BYOK risks?

The platform now holds a live credential to your provider account, so a breach of the platform, a malicious insider, a compromised dependency or a leaked backup can expose it. A stolen key can be used directly against the provider, outside every limit the platform enforces, until you revoke it at the provider.

### Should I use my production key in a third-party tool?

No. Create a separate key for each tool, in its own OpenAI project, Anthropic workspace or Google Cloud project, with a spend limit set at the provider. Then revoking the tool's access, or losing the key, does not touch your production traffic.

### What should I do if a tool I gave a key to reports a breach?

Create a replacement key, revoke the old one at the provider, check that the old one now fails, and review provider usage and billing from the earliest exposure time the vendor gives. Replacing the key inside the tool alone does not revoke it.

## Sources

1. API reference: Authentication — OpenAI. https://developers.openai.com/api/reference/overview (accessed 2026-10-21)
2. OpenCode hack exposes API keys amid AI distillation attacks — BleepingComputer. https://www.bleepingcomputer.com/news/security/opencode-hack-exposes-api-keys-amid-ai-distillation-attacks/ (accessed 2026-10-21)
3. OpenCode Breach Could Affect OpenAI, Anthropic and Google — Infosecurity Magazine. https://www.infosecurity-magazine.com/news/opencode-breach-openai-anthropic/ (accessed 2026-10-21)
4. Secrets Management Cheat Sheet — OWASP. https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html (accessed 2026-10-21)
5. Production best practices — OpenAI. https://developers.openai.com/api/docs/guides/production-best-practices (accessed 2026-10-21)
6. Creating and managing Workspaces in the Claude Console — Anthropic. https://support.claude.com/en/articles/9796807-creating-and-managing-workspaces-in-the-claude-console (accessed 2026-10-21)
7. Best practices for managing API keys — Google Cloud. https://docs.cloud.google.com/docs/authentication/api-keys-best-practices (accessed 2026-10-21)
8. Spend limits — OpenAI. https://developers.openai.com/api/docs/guides/spend-limits (accessed 2026-10-21)
9. MAL-2026-12510: Malicious code in anthropic-setup (npm) — OSV. https://osv.dev/vulnerability/MAL-2026-12510 (accessed 2026-10-21)