Build servers and CI machines run the office AV policy and builds are 3x slower than on a comparable dev laptop.

A build runner is functionally a server. Same policy as laptops gives it unnecessary scan work on short-lived files. A separate, narrowly scoped policy is defensible if documented.

Try this first

1. 1In your AV console (Defender, Sentinel, CrowdStrike) create a separate policy for build machines. Put them in their own device group so the production policy stays untouched.
2. 2Exclude the build workspace and cache folders: typically 'C:\agent\_work', '%LOCALAPPDATA%\Pip\Cache', '%LOCALAPPDATA%\NuGet\v3-cache', npm/yarn caches.
3. 3Add process exclusions for compilers and runners: 'msbuild.exe', 'dotnet.exe', 'node.exe', 'go.exe', 'java.exe'. Narrower than paths, prefer where possible.
4. 4Schedule a weekly full scan in a quiet window and keep real-time scanning on for everything outside build paths. You don't lose detection on incoming artifacts.
5. 5Measure the delta: run the same build before and after the policy change and log the time. Concrete numbers help during security review.
6. 6Put a review date on the calendar, say every 6 months. Build tooling changes and exclusions otherwise live forever.

None of the above fits?

Describe your situation below. We pass your input plus the steps you already saw to our AI and return tailored next-step advice. If it's too risky to DIY, we'll say so.