Protect data and secrets

AI workflows copy data around. Into the prompt, the conversation history, tool results, logs, traces, generated files. When you think about privacy, think about the whole path. Not just the final answer.

Before you share data with an AI service, ask:

1. What exact fields am I sending?
2. Does this task need the real values?
3. Where will the input and output be stored or logged?
4. Which people, services, tools, or models can access it?
5. When does it get deleted?

Then read the current provider policy. Consumer chat, API, enterprise, and local deployments can all handle retention and training differently, even from the same company.

Minimize before you share

Use a synthetic record instead of a production record when you can. Keep only the fields needed to reproduce the problem. Replace names, emails, tokens, and IDs consistently, so relationships between records still make sense.

Don’t paste a whole customer export to explain one failing row. Don’t attach the entire .env file when the name of one variable is enough.

Different data needs different treatment. A public schema is fine to share. A customer email gets sanitized first. A credential never enters the prompt. Ever.

Environment variables are not automatically secret

API keys and passwords belong in protected server-side configuration or a secrets manager. But an environment variable that reaches browser code becomes public the moment the app builds or runs. Anyone can open the network tab.

The browser must never receive a private model-provider key. Put the model call on a server and expose only the narrow operation the client needs.

Secrets also leak through screenshots, shell history, test fixtures, logs, error messages, and generated documentation. Agents write all of those. Check them.

If a secret leaks

Deleting the visible line is not enough. Assume anything that was committed, logged, or shared has already been copied.

1. Stop using the credential.
2. Revoke or rotate it at the provider.
3. Update the deployed configuration.
4. Check usage and logs for abuse.
5. Remove the visible copies and clean history where it makes sense.
6. Fix the process that let it happen.

Rotation is the step that matters. It stops future use. Cleaning the repository alone does not.

A quick self-test. Sort these into three buckets, safe to share, sanitize first, never share: a public database schema, an anonymized fixture, a production stack trace with an authorization header in it, a customer export, a private API key. If you hesitated on the stack trace, that’s the one that bites people. Headers hide in the middle of the text.