How to See What Files Your AI Agent Accesses

AI coding agents — Claude Code, Cursor, Hermes, OpenClaw — have direct access to your filesystem through your user account permissions. Most builders know this in principle but don't have a way to see what the agent actually touched during a session.

What files do AI agents read?

AI agents read two categories of files. The first is context files — everything they load to understand your project before they start working. Claude Code reads CLAUDE.md from the project root, parent directories, and relevant subdirectories. Cursor indexes your entire workspace on launch. Both read source files, config files, and any documentation in scope.

The second category is files the agent reads during task execution. When an agent runs a shell command, reads a file to answer a question, or checks a config before modifying it, those reads happen with your user permissions. There is no sandbox around them. If .env is in your project directory and an agent cats it — either on its own or as part of a task — that access happens silently from your perspective.

.gitignore does not protect files from local agent access. Git ignore rules control what gets committed to version control, not what gets read from disk. Your .env is fully readable regardless of what's in .gitignore.

Why does file access visibility matter?

The gap isn't whether agents can access sensitive files — they can, by design. The gap is not knowing which files they did access during a session.

This matters for a few reasons. A prompt injection attack can cause an agent to read files you didn't ask it to touch. A compromised skill or MCP server can trigger reads of credential files as part of a larger exfiltration attempt. And even without an attack, an agent that reads your SSH directory or cloud credential file while completing a routine task is doing something most builders would want to know about.

Framework logs record what the model was asked and what it responded, not what files the process opened. Those are two different things.

How do I see what files my agent accessed?

There are two approaches, depending on how much detail you need.

For after-the-fact review, most operating systems provide access to filesystem event logs. On Linux, auditd can be configured to log file reads by process. On macOS, fs_usage captures live filesystem events by process. These tools require setup and produce verbose output that needs filtering to be useful.

For ongoing monitoring with alerting, a dedicated monitoring layer is more practical. AgentGuard360's Shield scan monitors filesystem activity across all agents running on your machine — surfacing which processes accessed which file paths and flagging reads of sensitive locations (credential files, SSH directories, environment files). Access events appear in a dashboard organized by file and process — showing whether the access came from a system process or an agent — and alerts fire when a sensitive file is read.

The practical difference is aggregation: raw OS logs tell you a read happened; a monitoring tool tells you which agent did it, what file it was, and whether that matches a pattern worth investigating.

What are common mistakes to avoid?

• Relying on ignore files for security — .claudeignore and .cursorignore reduce what agents load for context, but don't block file reads during shell tool use. They're scope controls, not access controls.
• Assuming framework logs are complete — agent frameworks log model interactions, not OS-level file access. A file read that happens inside a shell command won't appear in the LLM call log.
• Treating all file access as equivalent — reading source code is normal; reading .env, .ssh/id_rsa, or ~/.aws/credentials is a different category of event worth tracking separately.