Course contents

Lesson 4 of 9

Keys have three homes, and deleting one revokes nothing

A key lives where it is stored, where it is copied, and in the service that issued it. Only the issuer can revoke it. Anything that runs on your computer as you can read a key stored in a plain file.

5 minutes · Checked on October 25, 2026

The prompt

The longer you use Claude Code, the more API keys and tokens you are going to accumulate and use. Each new service you adopt is a potential new key to hand over to Claude for its use. Where are these keys stored exactly? Lets find out together.

Three homes

A key lives in three places:

  1. Where it is stored: a file, a settings page, a password manager, a connector hub
  2. Where it was copied: a chat with your agent, a note, a screenshot, a backup, the history of a git repository
  3. The service that issued it: Google, OpenAI, Meta, your bank

Here are some uncomfortable truths about this:

  • Only the third home can revoke it. Deleting the file that held an old key revokes nothing: the key still works for anyone who has a copy. Revoking happens on the issuer's page, and that is the only step that counts
  • Deleting the other two is just house cleaning - nothing more. As long as the key is valid in the service - it can be used - and not necessarily by you
  • That second home is the one that hurts the most. It shouldn't happen. At all. When it does, you need to revoke it in the service and reissue another one. Not fun at all

A plain file is open to everything you run

A key in a plain text file on your computer can be read by anything that runs as you: every agent, every script you install, every package's install step. That is how most key theft works in practice. A package runs a step when it is installed, reads the usual settings folders and sends home what it finds. A password manager or the system's secure store keeps the key out of the files that kind of script reads.

Keys on a public site

A website you deploy has two sides:

  1. Code on the server can hold a key privately
  2. Code sent to the browser is downloaded by every visitor, so anything in it is public

Frameworks mark the settings allowed to cross that line with a prefix in the name, such as NEXT_PUBLIC_ in Next.js. When an agent needs a key in the browser, the easy fix is to give it that prefix. The site works, and the key is now in a file anyone can read. If that ever happens, revoke the key at the issuer. Renaming the setting afterwards changes nothing.

Hubs hold keys for you

A connector hub is convenient because it holds the keys for you. That also means its breach is your breach. Know which services hold keys on your behalf, and know where you would revoke everything if one of them made the news.

The prompt

This prompt lists your keys with the one column most lists leave out, the place you would revoke each one, without ever printing a key.

Copy into your Claude session
List every API key, token and password my agents can use.

For each:
- where it is stored
- what it can do (read, write, send, pay)
- the exact page where I would revoke it today

Never print a value, not even partially.

Then tell me which of these a script I install from the internet could read, and which services are holding my keys for me.

Reading the answer

  • A real answer

    A revoke location for every row, and an honest "a script running as you could read these" for the ones in plain files.

  • A non-answer

    A list of keys with no revoke column. Without it, the list cannot help you on the day one of them leaks.