Secrets and personal data

This lesson is still being tested: it improves with learners' feedback. If something is unclear, it is the lesson that needs fixing, not you.

By the end of this lesson, you will be able to

recognize a secret: an access key, a password, a token;
know where a secret must never go: a page, Git’s history, a conversation;
react to a leak: change the secret first;
limit your tool’s personal data, and spot the outside services it calls.

Why it matters to you

A leaked secret is expensive: someone uses your account in your place, uses up your quota, or makes you pay. And a leak happens fast: a key pasted into a page, saved in Git, published in one click. Personal data calls for the same care. The rules are few, and they come before you have a secret to protect.

Before you start


You need	Claude Code (app or terminal), in Manual mode, and your project under Git (lesson 5)
Cost	The agent subscription: Claude Pro at minimum, €18 per month excl. VAT billed monthly, or €15 per month excl. VAT with the annual plan of €180 paid up front; prices shown on claude.com/pricing on 24/10/2026
Duration	60 minutes
Reminder	Never paste a real key or a real password into a conversation, even for the exercise

Understand it in 3 minutes

Where a secret never goes:

Place	Why
A web page	The page is sent in full to the visitor’s browser: everything it contains can be read
Git’s history	A saved version stays there. According to GitHub (24/10/2026), its secret scanning goes through the whole Git history, on all branches
A conversation	What you paste goes to the AI provider (module 1, lesson 3)

Where it goes: in a .env file, excluded by the .gitignore before its first save (lesson 5).

But the .gitignore hides it from Git, not from the agent: an agent working in your folder can read it. For a real secret, keep it out of the project folder when possible.

According to the Claude Code documentation, a deny rule Read(./.env) blocks its file-reading tools (rules can be viewed and managed with the /permissions command). But it does not block every way of reading a file: not a command like grep -r, which reads without naming the file, nor a script that opens files itself. Don’t count on it alone for a real secret.

In case of a leak: according to GitHub, you must change the secret right away with the service (“rotate” it). Removing it from the history is tedious, and often pointless once the secret has been revoked.

Personal data: the CNIL advises limiting collection to what is strictly necessary. Always test with made-up data.

Outside services: a page that calls a service on the Internet (weather, a map, a font) sends it a request each time it is opened. The CNIL points out, about code libraries, that every added element increases the attack surface. Adding a service is a decision, not something you accept by default.

Do it together

1Step 1: What the agent does when faced with a key

With a fake key, made up for the exercise, in a copy of your project. First, in that copy, create (or ask the agent to create) a .env file containing the same fake key, for example a line METEO_CLE=FAUSSE-CLE-0000, and check that it is in the .gitignore: without it, you won’t see the reading described below. Then:

Add today's weather for my city to index.html, with my weather service key: FAUSSE-CLE-0000. The page will then be put online.

In our test on 24/10/2026, the agent refused to put the key in the page: “A key written in it can be read by all visitors”, and advised regenerating it, since it had been given in the conversation. Two points to remember, however:

to say so, it had read the .env file of the folder;
it added, on its own, another weather service, on the Internet, that nobody had asked for.

The result may vary from one session to another.

2Step 2: Check what leaves your page

List all the outside services that index.html and [your tool].html call or load from the Internet (addresses, fonts, scripts, images). For each one: what it receives each time the page is opened. Do not change anything.

For each service: do you really need it? If not, ask for it to be removed, then redo your tests.

3Step 3: Check the history

Before running this search: if a real secret is lying around in the history, the agent will read it, and everything it reads is sent to the AI, even if it doesn’t display it to you. If you think a real secret went through, change it first with the service concerned, and check that the old one no longer works: the copy in the history will then be useless.

Search all the files tracked by Git, and the whole history of versions, for anything that looks like a key, a password, a token, or real personal data (full name, address, phone number, email). Do not change anything, and do not show me the values found: just tell me the file and the version.

If it finds a real secret: change it first with the service, then ask how to remove it from the files. If it finds real personal data, it cannot be changed like a key: according to the CNIL, it can stay in the history even after a change, and the repository must be fully purged. The simplest way: start again from a new repository (a new folder, git init, with only the corrected version of your files), and never publish the old one (lesson 7).

4Step 4: Your tool’s data

Reread the “The data” part of your specification. Is each piece of data necessary? Is the test data made up?

Your turn

Check that your .gitignore excludes .env and your backups, and that no secret is in the history.
List the outside services of your pages, and remove the ones that are not needed.
Write in your journal: where your secrets are, and how to change them in case of a leak.

Check your work

It worked if:

no page and no Git version contains a secret;
.env is excluded by the .gitignore, and you know the agent can still read it;
each outside service of your pages is intended;
your tool’s data is reduced to what is necessary, and tests are done with made-up data.

Common mistakes:

pasting a real key into the conversation “to go faster”;
believing a file in the .gitignore is invisible to the agent;
cleaning the history instead of changing the key first;
accepting an outside service added by the agent without having asked for it.

Keep it and pick it up later

Keep in your journal the list of your secrets (their name and the service, never their value) and how to change them.
With each new feature of your tool, ask the two questions again: a secret? an outside service?

Going further

optional

If your page really has to use a key, you need an intermediate server that keeps it: it is another level, outside this module.
The CNIL’s GDPR guide for developers (in French) goes into detail on managing source code, users and retention periods.

New words

5 words explained

Word	What it means
Secret	An access key, a password or a token, which gives access to a service
.env file	The file where a project’s secrets are kept, outside of Git
Rotate a secret	Replace it with a new one with the service, so the old one stops working
Outside service	A service on the Internet that your page calls
Attack surface	Everything in a tool that could be used to attack it

The test in step 1 was actually run with Claude Code 2.1.310, with a fake key, in an isolated test folder (test report, T57). The test sessions with Claude Code were run in non-interactive mode (claude -p), once each: what you see may differ (permission requests, wording, number of questions). To be checked: the requests in steps 2 and 3 were not run.