Module 1 · Start safely
What stays out of the model: secrets, production data, client code
In short
Keys, passwords, production data, client code under agreement and personal data are not pasted into a model. Use synthetic samples or empty schemas instead, and check what an agent can read before giving it access.
After this lesson you can
- Name four things never pasted into a model: secrets, production data, client code under agreement, personal data
- Replace sensitive material with synthetic samples, empty schemas or cleaned code excerpts before asking AI for help
- Check the AI tool's settings and the team's rules before giving a coding agent access to a repository
Terms in this lesson
Understand
A coding assistant feels like a colleague at the next desk: you paste an error, it explains; you paste a function, it tidies. Because it feels so familiar, developers easily forget that every pasted text leaves their laptop and enters someone else's service, or an agent's context file that may be read again later.
Four kinds of material stay out of the model, whatever the tool.
Secrets. API keys, access tokens, database passwords, environment files, certificates and SSH keys. A leaked key can be used by anyone who reads it, and you cannot take back text that has been sent. If your error contains a full connection string, remove the secret part before pasting.
Production data. User table rows, order contents, logs holding email addresses or phone numbers, database backups. To understand a bug, a model rarely needs real data; it needs its shape. A table schema, three made-up rows and the error message are usually enough.
Client code under agreement. Code you write for a client is often covered by a confidentiality contract. Pasting it into an AI service can breach that contract, even if you only wanted help tidying it. Check the agreement, or ask the project lead, before client code touches any AI tool.
Personal data. Names, ID numbers, addresses, health data or children's data in fixtures, logs or screenshots. The PDP Law applies to developers too: moving personal data into another service is processing and needs a lawful basis.
The practical rule is simple: send the shape, not the contents. The model needs to know the structure, types and pattern of the problem, not the real values.
A coding agent adds another layer of risk. An assistant in a chat window only reads what you paste. An agent running in your repository can read on its own: the environment file at the project root, a backup folder, meeting notes saved in the repository, or terminal history. It can also run commands that touch a database.
So before giving an agent access, check three things. First, what is in its working folder: secret files should not be in the repository at all, and if they must exist on the local machine, make sure the agent is set not to read them. Second, where its commands can connect: environment variables pointing at the production database or a shared developer database must not be the default when the agent runs tests. Third, what the tool stores: some services keep conversations or use them for training unless set otherwise. That setting is your organisation's to decide, not a personal choice.
Before
The prompt
Why is this query slow? postgres://app:Secret123@db-prod:5432/main SELECT * FROM customers WHERE email = 'siti.rahma@example' ... [then 50 result rows with customer names and phone numbers]
What came back
Bad example output, do not use: The query is slow because there is no index on the email column. Add an index. By the way, the database password in your connection string should be changed.
After
The prompt
Goal: I want to know why the customer search query is slow. Reader: me, a backend developer. Material: the customers table schema (no data), the query with sample values and the execution plan below. The table has about two million rows. Limits: do not guess beyond the material; if you need other information, ask. Shape: three possible causes, most likely first, each with a way to prove it. Check: name the part of the execution plan that supports each possibility. [schema] [query with a sample email] [execution plan]
What came back
Three possibilities: (1) a full table scan because the email column has no index, seen in the sequential scan line of the plan; (2) a case-insensitive comparison that stops the index being used; (3) too many columns selected. To prove it: create the index on a local copy, rerun the execution plan, compare the cost.
What changed
- The first request sent a production password and fifty customers' personal data. Neither can be taken back.
- The second request sent the shape of the problem: schema, query with sample values and execution plan. The result is sharper because the model had evidence to read.
- A password that has been sent must be rotated that same day, however politely the model suggests it.
Common mistake
- Mistake
- Pasting a whole environment file into a model to ask why the app cannot connect to a service.
- Why it hurts
- An environment file holds every secret of the app at once. Once sent, you must treat all of them as leaked and rotate every key, which can take half a day and disrupt other services that share those keys.
- Do this instead
- Send only the list of variable names, with values replaced by a marker such as ‹hidden›, plus the error message. If the value format matters, describe its pattern in words.
Try
Sorting card
For each item, decide: may it go to the model, or must it be replaced first?
A table schema with no data rows
A database connection string with its password
A payment module written for a client under a confidentiality agreement
A compile error from your own team's code
A production log containing users' email addresses
Three test rows you made up with fictional names
6 cards left
You want a coding agent to run tests in the repository. Your local environment file points at the team's shared developer database. What do you do first?
Take home
Before pasting or granting access
- I have removed keys, tokens and passwords from the text I will send
- I send schemas and made-up samples, not production rows
- I have confirmed client code may be shared with this AI service
- Logs and screenshots are clean of personal data
- The agent's working folder holds no secret files, and its test command points at a throwaway database
- If a secret was sent by mistake, I rotate it that same day
What went wrong for us
Secrets never go into public browser variables
- Context
- Web apps read configuration from environment variables. Some are used only by the server; others are deliberately compiled into the code the browser downloads.
- What tends to go wrong
- If a service provider key is kept in a public browser variable, it ships to every visitor. Anyone who opens the developer tools can copy it.
- What it costs if ignored
- Others can use the service in your organisation's name and on its bill, and you cannot prove who used it.
- Root cause
- In a config file, public and secret variables look the same. The only difference is a name prefix, which is easy to miss in a hurry.
- How we do it
- Keys are read only by the server, and the browser never receives a secret. If a key ever appears in browser code, we revoke and rotate it at once.
- The rule we keep
- A test fails whenever a public variable is named like a secret (key, token, password), in code or in config files.
The lessonTreat everything that reaches the browser as already read by someone else.