API keys in AI prompts: how they slip in and what to do

Nobody decides to paste a secret key into a chatbot. It arrives as a passenger. A developer copies forty lines of a configuration file to ask why the connection fails, and line twelve holds the database password. An analyst pastes an error log, and the log includes a request header with a token. A support engineer shares a customer's webhook address, which works as a password on its own.

This post covers where keys hide, why a pasted key should be treated as exposed, and what to do in the first hour after it happens.

Where secrets hide in ordinary text

• Environment and configuration files: the .env file, settings files, deployment scripts.
• Connection strings: a database address with the user name and password written into it.
• Error logs and stack traces that print the request, including its authorisation header.
• Code snippets with a key written directly into the source for a quick test.
• Webhook addresses for chat tools, which let anyone who has them post messages.
• Copied terminal output after a command that echoed a variable.
• Private key files, which begin with a recognisable header line.

Most of these look like noise to a person skimming before they paste. That is exactly why they get through.

Why a pasted key counts as exposed

Once the text leaves your machine, you no longer control who can see it. It may be stored in the chat history of the account, kept by the provider for some period under its terms, visible to anyone else with access to that account, and on some plans used to improve the service. You cannot check any of that from the outside, and deleting the chat does not prove the copy is gone.

So the rule is simple: if a live secret was pasted anywhere outside your own systems, rotate it. Do not spend an afternoon deciding whether the risk is real. Rotation is usually a few minutes of work; a misused key can be far more expensive.

The first hour

1. Revoke or rotate the key at the service that issued it, and put the new one where the old one was used.
2. Check the service's own logs for use of the old key since the time it was pasted.
3. Delete the conversation from the chat history, while accepting that this does not guarantee removal.
4. Write down what happened: which key, which tool, when, who, and what you did. Keep it short and factual.
5. Tell whoever owns security in your company, even if everything is fine. Patterns only show up when incidents are recorded.

The same steps, with small changes, apply to any accidental paste: personal data, a client document, a pricing sheet. Act first on whatever can be changed, such as a key or a password, then record what happened while it is fresh. For the other kinds of information that should stay out of chat tools in the first place, see the list of what not to paste.

Stopping it next time

Training helps, but habits help more. Three that work for development and operations teams:

• Keep secrets out of code and configuration files that people copy from. A secrets manager or environment variables set by the deployment system mean the file people paste does not contain the value.
• Replace values before asking for help. A placeholder like YOUR_DB_PASSWORD keeps the question intact.
• Check pasted text for key patterns before it goes anywhere. Many keys have recognisable shapes: fixed prefixes, set lengths, a header line.

What a pattern check can and cannot see

Pattern rules are good at secrets with a fixed shape: a private key header, an access key ID with a known prefix, a connection string with a password in it, a password written as password equals something. They are weaker at a random string with no prefix, a key split across two lines, or a key encoded in base64. A check reduces mistakes; it does not replace rotating a key that got out.

In Openn Shield

The Openn Shield scanner includes rules for private keys, AWS access key IDs and secret keys, GitHub and Slack tokens, Slack webhook addresses, Stripe secret keys, Google API keys, OpenAI and Anthropic API keys, JSON Web Tokens, database addresses with passwords, and passwords written in text. It runs in your browser, so the text and the key you are checking never reach our server. See the full rule list and its limits.