Which Files Did Your AI Actually Read? The Read-Audit Every Vault Owner Should Keep

Simon Willison named it — "private data, untrusted content, and external communication" — the lethal trifecta.¹ Your notes are the private-data leg. One question falls out. Which of your notes did the agent read to answer that? An answer is only as forensic as the log of what was read to produce it. Keep the read-audit yourself — the vendor won't.

The pattern is different from what a write-side audit answers. A write-audit tells you what changed — the companion piece on this blog names the discipline of keeping your own record of what your agent did.² A read-audit is the other axis. It tells you what the agent saw before it decided what to change. Both matter. Neither is automatic. In 2026 the surface an agent reads over is your files — a folder handed to Claude Code, a roots boundary in the Model Context Protocol, a personal vault indexed on-device. OWASP's LLM06:2025 puts the discipline plainly for LLM extensions: log and monitor.³ The vendor's UI often hides the reads. The OS emits them anyway.

A personal vault owner already has three tiers of visibility available — a five-minute vendor log, a thirty-minute OS-level watcher, and, for the advanced, an MCP-proxy that sniffs the tool-call wire.

What most people believe: the transcript is the record

Most agent transcripts scroll every decision in real time, and the ambient chatter feels like accountability. The transcript tells you what the model said it did. It does not tell you which of your files it opened, which chunks it retrieved from the vault, or which folder it quietly checked. Testimony is not evidence.

The frame shifted this week without much noise. An indie developer, fuzzykidoo, put the shift in one line on dev.to: "MCP didn't give AI memory. It gave AI access to memory."⁴ Whatever the model appears to remember is, in practice, a series of live reads through the tool-call bus at the moment of the answer. If reading is the mechanism, then reading is the thing to log.

The same pattern shows up in the enterprise. Teams already pay platform observability vendors to answer the read-side question at scale. That market is a signal, not the subject of this essay. The signal is that the discipline is real. The subject is what a personal vault owner can do in the next thirty minutes with tools they already have.

The pivot: the read-path is the private-data leg

Willison's lethal trifecta describes the mechanism: an agent with private data, exposure to text it did not write, and a channel to send bytes outward becomes a leak the moment the three legs touch.¹ The read-path is the first leg. Whatever the agent reads is the private data at risk of leaving.

If you cannot see which files the agent opened, you cannot see the surface on which the trifecta might be closing. The standards body has already named the practice. OWASP LLM06:2025's mitigation section opens with a caveat, then names it verbatim: "The following options will not prevent Excessive Agency, but can limit the level of damage caused: Log and monitor the activity of LLM extensions and downstream systems to identify where undesirable actions are taking place, and respond accordingly."³

The caveat is honest. Logging does not stop the read; it makes the read visible. The naming is the point. The read-side of an agent's behaviour is a normal observability surface, not an exotic one. The tools that surface it already exist on every operating system you own.

The related discipline is scope. A companion essay on this blog sets out the positive-permission root — the smallest folder you hand the agent decides what it can read.⁵ The read-audit is the sequel. Of the files it can see, which ones did it actually open this session?

The argument: three tiers of read-audit, in order of effort

Every serious agent surface in 2026 exposes a knob that shows the reads. Vendor CLIs ship a verbose flag. Every mainstream operating system emits file-access events. The Model Context Protocol standardises tools/list and tools/call at the JSON-RPC frame. The knobs differ per surface — the shape is the same. Pick the tier that matches your effort budget, and layer.

Tier (a) — the five-minute vendor log. Anthropic's Claude Code CLI reference documents --verbose as "Enable verbose logging, shows full turn-by-turn output. Overrides the [verbose setting]".⁶ Turned on, every Read invocation prints with the file path the agent opened.

Pair it with --add-dir, which the same reference defines as "Add additional working directories for Claude to read and edit files. Grants file access; most .claude/ configuration is [not discovered]".⁷ The same session ties what the agent is allowed to see to what the agent actually read. The scope decision is --add-dir. The audit decision is --verbose. Two flags, one habit.

Tier (b) — the thirty-minute OS-level watcher. The vendor's log is a courtesy. The OS emits the read whether the vendor talks about it or not. Three surfaces, three names, one habit — inotify on Linux, FSEvents on macOS, and ReadDirectoryChangesW on Windows.

• Linux. inotify(7) emits IN_ACCESS: "IN_ACCESS (+) File was accessed (e.g., read(2), execve(2))."⁸ A one-line watcher — inotifywait -m -r -e access ~/notes/ >> ~/logs/reads.log — prints every read the kernel sees. It hooks the syscall path, so it works even when the mount option turned atime off.
• macOS. Apple's official framing describes FSEvents as: "The file system events API provides a way for your application to ask for notification when the contents of a directory hierarchy are modified."⁹ The exact word is modified. FSEvents watches directory-level modifications, not per-file reads. That is the honest limit of the tier on macOS, and the essay names it below.
• Windows. ReadDirectoryChangesW accepts a filter flag called FILE_NOTIFY_CHANGE_LAST_ACCESS: "Any change to the last access time of files in the watched directory or subtree causes a change notification wait operation to return."¹⁰ It fires at the subtree level, subject to NTFS access-time being enabled.

Each hooks the syscall path the vendor UI cannot elide. If the agent opens a file inside the watched folder, the OS says so. The log is a plain text file on your own disk, not a row in a vendor's database. That is the point.

Tier (c) — the MCP-proxy, for the advanced. The Model Context Protocol standardises the tool-call bus. From the specification: "To discover available tools, clients send a tools/list request" and "To invoke a tool, clients send a tools/call request."¹¹ The same page defines the capability advertisement: "Servers that support tools MUST declare the tools capability: { "capabilities": { "tools": { "listChanged": true } } }."¹²

Because the schema is open, an in-line proxy can see every request the client makes to the server. Someone shipped one this week: kerlenton/mcpsnoop, described by its own README as "Wireshark for MCP. A transparent proxy that shows every real tool call between your AI client and your MCP servers, live in your terminal."¹³

The maintainer's own problem statement is the honest reason it exists: "The official MCP Inspector connects as its own client, so it never sees what your client (Cursor, Claude Code, Codex) actually sends your server."¹³ The Show HN post that put the tool in front of the community earned sixty-three points on July 3, 2026. Read that as the signal that the personal-vault owner's version of a discipline the enterprise already buys is being built in the open.

Team-scale observability products solve the same question with dashboards and invoices. You do not need their invoice to run the discipline. You need the tier that matches your effort budget.

The practice: keep the log yourself

Start with the five-minute tier today, and add the OS watcher when the folder starts to matter. Log the read, not the keystroke. Store the log where the agent cannot rewrite it. The habit is boring, and boring is the point. The useful audit is the one you already run when a wrong answer arrives at 11pm.

Three concrete moves, in order:

• Run every serious agent session with --verbose on. For Claude Code, claude --verbose > ~/logs/agent-$(date +%F).txt 2>&1 gets you a per-day file of every tool call, including each Read and the path.⁶ For a scoped session, claude --add-dir ~/notes/reading narrows the root before you start. The audit is only as small as the surface you handed the agent.⁷
• Point an OS watcher at the folder that matters. On Linux, inotifywait -m -r -e access ~/notes/ >> ~/logs/reads.log runs from a systemd --user service and never touches the terminal you close.⁸ On macOS, an FSEvents client at the directory level catches modifications; per-file reads need kernel-audit, which is a separate decision. On Windows, wrap ReadDirectoryChangesW with FILE_NOTIFY_CHANGE_LAST_ACCESS.¹⁰ Write the output to a plain file next to the vault.
• Reserve the MCP-proxy tier for advanced routing. If you own the MCP server the agent talks to, run a Mcpsnoop-style transparent proxy while you develop, and treat it as a temporary sniff, not a runtime dependency.¹³ Its purpose is a session's worth of forensic detail, not a permanent hook.

The layering pairs with the folder-scope discipline of the smallest working root⁵ and the write-side record of what changed.² The protocol-layer background is where these reads live in the first place. Each layer catches what the layer above lets through.

The honest caveats: three failure modes to name

This is hygiene, not security. An audit does not stop the read; it makes the read visible. Three failure modes survive every tier, and every reader should hold them. The audit records what was read, not what the vendor retains. The vendor's own log is only as complete as the vendor makes it. And OS-level watchers have real gaps.

One — the audit records the READ, not the RETENTION. OWASP names the ceiling of the discipline in the same sentence that names its usefulness: "The following options will not prevent Excessive Agency, but can limit the level of damage caused."³ Your log tells you which of your files the agent touched during a session.

It does not tell you which characters the vendor kept on their server, cached in a session store, or reserved for training absent a contrary setting. Read-audit needs to pair with a written policy about what should never have been fed to a hosted model in the first place¹⁴ and with a check on the training defaults you accepted when you signed up.¹⁵

Two — vendor --verbose is only as complete as the vendor makes it. Claude Code's documented behaviour today is full turn-by-turn output.⁶ A future release could redact tool-call arguments, elide certain paths, or omit tool calls performed inside subagents. That would be a legitimate product decision. It would also close the tier.

The OS-level tier exists precisely because it does not depend on the vendor. If the vendor's log ever disagrees with the OS log, believe the OS.

Three — OS-level watchers have real gaps. Linux's naive read-audit anchor was atime, and every modern mainstream distribution now mounts with relatime or noatime, so atime lags or disappears. inotify IN_ACCESS does not depend on atime; it hooks the syscall path, which is the honest workaround.⁸

But macOS FSEvents watches directory-level modifications, not per-file reads⁹; per-file read-audit on macOS needs kernel-audit openbsm/auditd, which needs escalated privileges and a written baseline. Windows NTFS access-time updates have been default-disabled since Vista (fsutil behavior set disablelastaccess); the FILE_NOTIFY_CHANGE_LAST_ACCESS filter fires on subtree change notifications, not on every per-file read.¹⁰ Every tier is more than nothing and less than everything.

Layered defence is the shape. The read-audit shrinks the surface a wrong answer can hide inside. The write-audit tells you what changed after the reads.² The upstream deny-list keeps sensitive classes out of the reachable folder.¹⁴ A write-side firebreak keeps a destructive delete from touching everything in scope.¹⁶ The append-only pattern preserves what an agent may write.¹⁷ Secrets never live where an agent reads.¹⁸ The user turn you typed is worth saving too.¹⁹ The session file you carried across a model handoff carries its own discipline.²⁰ Each of these is a layer. The read-audit is the one that watches the eyes.

Frequently asked questions

How do I see which files Claude Code read to answer a question? Run the session with --verbose on. Anthropic's CLI reference documents the flag as "Enable verbose logging, shows full turn-by-turn output."⁶ Redirect the output to a dated file (claude --verbose > ~/logs/agent-2026-07-08.txt 2>&1), and every Read invocation prints with the file path. Grep the transcript for Read ( to lift only the read-lines from the log.

How do I log the files an AI agent opened during a session? Three tiers. The five-minute tier is the vendor's own verbose log: --verbose on Claude Code⁶, the equivalent on your CLI of choice. The thirty-minute tier is an OS-level watcher: inotifywait -m -r -e access ~/notes/⁸ on Linux, an FSEvents client on macOS⁹, ReadDirectoryChangesW on Windows.¹⁰ The advanced tier is an MCP-proxy that sits between your client and its servers.¹³

How do I audit MCP tool calls locally? The protocol layer is where the reads live. The MCP specification defines "to discover available tools, clients send a tools/list request" and "to invoke a tool, clients send a tools/call request".¹¹ Every conforming server declares its tool capability under { "capabilities": { "tools": { "listChanged": true } } }.¹² A transparent proxy — Mcpsnoop is one reference implementation — captures every request on that channel and prints it live.¹³

Which notes did Claude Code read to answer this question? Every Read tool call is printed by --verbose with the file path.⁶ Grep the transcript for Read ( to isolate the reads. Pair the read-side transcript with --add-dir so the scope of what was allowed to be read is on the record next to what was actually read.⁷

Can my agent leak files by touching things it shouldn't? Yes. The read-path is the private-data leg of Willison's lethal trifecta.¹ The moment private data, untrusted content, and an external channel are all present, the read is the seed of the leak. The two mitigations are scoping the folder and auditing the reads inside it. A smaller root is the first move⁵; the read-audit is the second.

How do I log file reads on Linux, macOS, and Windows? On Linux, inotify(7) emits IN_ACCESS: "IN_ACCESS (+) File was accessed (e.g., read(2), execve(2))."⁸ On macOS, Apple's FSEvents API delivers "notification when the contents of a directory hierarchy are modified"⁹ at the directory level; per-file reads require openbsm/auditd. On Windows, ReadDirectoryChangesW accepts FILE_NOTIFY_CHANGE_LAST_ACCESS on subtree change notifications.¹⁰

Is a tool-call log the same as knowing what the model retained? No. The audit records the read, not the retention. OWASP says it plainly: the discipline "will not prevent Excessive Agency, but can limit the level of damage caused."³ The log tells you what the agent opened on your machine. It does not tell you which characters the vendor kept, cached, or used for training. Layer read-audit with an upstream deny-list¹⁴ and a check on your training defaults.¹⁵

Steph Ango's version is the philosophical anchor: "Apps are ephemeral, but your files have a chance to last. If you want to create digital artifacts that last, they must be files you can control, in formats that are easy to retrieve and read."²¹ The corollary is that the log of what an app read from your files is also yours to keep. The vendor's transcript will roll away when the vendor does. The plain text file the kernel wrote survives.

Your notes live on your device as plain Markdown files, so the OS can watch them and the log is a file right next to them — mnmnote.com is the same shape at the layer below.

References