An AI coding agent should never be able to read credential files, private keys, cloud config directories, production environment files, browser profiles, and exports of customer data. Enforce this with isolation and file permissions, not only with a rule telling the model to stay away.
Why the question matters
Everything an agent reads can end up in a prompt, and prompts leave the machine for a model endpoint. OWASP lists Sensitive Information Disclosure as LLM02 in its 2025 Top 10 for LLM applications. A file the agent has no access to cannot leak, whatever the model does or whatever a poisoned instruction says.
The exclusion list
| Category | Examples | Why |
|---|---|---|
| Credential files | environment files with tokens, package registry config, cloud CLI config folders | Direct account access |
| Key material | SSH private keys, signing keys, certificates with private parts | Identity theft, signing abuse |
| Production config | deploy manifests with live values, database connection settings | Lateral movement |
| Personal data | customer exports, support transcripts, test dumps copied from production | Privacy duties, breach scope |
| Other projects | sibling repositories, shared drives | Scope creep |
| Browser and chat data | profiles, cookie stores, message archives | Session theft |
Adjust the list for your stack, but keep it short enough that people remember it.
Four ways to enforce it
- Mount less. In a container, mount only the project. Files that are not mounted do not exist for the agent.
- Use a separate account. A dedicated OS user cannot read another user's home directory by default.
- Keep secrets out of the tree. Load secrets from a manager at run time instead of storing them in files beside the code. For local development, use short lived tokens.
- Use tool level ignore rules as a second layer. Many tools can be told to skip certain paths. Treat this as a convenience, not a guarantee, since a shell command can still read what an ignore list hides.
Be honest about which of these your tools support, and test them.
A quick test
In a throwaway project, create a file named like a credentials file with a harmless dummy value. Ask the agent to summarize the repository, then to debug a config problem. Check whether it opens the dummy file and whether the content appears in any log you can see. Repeat with the ignore rules on. The results show how much to trust each layer.
Handling the accident
Assume that someday a real secret will be read. Prepare for it:
- Know how to rotate each credential class quickly.
- Prefer short lifetimes so rotation is mostly automatic.
- Keep an inventory of where each credential lives.
- Ask your tool vendor how long prompts are retained and who can access them, and keep their answer on record.
Rotation speed turns an incident into a chore.
What about code itself
Source code is often confidential too. Decide whether the repository is allowed to go to the model endpoint at all. Many teams classify repositories into tiers, such as public, internal, and restricted, and allow agents only on the first two at the start. Our post on AI coding assistant data leakage paths maps where the data can travel.
Safeguard can help at the dependency and pipeline end of this: SBOM and dependency scanning, reachability analysis, policies and gates on pull requests, and agent identity. You can try a free scan at gold.safeguard.sh/scan.
A worked example: auditing one repository
A team audits a typical service repository before enabling an agent. They list what is reachable from the working directory and from the user's home, then mark each item.
| Item found | Where | Action |
|---|---|---|
| Environment file with a database password | Project root | Move to a secret manager, delete the file, rotate the password |
| Cloud configuration folder | Home directory | Not mounted in the sandbox |
| SSH private key | Home directory | Not mounted, agent uses a deploy token instead |
| Sample customer export used for debugging | Data folder | Replace with synthetic data, remove from the tree |
| Registry token in a package config file | Home directory | Use a short lived token injected per session |
| Sibling repositories | Parent directory | Not mounted |
| Test fixtures with fake data | Test folder | Keep, nothing sensitive |
Of seven items, five are removed from the agent's view entirely, one is replaced, and one stays. The team did not need a sophisticated product. They needed to look at what was lying around and decide.
Why local habits matter
Secrets accumulate in places that were meant to be temporary: a shell history with a pasted token, a notes file with a connection string, an exported report left in a downloads folder. A sandbox that mounts only the project avoids most of it, but the project itself should be clean too.
- Search the repository history for files that look like credentials, using whatever tooling your team already has, and rotate anything you find.
- Add the usual credential file names to your ignore list so they do not get committed again.
- Store local development secrets in a manager and load them at run time.
- Prefer tokens that expire in hours.
Handling the data the agent legitimately needs
Some tasks need realistic data. Give the agent a masked or synthetic copy. Keep the mapping to the real data outside the sandbox. If a bug only reproduces with real data, have a person run that step and give the agent the sanitized result.
Classifying repositories
Not every repository needs the same treatment.
| Tier | Example | Agent policy |
|---|---|---|
| Public | Open source libraries | Allowed with standard controls |
| Internal | Typical services | Allowed in a sandbox with scoped tokens |
| Restricted | Payment, health, or key handling code | Not allowed until a specific review is done |
Write the tiers down and assign each repository an owner who confirms its tier.
Measuring success
Count how many agent sessions started in a sandbox with no mounted credentials, how many credential files were removed from repositories this quarter, and the median age of tokens agents use. These numbers show whether the habit is sticking.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through and notice what a dependency inventory shows about a project.
Quick check
Is an ignore file enough?
No. It is a hint to the tool, and a command line can bypass it. Use isolation as the main control.
Should test data come from production?
Avoid it. Synthetic or masked data keeps the agent, and your logs, out of privacy scope.
What if the agent does read a real secret?
Rotate it immediately, review provider logs for use since the exposure, and check where the session's prompts are retained.
Sources
Last reviewed: 19 October 2026.
