5 Ways Beginners Leak Credentials With AI Tools

Last updated: August 2026

Every professional I teach eventually has to hold a secret. A token, an API key, something that proves to another system that they are allowed in. For most of them it is the first time any tool has ever asked them to do that, because nothing in a career of spreadsheets and browser logins prepares you for it. Going through my session notes from July, two of the four students I taught created a real credential exposure inside their first three sessions. In both cases the thing that caught it was the software, not the person. Five ways it happens, in the order I see them.

In this post: The synced folder · The token in the chat · The powerless token · The convenient forever key · The committed secret

1. The synced folder

This is the one nobody sees coming, because it has nothing to do with security habits and everything to do with where you happened to make a folder.

A student of mine set up her whole project inside a folder her IT department had created for her. It looked like a normal folder. It behaved like a normal folder. It was also cloud-synced and shared with her employer, which meant that the moment she saved a live access token for a production system into it, that token replicated somewhere she did not control and other people could reach.

What saved her was not either of us. The AI's own safety classifier refused to write the secret to that path, which limited the exposure considerably. I flagged it, said we would fix it next session, and then it slipped for three consecutive sessions while we chased more interesting problems. That is my failure, not hers, and it is the most common shape this takes: everyone agrees it matters and nobody does the thirty seconds of checking.

Before you save anything sensitive, confirm where you actually are:

# macOS and Linux
pwd

# Windows PowerShell
Get-Location

If the path contains OneDrive, Dropbox, Google Drive, iCloud, or a network share, you are in a synced location. Move the project before you go further.

Two things make this worse than it first sounds. The first is that in most corporate setups the synced folder was created by IT and is shared by design, so the people who can read it are not people you chose. The second is that if you work under an NDA, how you handle company data is contractual rather than merely advisable, which turns a sloppy folder choice into a compliance question.

There is also a subtler version of the same mistake. One student opened her project from inside the tool's own hidden configuration directory rather than the actual project folder. Nothing warned her. The tool ran, wrote files, and everything looked normal, but it was writing into a location she would never think to check and could not see from her own work. Confirm the path, not the fact that something opened.

The fix: Keep project folders in a plain local directory that syncs nowhere. Check the full path before the first credential, not after.

2. The token in the chat

Here is the pattern that surprised me most, because it is the one I caused.

In one session I taught a student, correctly and at some length, that credentials belong in an environment file and never in a conversation, because the conversation is saved locally and a secret sitting in it is a standing risk. She understood it and she applied it.

One session later I had her paste a token straight into the chat window, and justified it out loud with "it expires anyway, so it is fine for now."

The smaller problem is that the token now sits in her local conversation history until it expires. The bigger problem is that I taught a rule and then broke it in front of her, which quietly teaches that the rule is optional whenever it is inconvenient. For someone whose entire risk exposure is credential handling inside a locked-down company, that is precisely the wrong lesson to leave lying around.

It is worth being clear about where a secret actually ends up when you paste it somewhere:

Where you put it	Who can read it later
Environment file, ignored by version control	Only someone with access to your machine
Chat conversation	Anyone with your session history, until it expires
Committed to a repository	Anyone with repository access, permanently, even after deletion

That last row is the one people underestimate. Deleting a secret from a file does not remove it from the history. OWASP's secrets management guidance is blunt about it: once a credential has been committed or transmitted somewhere it should not have been, treat it as compromised and rotate it, rather than trying to clean up after it.

The fix: No exceptions for short-lived credentials. If it authenticates to something, it goes in an environment file, every time, even when that is slower.

3. The powerless token

Not every credential mistake is a leak. This one is the opposite problem, and it derails a session just as effectively.

A different student created a personal access token to connect her work to version control, followed the flow, and generated it successfully. Then the commit failed. Then it failed again. We spent a genuinely irritating stretch of the session working out why, and the answer was that when she created the token she had not ticked any permissions at all. The token was real, valid, correctly stored, and allowed to do precisely nothing.

The reason this is worth its own entry is that the error message does not say "your token has no scopes." It says something generic about authentication, which sends a beginner straight back to the parts they already got right. They regenerate the token. They check the file. They check the spelling. The one screen they do not go back to is the permissions checklist they scrolled past on the way to the green button.

GitHub's own guidance on personal access tokens is explicit that you should grant the minimum scopes needed, which is correct advice that reads very differently once you know the failure mode for granting none.

There is a real tension here that nobody acknowledges. Least privilege is the right principle, and it is also the principle that produces this exact failure for beginners, because a person who does not yet know what the tool needs cannot pick the minimum set. The honest sequence is to start narrow, fail, read the error, and widen by one scope at a time. That is slower than ticking everything, and it teaches you what the tool actually touches, which is knowledge worth having before you connect it to anything that matters.

The other half of this is that a token is not the only thing that can be underpowered. Your own account can be too. If you do not have permission to perform an action in a system, connecting an AI tool to that system does not grant you permission, and the failure will look identical to a broken connection. Check what you can do by hand before assuming the integration is at fault.

The fix: When you generate any token, screenshot the permissions screen before you click create. When authentication fails later, check that screenshot first, then check whether your own account could perform the action manually.

4. The convenient forever key

Most of these disappear when someone watches you set it up once. That is a large part of what my 1-on-1 sessions actually are.

Every reconnection problem creates pressure to make the credential permanent, and the pressure is legitimate. Short-lived tokens expire mid-task. They expire between sessions. They expire on the morning you have twenty minutes to get something done. So when the tool offers you the option of no expiry, it is genuinely tempting.

I offered exactly that choice to a student, framed as permanent or thirty days, and she picked permanent. It was the reasonable answer to the problem in front of her. It also means a long-lived credential to a live production system now exists indefinitely, and given the folder question from pattern one had still not been resolved, it may exist indefinitely inside a shared location.

Expiry	What it costs you	What it costs you if it leaks
30 days	Rotating it monthly	An exposure with a deadline on it
90 days	Rotating it quarterly	A longer, but finite, window
Never	Nothing, ever	An exposure with no end

Ninety days is usually the honest compromise. Long enough that you are not fighting it every session, short enough that a mistake eventually closes itself.

The fix: Never choose no expiry on anything connected to a production or company system. Take ninety days and put the renewal in your calendar the day you create it.

5. The committed secret

The classic, and the only one on this list that most tutorials actually warn you about, which is exactly why it still catches people who follow tutorials.

You do the right thing. You put your key in an environment file instead of typing it into your code. You feel good about it. Then you commit your work, and because that file was never excluded, the secret goes up with everything else. It is now in the history of that repository. Removing the file in a later commit does not remove it from the history, and if the repository is public, assume it was scraped within minutes.

The exclusion has to exist before the first commit, not after:

# .gitignore
.env
.env.*
*.key
*.pem

The wildcard on the second line is the one people miss. A single entry for .env does not cover .env.local or .env.production, and those are exactly the files that tend to hold the real credentials.

If it has already happened to you, the fix is not to delete the file and hope. Assume the credential is compromised and rotate it: revoke the old one at the source, issue a new one, and update your environment file. Cleaning the history is a separate and much fiddlier job, and it is pointless if the secret is still valid. Revoke first, tidy later.

The good news, from watching this play out live: the tools themselves are getting genuinely protective. In one session I watched an AI assistant refuse to paste a token into a chat window and, separately, refuse to approve its own pull request. Both refusals were correct. Both taught the lesson better than my explanation had, because the student saw a machine decline to do something unsafe and worked out why on her own.

The fix: Create the ignore file in the same minute you create the project, before any credential exists. Then verify by asking your AI tool to list every file it is about to commit.

Start here

If you do one thing from this list today, do pattern one. Check where your project folder actually lives. Not because it is the most dramatic failure, but because every other mistake here is contained if the folder is local and private, and every one of them is amplified if the folder is synced and shared.

Run the path check from pattern one. If a sync service appears in the path, move the project to a plain local folder now.
Create your ignore file with the four lines above, before you generate any credential.
Go through whatever tokens you already have and re-issue anything with no expiry at ninety days.

If you are setting up on Windows and want the environment side done properly from the start, the Claude Code on Windows walkthrough covers it, and the six setup problems that stall beginners has the wider pattern this one sits inside. For the mistakes that show up later, once the setup is behind you, see six mistakes professionals make with AI tools. If your company controls your access and you are unsure what is even permitted, what to do when your company blocks Cowork is the companion piece.

From the session logs of AI Tutor Code: 1-on-1 Python and AI tutoring for working professionals. Every pattern above happened in a real session and is anonymized to roles.