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:

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:

Limitations

Access testing also has limitations.

A test performed today may not describe future behavior if the tool changes.

Updates can modify:

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.