Where your AI keys and logins should live

Your AI keys and logins should live in a proper secret store: the operating system's keychain on a personal machine, or a secrets manager for servers and teams. They should not live in source code, plain text files, chat messages, or a third party's database unless you have decided to trust that party with your account.

A key is a bearer credential. Whoever holds it can act as you. They can spend your money, read whatever your account can read, and in some setups see past conversations. That makes where it sits a custody question, not a convenience one.

The kinds of credential involved

Credential	What it is	Typical lifetime
API key	A long random string that identifies an account to an API	Until you revoke it
OAuth access token	A short-lived token issued after you sign in and approve access	Minutes to hours
OAuth refresh token	A longer-lived token used to obtain new access tokens	Days to months, or until revoked
Session cookie	What keeps you signed in to a website	Varies

API keys are the simplest and the riskiest, because they usually do not expire on their own. OAuth-style sign-in is generally safer: you approve access in a browser, the application never sees your password, the access token expires quickly, and you can revoke the grant from your account settings. Refresh tokens still need careful storage, since they can mint new access tokens.

Where keys should not live

In source code. Code is copied, shared and pushed to repositories. Keys committed to a public repository are found by automated scanners very quickly. Removing the line in a later commit does not help, because the key remains in the history. Rotate it.
In plain text configuration files. A file of environment variables in a project folder is readable by any program running as you, is easily swept into a backup or a zip file, and is often committed by accident.
In chat, email or tickets. These systems keep history, are searchable, and are read by more people than you expect.
In shell history and logs. Pasting a key into a command line can record it in your history file. Programs that print their configuration on start-up can write it to a log.
In notes and documents. Including the notes an AI agent is allowed to read.
In screenshots and screen shares.

Where they should live

On a personal computer: the operating system's secret store. macOS has Keychain. Windows has Credential Manager. Linux desktops commonly provide the Secret Service interface through GNOME Keyring or KWallet. These stores encrypt secrets at rest, tie them to your user login, and let applications request a specific item without the secret sitting in a readable file.

On servers and in automated pipelines: a secrets manager. These hold secrets centrally, hand them to a workload at run time, record who accessed what, and make rotation manageable. Most cloud platforms offer one, and there are self-hosted options.

For a team: separate keys per person and per purpose. Shared keys make it impossible to tell who did what, and impossible to remove one person's access without disrupting everyone.

A keychain is not magic. Software running as your user, once the store is open, may be able to request secrets, and the details differ by operating system. It is still a large improvement on a plain text file, and it is the right default.

The third option: someone else holds your key

Many AI products ask you to paste your API key into their website so that their servers can call the model on your behalf. That can be a reasonable design. It also means a copy of your credential now sits in their database, and your exposure includes their security, their staff access and their backups.

The alternative is an application that runs on your device, stores the credential in your keychain, and calls the AI provider directly from your machine. The vendor of the application never receives the key. The guide on bringing your own AI subscription covers this model, and data custody in AI explains the wider principle.

Neither design is always right. What matters is that you know which one you are using.

Keys and AI agents

Agents add a new way to leak a secret. An agent sends what it reads to a model provider as part of its prompt. If it opens a file containing a key, or runs a command that prints one, the key travels with the rest of the context. See what gets sent to an AI provider.

Practical steps:

Keep secrets out of the folders an agent works in.
Have the launching program inject credentials into the specific process that needs them, so they never appear in files or command output the agent reads.
Do not ask an agent to "check whether the key works" by printing it.
Give agents their own narrowly scoped credentials where the service allows it, so a leak is limited.
Watch tool servers and plugins. Each one you connect may need its own credential, and each is another place for one to sit. The guide on skills, plugins and tool servers explains what these are.

Good habits

Least privilege. If the provider supports scoped or restricted keys, use them. A key for one project should not reach another.
Spending limits. Set usage caps and alerts where the provider offers them. A stolen AI key is commonly used to run up a bill.
Rotation. Replace long-lived keys on a schedule and whenever someone leaves.
Separate environments. Development, testing and production each get their own key.
Secret scanning. Turn on scanning in your code hosting service and add a local check before commits.
Multi-factor sign-in on the AI provider account itself. The key store protects the key. This protects the place keys are issued.

If a key leaks

Revoke it at the provider at once. Do not wait to investigate first.
Issue a new key and update the systems that used the old one.
Review usage and billing for activity you do not recognise.
Find out how it leaked, and fix that path.
If the key could reach personal or client data, tell whoever is responsible for incidents in your organisation.

Where Prism fits

In Prism Desktop, each agent signs in with the owner's own AI account or subscription. Prism never holds that login, and keys stay in the computer's keychain. Bare mode, for Claude Code and Codex, keeps your sign-in and leaves your personal setup behind. There is more on the security page.