JuniorAI for developers

What shouldn't you give an AI tool when you code, and what do you do if you accidentally leak an API key?

The interviewer wants to know that you use AI with security in mind, and that you know the order of steps once an incident has happened.

There are three groups of things not to give an AI tool. The first is keys and passwords: API keys, tokens and database connection strings. The second is other people's data, such as the names, phone numbers and emails of real users. The third is code and documents that don't belong to you, such as your company's or a client's code, because each tool and each plan has its own policy on storing and using data, and you need to read the terms of the exact plan you use, and also ask whether your company has a list of approved tools.

In practice: replace real data with fake data of the same shape, mask keys before pasting (a filter that runs first can do this), keep keys in environment variables instead of writing them into code, put .env in .gitignore, and configure the AI tool so it can't read secret files. It's also worth adding an automatic layer, such as secret scanning before a commit or protection when code is pushed, because a manual routine tends to get forgotten exactly when you're in a hurry.

If you do leak a key, the first step is to revoke it, not to erase the traces: deleting the line from Git isn't enough because the old copy stays in the history, in clones and in forks. After revoking, create a new key and update the places that use it, check the usage history for unusual activity, and only at the very end clean up the Git history.

A bonus point: say that a secret filter only catches the shapes it already knows, so it can't replace good habits, and mention testing the filter with your project's real variable names.