AI tools make it very easy to paste information into a box and ask for help.
That convenience can also make people forget what they are sharing.
A code snippet may contain an API key. A spreadsheet may include customer information. A support ticket may contain phone numbers or account details. A configuration file may expose a database password.
Once sensitive information leaves the place where it was meant to stay, fixing the problem can be much harder than preventing it.
The simplest rule is:
Do not send sensitive information to an AI system unless the task genuinely requires it and the system is approved to handle that information.
That sounds obvious. In practice, it is easy to miss.
What counts as sensitive information?
It depends on the context, but common examples include:
Personal information
Names, addresses, phone numbers, identification numbers, account details and other data that can identify or describe a person.
Business-confidential information
Internal documents, contracts, pricing, financial information, private meeting notes, source code, unreleased plans and proprietary processes.
Security credentials
Passwords, API keys, access tokens, private keys, database credentials, session tokens and other values that grant access.
Regulated or high-impact data
Health records, financial records and other information that may be subject to legal, regulatory or contractual handling requirements.
OWASP’s guidance on generative AI data security treats sensitive information exposure as a real application risk, and its Secrets Management Cheat Sheet gives practical guidance for handling credentials such as API keys, passwords and private keys.
An API key is not just a random string
An API key may look like a long piece of text, but it can represent authority.
Depending on the service, a leaked key may let someone:
- use a paid API
- access stored data
- perform actions under your account
- consume your usage quota
- reach internal services
- impersonate an application
That is why keys and tokens should be treated like credentials, not like configuration labels.
If an AI assistant asks you to paste a real production key so it can “debug the code”, stop and ask whether the real value is actually necessary.
Usually it is not.
For everyday AI users: use a three-question check
Before pasting something into an AI tool, ask:
1. Is this information already public?
If yes, the confidentiality risk may be low.
If no, continue.
2. Does the AI actually need the real value?
Often you can replace sensitive values with placeholders.
Instead of:
Customer: Nimal Perera
Phone: 07XXXXXXXX
Account: 123456789you can use:
Customer: [NAME]
Phone: [PHONE]
Account: [ACCOUNT_NUMBER]The AI can still help with formatting, logic or writing without receiving the real personal information.
3. Is this AI service approved for this data?
Different products, plans and deployments can have different data-handling terms, retention options and administrative controls.
Do not assume that every AI tool handles prompts in the same way.
For company data, follow the organization’s approved tools and policies rather than relying on a general consumer account.
For developers: never put production secrets in prompts
A production API key should not be inserted into an LLM prompt so the model can “use” it.
Instead, the application should keep the secret in a controlled backend or secrets-management system.
The model can request an action through a defined function, while the application performs the authenticated operation without showing the raw credential to the model.
This creates a useful separation:
The model knows what action is needed. The application knows the secret needed to perform it.
The model does not need both.
Use a real secrets-management approach
OWASP recommends centralising and standardising secrets management rather than scattering credentials through source code and configuration files.
A mature secret should have a lifecycle.
It should be:
- stored securely
- visible only to identities that need it
- revocable
- rotated when appropriate
- auditable
- excluded from plaintext logs
- removed when no longer needed
Environment variables can be better than hardcoding credentials directly into source code, but they are not automatically a complete secrets-management system. The right approach depends on the application and deployment environment.
Apply least privilege to keys and tokens
A key that can only read one resource is safer than a key that can administer an entire account.
If a service supports scoped tokens, use the narrowest scope that works.
Also separate environments.
A development tool should not automatically receive a production credential just because using one key everywhere is convenient.
Separate credentials make it easier to limit damage and rotate one environment without affecting everything else.
Use short-lived credentials where practical
Long-lived secrets are convenient for attackers too.
Where the platform supports temporary or short-lived credentials, they can reduce the time a stolen token remains useful.
This does not remove the need for access control or monitoring, but it improves the security model.
Do not leak secrets through logs
A surprisingly common mistake is protecting a credential in storage and then printing it into a log.
AI applications can create additional logging points:
- raw prompts
- retrieved context
- model responses
- tool parameters
- error traces
- debugging output
Before logging AI interactions, decide what information is genuinely needed for debugging and security monitoring.
Mask or remove sensitive values before they are written to logs.
Scan and mask data before it reaches the model
For applications that handle user-submitted text or code, a pre-processing layer can look for sensitive patterns and remove or replace them before the data is sent to an LLM.
Examples include:
- API keys
- access tokens
- email addresses
- phone numbers
- identification numbers
- database credentials
- private keys
Detection will never be perfect, so it should be one layer rather than the only control.
Still, reducing the amount of sensitive data that reaches the model is a very useful design principle.
This is closely related to the broader ideas in my guide to AI security.
Be careful with retrieved documents
Retrieval-augmented generation systems may automatically pull internal documents into the model context.
That creates an access-control question.
The retrieval system should not return a document simply because it is relevant to the user’s question. It should also check whether the user is authorised to access that document.
Relevance is not permission.
This distinction is important in enterprise AI.
Protect the output too
Sensitive information can leak in the response even when the original prompt looked harmless.
Applications that work with confidential data may need output checks, especially when results are being sent to external channels, other users or automated systems.
The correct control depends on the use case, but the principle is straightforward: data protection applies on the way out as well as on the way in.
What to do if a secret was exposed
If you accidentally pasted an API key, password or token into a place where it should not have been, do not rely on deleting the message as the only response.
For a real credential:
- Revoke or rotate it as soon as possible.
- Create a replacement credential.
- Update the application or service that uses it.
- Review available logs for suspicious use.
- Check whether the same secret was copied anywhere else.
- If the exposure affects an organization, follow its incident-reporting process.
For a password, change it anywhere it was used and avoid reusing the same password across services.
For human accounts, multi-factor authentication adds an important layer of protection. Phishing-resistant MFA is stronger than methods that can be easily intercepted or approved by mistake.
Do not confuse masking with encryption
Masking, encryption and tokenisation solve different problems.
Masking replaces the visible value, often so a system can process the surrounding text without seeing the original sensitive data.
Encryption protects data using cryptography so that authorised parties with the correct key can recover it.
Tokenisation replaces sensitive data with another value and usually keeps a protected mapping elsewhere.
For AI workflows, masking can be useful when the model needs the structure of the information but not the real identity or secret.
A safer default
When using AI, start with less data.
Add information only when the task needs it.
For developers, keep credentials outside the model and expose narrow, controlled functions instead. For users, redact personal or confidential values whenever the real value does not matter.
AI security is often discussed using complex attack names, but good data handling still begins with a very old security principle:
Do not give a system information it does not need.