Forcepoint DLP Endpoint Agent High CPU: Why Policy Complexity and Deep Inspection Drive the Spikes
Reach 50,000+ security professionals
Sponsor a newsletter slot and put your brand in front of CISOs, engineers, and IT decision-makers.
Forcepoint DLP endpoint agents work by intercepting file system operations at the kernel level and evaluating each intercepted operation against active policy rules. This architecture makes the agent highly effective at catching data exfiltration attempts in real time, but it also means that every file write, copy, print, and email attachment triggers policy evaluation. When policy rule count is high or content inspection runs on high-frequency paths, the CPU cost of that evaluation accumulates. For DLP product selection context including how Forcepoint compares to alternatives, see this Microsoft Purview vs Nightfall vs Concentric AI DLP comparison.
Root Causes: Why DLP Endpoint CPU Spikes
Cause 1: Excessive policy rule count with compound conditions. Each active DLP policy rule is evaluated against each intercepted file operation. A deployment with 150+ active rules, many with multiple AND/OR conditions and content inspection requirements, multiplies the CPU cost per file operation. Administrators often add rules iteratively without retiring older rules, leading to rule sprawl that the endpoint evaluates even when only 10-15 rules are practically relevant for a given endpoint role.
Cause 2: Deep content inspection on high-frequency paths. Content inspection (reading and classifying file content against data patterns) is significantly more CPU-intensive than metadata inspection. When content inspection policies are scoped to include temp directories (%TEMP%, C:\Windows\Temp, build output directories), the agent reads and classifies thousands of files per hour that have no data protection value. This is the most common cause of CPU spikes on developer workstations.
Cause 3: Discovery scan running during business hours. Forcepoint DLP's endpoint discovery feature scans existing files for policy violations. If discovery scans are configured to run during business hours rather than off-hours, they compete with real-time monitoring for CPU time and disk I/O, producing sustained high CPU for hours.
Cause 4: File system filter driver conflicts. Forcepoint's FSAgent operates as a Windows file system minifilter driver. Other endpoint security products (antivirus, EDR agents, backup clients) also run as minifilter drivers. Driver load order and I/O request packet (IRP) stacking conflicts between multiple minifilters can produce CPU overhead beyond what any individual driver consumes alone.
Cause 5: Post-upgrade policy re-compilation. After a Forcepoint DLP agent upgrade, policies are re-compiled at the endpoint. This compilation process runs at elevated CPU for 15-60 minutes after installation. CPU that appears as a post-upgrade regression is often this compilation completing.
Diagnostics: Identifying the Specific Cause
Step 1: Correlate CPU spike timing with agent activity.
Open Task Manager and confirm Forcepoint's FSAgent.exe or Websense Endpoint process is the CPU consumer. Then check timing:
- Is CPU high all the time, or does it spike during file-intensive operations (saving large files, build operations, email attachment)?
- Is CPU high during a specific hour each day (suggesting a scheduled discovery scan)?
- Did CPU become high after an agent upgrade (suggesting policy re-compilation or a new policy that covers more paths)?
Step 2: Check the endpoint agent log for inspection events.
Forcepoint DLP endpoint logs are located at %ProgramData%\Websense\websense\logs\ on Windows. The endpoint.log file records policy evaluation events. During a CPU spike, check whether the log shows a high rate of ContentInspection events or PolicyEvaluation events against specific file paths.
Step 3: Identify high-inspection-rate paths in the policy console.
In the Forcepoint DLP management console (Security Manager), review the policy rules assigned to the affected endpoint or endpoint group. For each rule with content inspection enabled, check the path scope. Rules scoped to monitor %TEMP% or broad path wildcards (C:\\*) generate orders of magnitude more inspections than rules scoped to %USERPROFILE%\Documents or specific application paths.
Step 4: Check discovery scan schedules.
In the management console, go to Policy Management > Discovery. Review the scan schedule assigned to affected endpoints. If scans run during business hours, reschedule to off-hours (02:00-05:00) and confirm whether business-hour CPU drops after the schedule change.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Fixes: Configuration Changes That Reduce CPU Without Gaps
Fix 1: Exclude high-frequency low-value paths from content inspection.
Add path exclusions for directories that generate high-frequency file operations with no data protection value:
%TEMP%and%TMP%(Windows temp)%LOCALAPPDATA%\Temp- Build output directories (
bin\,obj\,dist\,node_modules\) - Application cache directories (
%APPDATA%\*\Cache\) - Browser cache directories
In the management console, path exclusions are configured in the endpoint policy's Scope settings. These exclusions reduce the number of files the agent submits for content inspection without reducing protection for documents, email attachments, or USB transfers.
Fix 2: Reduce active policy rule count by retiring redundant rules.
Audit the active policy rules assigned to affected endpoint groups:
- Identify rules that have not generated any violations in the past 90 days (use the Forcepoint DLP incident reports for this count).
- For rules with compound conditions (3+ AND conditions), verify whether simpler versions of the rule would still catch genuine violations.
- Consolidate rules that test for the same data classification type but were created separately over time.
Reducing from 150+ rules to 50-60 well-scoped rules can cut per-operation evaluation overhead by 50-70%.
Fix 3: Move discovery scans to off-hours.
In Policy Management > Discovery, reschedule any discovery scans assigned to affected endpoints to a 2-6 hour window between midnight and 06:00. Set a CPU throttle limit if available in your Forcepoint version -- some versions support a maximum CPU percentage for discovery scans.
Fix 4: Adjust filter driver load order.
If multiple minifilter drivers are present (antivirus, EDR, Forcepoint FSAgent), review the driver load order using the Microsoft Sysinternals fltmc.exe tool:
fltmc.exe instances
Forcepoint's FSAgent should not be the last driver in the stack on write operations -- if it is, it receives IRPs after every other driver has processed them, adding latency that accumulates during high-write periods. Contact Forcepoint support to adjust the filter driver altitude if conflicts are confirmed.
Validating the Fix Without Creating Coverage Gaps
Validate using the Forcepoint DLP incident report.
After applying path exclusions or rule count reductions, run the DLP incident report for the affected endpoint group for 2 weeks and compare the incident count before and after. The incident rate should be unchanged or higher (the same violations detected on a lower-noise policy are easier to find). If the incident rate drops significantly and you cannot explain why, the exclusion may have been too broad.
Validate CPU reduction using Performance Monitor.
Capture FSAgent.exe CPU usage in Windows Performance Monitor (perfmon.exe) over a 2-hour period during a typical workday, before and after the configuration change. The graph should show a materially lower average and peak CPU for FSAgent.exe without changing the overall pattern (spikes are still expected during file-intensive operations like large email attachments).
Confirm policy evaluation is still active.
Test a sample violation: create a test file containing a known PII pattern (use fake data: a string that matches the SSN pattern like 123-45-6789) and attempt to copy it to a USB drive or upload it to a monitored cloud destination. The DLP incident report should capture the test violation within 1-2 minutes if real-time monitoring is active.
Known Edge Cases
Developer workstations with IDEs. Visual Studio, IntelliJ, and similar IDEs write thousands of files per minute during builds (compiled classes, incremental outputs, test artifacts). Path exclusions for build directories are essential on developer endpoints -- without them, the DLP agent inspects build artifacts that have no policy-violation risk and consume disproportionate CPU.
Encrypted file containers. Some data classification rules are designed to detect sensitive content inside encrypted containers (password-protected ZIP files, encrypted archives). Container decryption and inspection is orders of magnitude more CPU-intensive than plain-file inspection. If rules require container inspection, scope them narrowly by file extension and path.
Anti-tamper conflicts. Some EDR products (CrowdStrike, SentinelOne) include anti-tamper mechanisms that monitor or restrict process activities. In rare cases, the EDR's anti-tamper feature will cause repeated re-evaluation of the DLP agent's file operations, compounding CPU load. Contact both vendors' support if this conflict is suspected.
When to Open a Forcepoint Support Case
Open a Forcepoint Support case when:
- CPU is high on a single endpoint but not on similar endpoints with the same policy, suggesting a machine-specific issue (driver conflict, corrupted agent state).
- CPU does not decrease after path exclusions and rule count reduction.
- The
FSAgent.exeprocess is consuming CPU but no content inspection events appear in the endpoint log during the spike. - A recent agent upgrade produced CPU issues that were not present on the previous version.
For a support case, provide: the agent version, OS version and patch level, the output of fltmc.exe instances, the endpoint log from a CPU spike period, and the results of a process monitor capture showing what file operations FSAgent.exe is processing during the spike.
The bottom line
Forcepoint DLP endpoint high CPU is almost always a configuration problem rather than a software defect: too many policy rules evaluated per file operation, content inspection running on high-frequency low-value paths like temp directories, or a discovery scan scheduled during business hours. The fix -- path exclusions for temp and build directories, retiring redundant rules, and moving discovery scans to off-hours -- reduces CPU overhead by 50-70% in typical deployments without reducing data protection coverage. Validate the fix using incident report counts before and after to confirm coverage is maintained. For CASB deployments that complement endpoint DLP with cloud-based controls, see this CASB deployment guide for Netskope vs Microsoft Defender for Cloud Apps.
Frequently asked questions
What causes Forcepoint DLP endpoint agent high CPU usage?
Forcepoint DLP endpoint high CPU is most commonly caused by policy rule sprawl (too many active rules evaluated per file operation), deep content inspection running on high-frequency paths like temp directories or build output directories, a discovery scan scheduled during business hours that competes with real-time monitoring, or file system filter driver conflicts with other endpoint security products. The agent's CPU cost scales directly with the number of file operations monitored multiplied by the number of policy rules and inspection depth applied to each operation.
How do I reduce Forcepoint DLP endpoint CPU without disabling data protection?
Add path exclusions for high-frequency low-value directories: Windows temp directories, application cache directories, browser cache, and build output directories like bin, obj, and dist. These paths generate thousands of file operations per hour with no data protection value. Next, audit your active policy rules and retire any that have not generated violations in the past 90 days. Finally, reschedule discovery scans to run between midnight and 06:00 instead of during business hours. These changes typically reduce endpoint CPU by 50-70% without changing the incident detection rate.
How do I find which path is causing Forcepoint DLP high CPU?
Check the Forcepoint DLP endpoint log at %ProgramData%\Websense\websense\logs\endpoint.log during a CPU spike. The log records ContentInspection and PolicyEvaluation events with the file path being inspected. A path that appears hundreds of times per minute in the log is the source of excessive evaluation. Cross-reference this with your policy scope settings in the Forcepoint management console and add a path exclusion for the high-frequency directory.
Why did Forcepoint DLP endpoint CPU spike after an agent upgrade?
After a Forcepoint DLP agent upgrade, the endpoint performs a policy re-compilation step that runs at elevated CPU for 15-60 minutes. This is expected and resolves once compilation completes. If CPU remains high more than 2 hours after upgrade completion, the upgrade may have deployed a new policy version with broader scope or more content inspection rules than the previous version. Compare the active policy rules and path scopes before and after the upgrade using the management console's policy version history.
What is the Forcepoint FSAgent and why does it use high CPU?
FSAgent (File System Agent) is Forcepoint DLP's Windows kernel-mode file system minifilter driver. It intercepts file system operations (read, write, copy, rename) in real time and routes them through the DLP policy engine for classification and enforcement. CPU usage is proportional to the volume of intercepted operations and the complexity of the policy evaluation applied to each. FSAgent operates at the kernel level alongside other minifilter drivers (antivirus, EDR), and the interaction between multiple drivers processing the same I/O request packet can compound CPU overhead beyond what any single driver would use alone.
How do I validate that Forcepoint DLP is still protecting data after reducing CPU overhead?
Create a test file containing a known data pattern that your DLP policy is designed to detect -- use fake PII that matches your policy's classification rules (for example, a string formatted as an SSN but containing obviously fake numbers). Attempt to copy the test file to a monitored destination: a USB drive, a cloud storage upload, or an email attachment. Confirm that the Forcepoint DLP incident report captures the test violation within 1-2 minutes. If the violation is detected, real-time monitoring is active. Additionally, compare the incident rate in your DLP incident reports before and after the configuration change over a 2-week period -- the rate should be stable or higher.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Daily briefings + Google Top Stories in one step.
Enter your email and we'll subscribe you to the daily briefing and add Decryption Digest to your Google Search feed at the same time.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.