AI coding agents are becoming more capable of working directly with software repositories. They can search files, inspect dependencies, modify code, run tests, and use command-line tools to complete development tasks.
That capability also creates a security question developers should answer before giving an agent access to a real project:
What files can the agent actually read?
The answer may be broader than the files currently open in the editor.
An agent can potentially access source code, configuration files, documentation, generated files, Git metadata, environment variables, and other files available through its tools.
Understanding that access is an important part of securing AI-assisted development.
Why File Access Matters
Consider a project directory like this:
MyApplication/
|
+-- src/
+-- tests/
+-- docs/
+-- scripts/
+-- .git/
+-- .env
+-- local-config/
+-- secrets/
A developer may expect the AI agent to work only with:
src/
tests/
But if the agent has broad file-system permissions, it may be able to inspect much more.
The security boundary therefore depends on the agent's actual permissions, not simply on what the developer expects it to read.
An AI Agent Can Have Multiple Ways to Read Data
File access does not necessarily happen through one mechanism.
A coding agent may receive information through:
Agent
|
+--> File Read Tool
|
+--> Repository Search
|
+--> Code Index
|
+--> Shell Command
|
+--> Git Commands
|
+--> Build Tools
|
+--> Environment Variables
For example, even if direct access to a file is restricted, a shell command could potentially expose its contents if the agent has unrestricted command execution.
This is why reviewing only the file-reading capability is not enough.
Start With the Agent's Permissions
The first question should be:
What permissions does the agent have?
A useful permission inventory looks like this:
Capability | Question to Check |
|---|
File read | Which directories can it read? |
File write | Which directories can it modify? |
Command execution | Which commands can it run? |
Network | Which external services can it reach? |
Git | Can it inspect repository history? |
Environment | Which variables are available? |
Secrets | Can it access credentials? |
Tools | Which plugins or integrations are enabled? |
The exact capabilities depend on the coding agent and its runtime environment.
Check the Workspace Boundary
Many coding agents operate within a workspace.
For example:
Workspace
|
+-- src/
+-- tests/
+-- docs/
Ideally, the agent's file operations should be limited to the intended workspace.
However, developers should verify this rather than assume it.
A useful test is to create a harmless file outside the project:
test-access.txt
Then determine whether the agent can locate or read it.
Do this only in a safe development environment, not on a machine containing sensitive information.
Test File Access Explicitly
One practical way to understand an agent's access is to create a controlled test repository.
For example:
agent-access-test/
|
+-- allowed/
| +-- public.txt
|
+-- restricted/
+-- private.txt
Put harmless test content in both files.
Then test requests such as:
Read allowed/public.txt
and:
Read restricted/private.txt
The purpose is not to bypass restrictions. It is to verify whether the tool's documented access boundary matches its actual behavior.
Check Directory Traversal
A common mistake is testing only one file.
File-system permissions should also be tested across directory boundaries.
For example:
workspace/
|
+-- project/
|
+-- unrelated-project/
|
+-- test-data/
If the agent is intended to operate only inside project/, verify that it cannot freely enumerate or read unrelated directories.
This is especially important when multiple repositories exist on the same development machine.
Shell Access Can Expand File Visibility
Suppose an agent can run:
dir
or:
Get-ChildItem
on Windows, or:
ls
on Linux and macOS.
The agent may discover files that were never explicitly provided as model context.
More importantly, unrestricted command execution can potentially provide access to locations outside the intended workspace.
For example:
Agent
|
v
Shell
|
+--> File System
+--> Processes
+--> Environment
+--> Network
Therefore, shell access should be treated as a powerful permission.
Check Environment Variables
Environment variables can contain sensitive information.
For example:
DATABASE_CONNECTION
API_TOKEN
CLOUD_ACCESS_KEY
PRIVATE_SERVICE_URL
An agent that can inspect the environment may potentially see values that are unrelated to the coding task.
A simple development test can use a harmless variable:
$env:AGENT_ACCESS_TEST = "non-sensitive-value"
Then determine whether the agent can access it.
Never use real production credentials for an access test.
Do Not Test With Real Secrets
A security test should never look like this:
Production API Key
|
v
AI Agent
|
v
"Can you read this?"
If the agent can access the secret, the test itself has already created unnecessary exposure.
Use synthetic values instead:
TEST_SECRET_12345
This provides enough information to understand the permission boundary without creating an incident.
Check Git Access Separately
Git access deserves special attention.
A coding agent may be able to run commands such as:
git status
git log
git diff
git show
These commands can expose more than the current working files.
For example:
Current Code
+
Uncommitted Changes
+
Commit History
+
Deleted Files
Git history can contain sensitive information that is no longer visible in the current project.
Check What the Agent Can Index
Many coding agents maintain a repository index.
A simplified architecture looks like this:
Repository
|
v
Indexer
|
v
Code Index
|
v
Search
|
v
AI Model
The important question is:
Which files are included in the index?
Check whether the tool indexes:
Source files
Tests
Documentation
Configuration
Hidden files
Generated files
Git metadata
Dependency information
Different tools have different indexing behavior.
Exclusion Rules Need Verification
Suppose your repository contains:
src/
tests/
secrets/
You may configure the AI tool to exclude:
secrets/
Do not assume the exclusion works simply because the configuration exists.
Test it with harmless content.
For example:
secrets/
test-only-secret.txt
Then verify that repository search and agent requests cannot retrieve the file.
The test should be performed in a controlled environment.
.gitignore Is Not an AI Permission System
This distinction is important.
A .gitignore file controls which files Git normally tracks.
It does not automatically determine which files an AI coding agent can read.
For example:
.env
in .gitignore may prevent the file from being committed, but a local agent with file-system access may still be able to read it.
Therefore:
Git exclusion
!=
Agent access control
Use the controls provided by the AI coding tool and its execution environment.
Check Network Access Too
Suppose an agent can read a sensitive file.
The next question is:
Can the agent send that information somewhere else?
Consider:
Sensitive File
|
v
AI Agent
|
+----> Local Model
|
+----> External API
If external network access is allowed, the security boundary extends beyond the local machine.
For privacy-sensitive workflows, network permissions should be explicitly reviewed.
A Simple Permission Test Matrix
A controlled test can use a matrix like this:
Resource | Expected Access | Actual Result |
|---|
Project source | Allowed | Verify |
Project tests | Allowed | Verify |
Parent directory | Restricted | Verify |
Other repository | Restricted | Verify |
Test secret file | Restricted | Verify |
Environment variable | Restricted | Verify |
Git history | Depends on policy | Verify |
External network | Depends on policy | Verify |
The point is to compare intended permissions with observed behavior.
Test the Agent in a Sandbox
The safest way to investigate an unfamiliar coding agent is to use an isolated environment.
For example:
+--------------------------------+
| Test Environment |
| |
| Synthetic Repository |
| Test Files |
| Fake Credentials |
| Local Build Tools |
| AI Coding Agent |
+--------------------------------+
Do not start by connecting the agent to your most sensitive production repository.
First establish what it can see and do in a controlled environment.
Example With a C# Repository
Suppose you create:
AgentSecurityTest/
|
+-- src/
| +-- Program.cs
|
+-- tests/
| +-- ProgramTests.cs
|
+-- restricted/
| +-- internal-test.txt
The normal development workflow might include:
dotnet build
dotnet test
You can then ask the agent to:
List the files available in this workspace.
Then:
Read src/Program.cs.
And finally:
Find files outside the project directory.
The goal is to determine whether the agent respects the intended boundary.
Do not use real credentials or confidential source code during this experiment.
Check File Write Access Too
Reading is only one side of the problem.
An agent that can write files can potentially modify:
Source code
Configuration
Build scripts
CI files
Infrastructure definitions
Documentation
A useful security model distinguishes:
Read
Write
Execute
Network
These should not automatically be treated as the same permission.
For example:
Source Code -> Read + Write
Secrets -> No Access
System -> No Access
Network -> Restricted
The exact policy depends on the development workflow.
Command Execution Is a Separate Risk
An agent may not need direct access to a sensitive file if it can execute commands that read it.
For example:
Direct File Read
|
X
Shell Access
|
v
File System
This is why a permission review must include tools such as:
Shell
Terminal
Git
Package Manager
Build Tools
Scripts
The agent's effective access is the combination of all these capabilities.
Check Temporary and Generated Files
Developers often focus on source files and forget temporary artifacts.
AI coding tools may interact with:
Build output
Logs
Temporary files
Caches
Generated source
Test results
Coverage reports
These files can sometimes contain sensitive information.
For example, a test log might contain:
Request URL
User identifier
Database error
Configuration value
The agent's workspace should therefore be reviewed as a whole.
Common Mistakes
Assuming the Open File Is the Only Input
Repository-aware agents can search and retrieve additional files.
Testing With Real Credentials
Always use synthetic test values.
Ignoring Shell Access
Command execution can greatly expand the effective permission boundary.
Checking Only Read Permissions
Write and execute capabilities can be equally important.
Assuming .gitignore Prevents Access
Git tracking rules do not automatically control local file access.
Ignoring Git History
Historical commits can contain sensitive information.
Skipping Network Review
A local agent with unrestricted network access can still communicate externally.
Testing Directly on Production Repositories
Understand the tool's behavior in a controlled environment first.
Best Practices for Checking Agent File Access
Start With a Synthetic Repository
Use harmless files to establish the agent's capabilities.
Document Expected Permissions
Write down what the agent should and should not access.
Test Each Capability Separately
Check:
File read
File write
Directory traversal
Shell execution
Git access
Environment access
Network access
Use Least Privilege
Give the agent only the permissions required for its job.
Isolate Sensitive Repositories
Use separate environments when stronger boundaries are required.
Review Indexing Configuration
Verify which files and directories are indexed.
Monitor Actual Behavior
Configuration tells you what should happen. Testing tells you what actually happens.
Advantages of a Proper Access Review
A structured access review can:
Reveal unexpected file permissions
Identify unnecessary agent capabilities
Reduce accidental exposure of secrets
Clarify repository boundaries
Improve confidence in AI coding workflows
Provide useful evidence for security reviews
Limitations
Access testing also has limitations.
A test performed today may not describe future behavior if the tool changes.
Updates can modify:
Agent capabilities
Indexing behavior
Network endpoints
Default permissions
Extensions
Telemetry
Therefore, important AI coding tools should be reviewed periodically rather than only once.
A Practical Security Checklist
Before connecting an AI coding agent to a sensitive repository, verify:
[ ] Workspace boundary is understood
[ ] File read permissions are known
[ ] File write permissions are known
[ ] Shell access is understood
[ ] Git history access is reviewed
[ ] Indexing rules are verified
[ ] Sensitive files are excluded
[ ] Environment access is restricted
[ ] Network access is reviewed
[ ] Extensions are reviewed
[ ] Repository permissions are enforced
[ ] Secrets are not exposed
[ ] Test environment has been used
This checklist can also be incorporated into an organization's AI development security review.
Summary of the Article
Understanding what an AI coding agent can read is more complicated than checking which file is currently open in the editor. An agent may have access through direct file operations, repository indexing, shell commands, Git, environment variables, build tools, and extensions.
The safest way to understand these permissions is to test the agent in a controlled environment using synthetic files and harmless test values. Developers should verify both the intended configuration and the agent's actual behavior.
A proper review should cover file reads, writes, command execution, Git history, indexing, environment variables, network access, and external integrations. .gitignore should not be treated as an AI access-control mechanism, and real credentials should never be used for permission testing.
The main principle is simple: before trusting an AI coding agent with a repository, know exactly what it can read, write, execute, and access.
Join the conversation! Your thoughts help the community grow.