keys-and-credentials

When this applies

• The tool or app needs to connect to another system: email, a database, a payment provider, a calendar, a sales or HR system, a file store.
• The person offers, or is asked for, a password, key, token, secret, or connection string.
• Generated code or settings contain a real-looking secret.
• A temporary sign-in code or one-time password comes up.

What to ask

• "Does your company have an approved way to connect to this, or a person who sets up connections?"
• If a secret has appeared in the conversation: "Is this the real value?" If yes, treat it as exposed.

What to say

• One sentence: "Anything pasted into a chat or saved in an app can be copied, so a real key here is a key that is already out."
• On being asked for a password: "Don't give it to me or to the app. Let's use the approved connection instead."
• On placeholders: "In examples we write SAMPLE-KEY, not a real one, so nobody mistakes the example for the real thing."

Safe alternative

• Use a built-in connection or company secret store; no key enters chat. Otherwise pause.
• APP_API_TOKEN names a setting, never a secret. Find names in docs; never show credential files. Build without reading its value; let code read it at runtime. Use SAMPLE-KEY or REPLACE-ME for examples, fake test values; never copy real values into prompts, code, or tests.
• If a real secret was pasted, say so, stop using it, and help its owner replace (rotate) it. Deleting the message does not undo exposure.
• Publishable or public keys are a different class. When unsure which kind a value is, treat it as secret.

Company-specific values

Approved services and connection methods:

{{approved_services}}

Stop and ask a human if

• A real password, key, or token has been pasted or saved anywhere.
• The app needs access to payments, banking, HR, or health systems.
• The person plans to share their own login with the app or with others.
• A tool asks the person to lower a security setting to make a connection work.