AI coding agents have become a standard part of the development workflow. Tools like GitHub Copilot integrate directly into your editor and can read files, run terminal commands, and interact with your file system on your behalf. They run in your user context, which for most developers means they can read almost anything you can.

That is useful when you ask the agent to fix a failing test or refactor a function. It gets more interesting when you stop to ask who else might be able to influence what it reads, and what it does with whatever it finds.

Most software runs in your user context too, but its behavior is predictable. A calculator does arithmetic. An AI coding agent runs with the same privileges but with no fixed scope: the next action depends on the prompt.

The test

To see what that looks like in practice, I set up a simple test on my own machine: a file called secret sitting outside any project folder, and a normal Copilot chat session in VS Code. The question was straightforward. What, if anything, stops the agent from reading it, and what do I see when it does?

Before doing anything, I asked Copilot directly what would stop it from reading a file outside the project. Its own answer is the most useful framing for this whole post:

That confirmation prompt is worth pausing on. To VS Code's credit, when Copilot tried to access a file outside the workspace folder, the editor asked permission first. The dialog clearly named the file (secret) and the directory it was in (Videos), with an Allow Once button and a Skip option. This is a real guardrail, and most users will see it before any out-of-workspace read happens.

I clicked Allow Once. The read proceeded immediately:

So far, this is the system working as designed. The user asked, the editor confirmed, the user approved, the agent read the file. Where it gets interesting is in the cases where that confirmation step does not save you.

The Allow prompt protects you from one thing: an AI that wanders off on its own. It does not protect you when the request looks reasonable. If you are debugging something and the agent asks to read a file you do not recognise, most people will click Allow. That moment is also when an injected instruction would take effect, and you would not know. The prompt only works if you read every dialog carefully, every time, for hours. Most people don't.

It also assumes the prompt is shown at all. The same dialog has an option to approve the action for the rest of the session. Once you click that, future reads in the same location happen silently. Copilot also lets you change the approval mode at the top level:

Bypass Approvals reduces the per-tool-call confirmation step. Whether it also turns off the out-of-workspace warning depends on configuration. Either way, the pattern is clear: every option above the default trades a guardrail for less friction. None of these are exotic settings. They exist because the prompts get in the way during long tasks, and people turn them off. The further you move from the default, the less the chat UI tells you what is actually happening.

And Copilot is one of the better cases. Other AI coding tools offer weaker guardrails, or none at all. Whether your tool asks before reading a file depends on how that tool was built. If your monitoring strategy depends on an in-app prompt, you are assuming the prompt exists, that it is on, and that the user reads and rejects every dubious one. None of those are safe assumptions.

What the chat UI shows you

VS Code makes tool calls visible in the conversation. When the agent read the file, the invocation and its parameters were displayed inline. This is genuine transparency about what the tool layer did, and the Allow prompt adds an explicit consent step on top of that.

The limitation is that the chat interface only shows what the tool layer reports about itself, and the consent prompt only protects against actions the user notices and rejects. In a prompt injection scenario, the chat log would show the read, but the user may have already clicked Allow because it looked relevant to the task. The chat UI is useful, but it is not an independent audit trail.

What ZeroExfil saw

For context, ZeroExfil is an endpoint agent that observes file activity at the kernel level. It captures reads, writes, renames, and deletes on the system, along with the process and account responsible. It runs independently of the applications it observes, so its view does not depend on what those applications choose to report.

The same file read that appeared in the Copilot chat also produced an event in ZeroExfil's telemetry:

The event captures the full picture: the exact file path, the process responsible (Code.exe), the account context, and the exact number of bytes transferred. The file contains 20 bytes, and ZeroExfil reported 20 bytes transferred. The read left a verifiable trace that is entirely independent of what the chat interface reported.

Why this is worth paying attention to

The scenario above was deliberate: I asked, I confirmed, I saw the result. The real risk is not an AI honestly reading a file you asked it to read. It is an AI being manipulated into reading files it should not.

Prompt injection, briefly

Prompt injection is a known attack class against AI systems. An attacker hides instructions inside content the AI is asked to process: a source file, a code comment, a document being summarised. Those instructions redirect the agent. It might be told to read credential files, private keys, or browser data, and put the contents in its response. From there, the data flows out through the chat interface or whatever API is consuming the output.

The AI is not deceiving you. It is doing what its tools allow, based on instructions it found in the content. The gap is that you did not write those instructions.

Why it matters on a developer machine

VS Code Copilot, Cursor, and similar tools are used in environments where API keys, database credentials, and certificate stores sit on the same machine as the development workspace. The attack surface is real, not theoretical.

It has already happened in the wild

GitHub's own security team documented this in a 2025 write-up on safeguarding VS Code against prompt injections. They describe several bypasses where an instruction hidden inside a public GitHub Issue caused Copilot to read a local credential file and exfiltrate the token to an attacker-controlled server. No confirmation prompt was shown. A separate bypass used the agent's file editing tool to overwrite settings.json, which led to arbitrary command execution.

Those specific issues have since been fixed. The underlying point holds: the consent layer lives inside the same tool that is being attacked. When that layer is bypassed, you only know about it if something independent was also watching.

What to look for

If you are thinking about this from a monitoring perspective, the process of interest is Code.exe for VS Code-based agents, with equivalents for other editors. AI agents do not just read. They also write generated code, rename during refactors, and delete temporary files. The full lifecycle matters. Useful questions to ask of your telemetry:

• Is Code.exe reading or writing files outside the active workspace folder?
• Is it accessing credential stores, private key directories, or .env files?
• Are there reads, renames, or deletes against paths under %APPDATA%, %USERPROFILE%, or network shares that have no obvious relation to the current project?
• Is there a pattern of reads followed by outbound network activity from the same process?

None of those patterns are individually definitive. They are starting points for investigation. What matters is having the events in the first place, across the full lifecycle, with enough detail to make the investigation possible.

What ZeroExfil gives you here

The event above came from ZeroExfil's kernel-level monitoring. It surfaced the read, attributed it to the correct process, and recorded the bytes transferred, regardless of whether the AI's chat interface confirmed it or not. The read happened to be the interesting event in this test, but the same telemetry covers writes, renames, and deletes. That is the same property that made it useful in the previous post on Defender telemetry gaps: the full lifecycle of a file surfaces at the kernel, not just at the tool layer.

For AI tools specifically, this gives you a way to answer the question independently: what did Code.exe actually do to your files during this session, and against which paths? That answer comes from the OS, not from the AI.

Final thought

This is not an argument against using AI coding agents. They are genuinely useful, and broad file access is part of what makes them capable. It is an argument for having visibility into what that access looks like in practice.

If your AI agent read a file outside your project today, would you know? Would you have a record of which file, how many bytes, and which process was responsible?

With ZeroExfil, the answer is yes.

Microsoft Defender is a solution I have spent countless hours working with. It is powerful and highly capable, but like any system operating at fleet scale, it is built around trade-offs. Not all events can be captured or retained equally.

That is not a criticism. Every large-scale security platform makes similar decisions. Understanding where those trade-offs live is what matters.

If you do not understand the limits of your visibility, you do not understand the limits of your security.

The DeviceFileEvents table

Within the Microsoft security stack, the DeviceFileEvents table is commonly used during investigations. The official documentation describes it as containing:

"information about file creation, modification, and other file system events."

At a high level, file system activity can be broken down into:

• File access (open)
• File reads (data being viewed or copied)
• File changes (writes and modifications)
• File renames or moves
• File deletions
• Folder browsing (discovery)

Where the documentation gets quiet

The documentation explicitly references file creation and modification. It is less explicit about two things that matter for exfiltration detection:

• Which action types are captured (reads, deletes, renames) and which are not
• Which file extensions produce events and which are silently dropped

That raises a useful question.

To what extent does the available telemetry represent the full lifecycle of file activity?

A small experiment

To explore this, I ran a simple test on a managed endpoint enrolled in Microsoft Defender for Endpoint.

Setup

• 100 files created on the system in a single directory.
• 20 files using common extensions (documents, images, scripts).
• 80 files using higher-value extensions (databases, backups, archives, configuration files, key material).
• Each file held 50 bytes of data.
• After a 60 second pause, every file was read sequentially, then moved into a staging subfolder, then deleted.
• Every file system operation was timestamped and logged locally so the test output could be compared against the telemetry surfaced in DeviceFileEvents.

The intent was to mirror the kind of access pattern that a collection or staging step might produce, while exercising the four operation types most relevant to exfiltration: create, read, move, and delete. The full PowerShell used to generate the workload:

# -------------------------------
# File Operation Logging Experiment
# -------------------------------
# Creates 100 files (20 common + 80 high-value extensions),
# then runs four phases: CREATE, READ, MOVE, DELETE.
# Every operation is timestamped to stdout so the local log
# can be diffed against EDR / DeviceFileEvents telemetry.

$commonExtensions = @(
    "txt","log","csv","json","xml",
    "html","js","css","pdf","docx",
    "xlsx","pptx","png","jpg","gif",
    "mp3","mp4","zip","ps1","bat"
)  # 20 entries

$importantExtensions = @(
    "db","sqlite","sqlite3","mdb","accdb",
    "bak","backup","dump","dmp","sql",
    "ldf","mdf","ndf","dbf","frm",
    "ibd","myd","myi","ora","rdb",
    "pst","ost","eml","msg","mbox",
    "kdbx","pfx","pem","key","crt",
    "cer","der","csr","pub","ppk",
    "env","config","conf","ini","yaml",
    "yml","toml","properties","reg","dat",
    "bin","blob","cache","tmp","temp",
    "tar","gz","bz2","7z","rar",
    "iso","img","vhd","vhdx","qcow2",
    "parquet","avro","orc","feather","h5",
    "sav","dta","rdata","mat","npy",
    "pickle","joblib","pt","pth","ckpt",
    "vmdk","ova","p12","jks","ovpn"
)  # 80 entries

$totalFiles = 100
$dir = "$PWD\file-ops-experiment"
$stagingDir = Join-Path $dir "staging"

if (($commonExtensions.Count + $importantExtensions.Count) -lt $totalFiles) {
    throw "Not enough extensions defined to reach $totalFiles files."
}

New-Item -ItemType Directory -Path $dir -Force | Out-Null

$content = [byte[]](1..50)

function Log($msg) {
    $ts = Get-Date -Format "yyyy-MM-dd HH:mm:ss.fff"
    Write-Host "[$ts] $msg"
}

Log "Creating $totalFiles files"

# Create common files (20)
for ($i = 0; $i -lt $commonExtensions.Count; $i++) {
    $filename = "$($i + 1).$($commonExtensions[$i])"
    $filepath = Join-Path $dir $filename
    [System.IO.File]::WriteAllBytes($filepath, $content)
    Log "CREATE $filename"
}

# Create remaining files (to reach 100 total)
$remaining = $totalFiles - $commonExtensions.Count

for ($i = 0; $i -lt $remaining; $i++) {
    $index = $i + $commonExtensions.Count + 1
    $filename = "$index.$($importantExtensions[$i])"
    $filepath = Join-Path $dir $filename
    [System.IO.File]::WriteAllBytes($filepath, $content)
    Log "CREATE $filename"
}

Log "Sleeping 60 seconds before read phase"
Start-Sleep -Seconds 60

# Read phase
Log "Starting READ phase"
foreach ($file in Get-ChildItem -Path $dir -File) {
    try {
        [void][System.IO.File]::ReadAllBytes($file.FullName)
        Log "READ $($file.Name)"
    }
    catch {
        Log "READ_FAIL $($file.Name)"
    }
}

# Move phase
Log "Creating staging folder"
New-Item -ItemType Directory -Path $stagingDir -Force | Out-Null

Log "Starting MOVE phase"
Get-ChildItem -Path $dir -File | ForEach-Object {
    Move-Item $_.FullName -Destination $stagingDir -Force
    Log "MOVE $($_.Name)"
}

# Delete phase
Log "Starting DELETE phase"
Get-ChildItem -Path $stagingDir -File | ForEach-Object {
    Remove-Item $_.FullName -Force
    Log "DELETE $($_.Name)"
}

Log "Experiment complete"

What I observed

Pulling the events for the experiment folder out of DeviceFileEvents:

DeviceFileEvents
| where FolderPath contains @"C:\Users\VictorOlsson\Documents\file-ops-experiment"

And the distinct list of extensions that surfaced at all, across any action type:

DeviceFileEvents
| where FolderPath contains @"C:\Users\VictorOlsson\Documents\file-ops-experiment"
| extend FileExtension = extract("\\.([0-9A-Za-z]+)(?:[\\?#]|$)", 1, FileName)
| distinct FileExtension

Two observations stand out. First, only two action types surfaced: file creation from the create phase, and file rename from the move phase. A same-volume move is implemented as a rename at the kernel level, so both Microsoft Defender and ZeroExfil report the staging step as a rename rather than a separate move event. The read phase and the delete phase produced nothing in DeviceFileEvents, even though every ReadAllBytes and every Remove-Item ran. Second, the create and rename events that did surface only covered a subset of the file types. The same 31 extensions showed up across both phases, and the remaining 69 were silent.

Per-extension result for all 100 files

#	Extension	Logged
1	txt	No
2	log	No
3	csv	Yes
4	json	No
5	xml	No
6	html	Yes
7	js	No
8	css	Yes
9	pdf	Yes
10	docx	Yes
11	xlsx	No
12	pptx	Yes
13	png	No
14	jpg	No
15	gif	Yes
16	mp3	No
17	mp4	No
18	zip	Yes
19	ps1	Yes
20	bat	Yes
21	db	No
22	sqlite	Yes
23	sqlite3	No
24	mdb	No
25	accdb	No
26	bak	No
27	backup	No
28	dump	No
29	dmp	Yes
30	sql	No
31	ldf	No
32	mdf	Yes
33	ndf	No
34	dbf	No
35	frm	No
36	ibd	No
37	myd	No
38	myi	No
39	ora	No
40	rdb	No
41	pst	No
42	ost	No
43	eml	Yes
44	msg	No
45	mbox	No
46	kdbx	No
47	pfx	Yes
48	pem	Yes
49	key	Yes
50	crt	Yes
51	cer	Yes
52	der	Yes
53	csr	No
54	pub	No
55	ppk	No
56	env	No
57	config	Yes
58	conf	No
59	ini	No
60	yaml	No
61	yml	No
62	toml	No
63	properties	No
64	reg	Yes
65	dat	No
66	bin	No
67	blob	No
68	cache	No
69	tmp	No
70	temp	No
71	tar	Yes
72	gz	Yes
73	bz2	Yes
74	7z	Yes
75	rar	Yes
76	iso	Yes
77	img	Yes
78	vhd	No
79	vhdx	No
80	qcow2	Yes
81	parquet	No
82	avro	No
83	orc	No
84	feather	No
85	h5	No
86	sav	No
87	dta	No
88	rdata	No
89	mat	No
90	npy	No
91	pickle	No
92	joblib	No
93	pt	No
94	pth	No
95	ckpt	No
96	vmdk	No
97	ova	No
98	p12	Yes
99	jks	No
100	ovpn	No

The same run, seen by ZeroExfil

The machine was also running ZeroExfil, so I queried the same folder in our hunting interface:

where filePath contains "file-ops-experiment"

ZeroExfil surfaced all four action types from the script, from the same powershell_ise.exe process tree:

Each file is exactly 50 bytes, so the full write phase should account for 5000 bytes across 100 files. ZeroExfil reported 4850 bytes across 97 files. The read, rename, and delete phases also surfaced 97 of 100 files. Diffing the captured paths against the script's file list, the same three files dropped out of every phase: 68.cache, 69.tmp, and 70.temp. These extensions are deliberately excluded in the collection pipeline to reduce noise from temporary and cache files. The shape of the result is still markedly different from MDE: every phase produced events, every event carried the full file path, and the totals add up to within a few percent of the work the script actually did.

Side by side, on the same machine and the same run:

The difference matters for exfiltration specifically, because exfiltration rarely requires modifying a file. If reads and moves are silent, the sequence that matters most is the one you never see.

What to do with this

The takeaway is not that one tool is better than another. It is that the shape of your telemetry decides which questions you can answer. If your investigations rely on DeviceFileEvents, it is worth running a similar test in your own environment, mapping which extensions and action types actually surface, and being explicit about the gap between what you can see and what you assume you can see.

Final thought

I hope this gives a useful starting point. If you run a similar experiment in your own environment and get different numbers, I would genuinely like to hear about it. The more data points we have on what surfaces and what does not, the better the community can reason about detection coverage.

If nothing else, check whether your telemetry covers the file operations that matter most to you. Knowing where the gaps are is half the work.