- Treat an AI coding session as a place where a password, API key or private file can be copied by mistake. Keep secrets out of prompts, tool output and local logs.
- Use short-lived credentials, narrow access and a secret scanner before code is committed or shared. Review what an assistant is allowed to read and run.
- If a secret appears, stop using it, rotate it, check where it travelled and remove it from the working copy. Do not assume deleting one line fixes every copy.
AI coding tools can be very useful. They can explain code, suggest a test or help untangle a build error. Many can also read files, run commands and call connected tools. That changes where a secret can leak.
A secret is a password, API key, access token or private signing value. It proves that a person or system may use another service. If it appears in a prompt, a terminal output or a local file an assistant can read, it may move before a normal code review sees it.
This is not a reason to ban every assistant. It is a reason to make the safe path easy. A few small rules can let a team use the tool while keeping access material out of its view.
Why repository checks are no longer enough
Most teams already scan a repository and a build pipeline. Those checks still matter. But an AI session happens earlier. A developer may paste an error message that includes a token. An agent may read a .env file. A command may print an environment value into the chat or a log.
Current research from GitGuardian found more than 28 million new hard-coded secrets in public GitHub commits during 2025. Its report also found secrets in AI-related configuration files and collaboration tools. The exact numbers do not mean every coding session is unsafe. They show why the laptop and the assistant workflow need care too.
NIST's Secure Software Development Framework asks teams to protect software and its data throughout development. UK NCSC guidance on secure AI development makes the same broader point: set security requirements early and keep control of access as a system is built and used.
Start with one clear rule
Do not paste a live credential into an AI prompt. Do not ask an assistant to read a secret file. Do not run a command that prints all environment values into a session. This rule sounds simple because it should be simple enough to use when someone is debugging under pressure.
Use a harmless placeholder when you need help with code. Write API_KEY=example, not a real value. Remove customer data from a sample. Replace a private host name with a generic one. The assistant can usually explain the shape of a problem without the access material.
| Risky request | Safer request |
|---|---|
| “Here is my full deployment log. Find the bug.” | “Here is the error section with tokens and host names removed. What could cause it?” |
“Read my .env file and fix the setup.” | “Here are the variable names and the expected formats. What configuration should I check?” |
| “Run a command to show every environment value.” | “Check whether the named variable exists, but do not print its value.” |
Give the assistant a smaller workspace
Do not let a new tool see every folder by default. Start it in the project folder it needs. Keep credential files, downloads and unrelated work outside that scope. If the tool lets you choose file access, allow the smallest useful set.
Use separate accounts or profiles for work that carries higher risk. Our guide to a clean admin browser profile shows the same useful habit: keep powerful work in a quieter, smaller space. For automation, give each connected tool a named owner and limited permissions. Our AI access review checklist explains how to record that access.
Before you enable a tool connection, ask four questions. What can it read? What can it change? Where do its outputs go? How do we turn it off? Write down the answers for connections that touch source code, cloud accounts or customer data.
Put checks at the handoff points
A single scan at the end is helpful, but it is not enough. Add checks where a secret can move: before a prompt is sent, before a command runs, before a commit is created and before code is pushed. Use the controls your team can run consistently.
For many teams, that means a local secret scanner, a pre-commit check and a server-side check in continuous integration. The aim is not to punish a developer. It is to flag the value while it is still easy to replace.
Also look at logs. A safe command can return a sensitive value by accident. Ask tools to report that a setting exists, not print the setting. Turn off verbose logging where it would copy credentials. Treat exported chat transcripts and terminal history as places that may need the same protection as source files.
Use credentials that are easier to replace
Some access values create more damage than others. A long-lived administrator key is hard to rotate and easy to reuse. A short-lived token with one narrow permission gives an attacker less to use if it leaks.
Use a secret manager or another approved store instead of hard-coding a value. Pass a reference to the application when possible. Give development, test and production separate credentials. A development token should not be able to change production billing or delete customer data.
These controls will not make an accidental paste harmless. They can reduce the time and scope of the response. They also make it clearer which system owner needs to act.
What to do when a secret appears
Act as though the value is exposed. Stop using it. Rotate or revoke it through the normal owner. Check the prompt, logs, local history, chat export, commit history and any connected ticket where it may have been copied. Then replace the value through the approved secret store.
Do not rely on a quick edit. Removing a line from the latest file does not remove an earlier commit, a log or a conversation copy. Record what happened and what was changed. If the value had broad access, follow the incident process and check for unexpected use.
This can feel slow. It is usually faster than guessing later where a credential travelled. A rehearsed response makes the next incident less disruptive.
Try a short team check this week
Pick one active project. List the secret files, tool connections and commands that can expose credentials. Make one safe prompt example. Turn on one local or pre-commit scan. Then test the revocation step for a low-risk development token.
Keep the first pass small. The goal is a working habit, not a large policy document. Review the setup after a week. If a rule is unclear, rewrite it in plain language. The best guardrail is one people can follow when the work is moving fast.
Sources and further reading
- NIST: Secure Software Development Framework
- UK NCSC: Guidelines for secure AI system development
- GitGuardian: State of Secrets Sprawl 2026
- GitGuardian: Local guardrails for secrets security
Frequently asked questions
Can I use an AI coding assistant with a private repository?
Yes, but private code is not a substitute for access control. Limit what the assistant can read, avoid sharing credentials and use the provider settings your organisation has approved.
Is a redacted log useful for debugging?
Usually. Keep the error type, code path and timing, then remove tokens, personal data, internal host names and values that prove access.
What is the first control to add?
Start with a clear no-secrets-in-prompts rule and a secret scan before commits. Add more checks as the team learns where its tools handle sensitive data.