Introduction
AV and EDR tools regularly flag RMM agents as Potentially Unwanted Applications (PUAs). This is expected behavior — an RMM has significant system privileges, and security vendors are right to treat unknown remote-access tools with suspicion. Since you've deployed Level intentionally, the fix is adding exclusions so your security stack allows it to run.
Why This Happens
EDRs have started classifying RMMs as Potentially Unwanted Programs (PUPs) by default. It's a reasonable security stance — RMMs provide deep system access, including remote control, background management, arbitrary script execution, and more. Any unauthorized RMM running on your network should be flagged immediately.
Level's position: EDRs should block unapproved RMMs. If you've chosen to use Level, creating an exception in your security software is the appropriate response.
For a deeper discussion on this, see: EDRs Distrust RMMs, and That's OK
How AV/EDR Actually Interferes With Level
This is important to understand, because AV/EDR interference isn't always obvious. Most people expect a quarantine event or an alert — but behavior-based detection often doesn't produce either.
Behavior-based detection is not signature-based. AV/EDR products don't just scan files; they watch what processes do at runtime. If the agent's behavior at a specific moment triggers a heuristic — a network call pattern, a WMI query, a process spawn — the security software may block or kill that action without quarantining anything. No alert, no log entry, no binary removal.
This is why you can have 50 devices running the same AV/EDR and only 2 show Level as offline. It's not inconsistent behavior from your security software — it's that the detection triggered on those 2 devices based on what the agent happened to be doing at the time.
AV/EDR can affect Level in ways beyond just removing the binary:
Kill the agent process outright (device goes offline)
Block specific outbound connections (connectivity checks fail, websocket drops)
Interfere with WMI calls (automations time out or fail partway through)
Throttle or suspend the process (device appears online but remote sessions won't connect)
Block the agent from spawning child processes (scripts fail to execute)
If something in Level is behaving strangely — not just offline devices, but intermittent automation failures, scripts that hang, remote sessions that won't establish — AV/EDR interference is a likely cause even if your security software shows nothing.
Exclusion Paths
Add these paths to your security software's exclusion or trust list:
🖥️ PLATFORM NOTE:
Windows:
C:\Program Files\Level\level.exe
C:\Program Files\Level\level.update
C:\Program Files\Level\winpty-agent.exe
C:\Program Files\Level\.level.exe.new
C:\Program Files\Level\.level.exe.old
macOS:
/Applications/Level.app/Contents/MacOS/level
Linux:
/usr/local/bin/level
💡 TIP: Use path-based exclusions on the specific executables, not the entire Level folder. Excluding the folder would also cover anything an attacker could drop there.
Certificate-Based Exclusions
Certificate-based exclusions are more resilient than path-based ones. Level ships weekly agent updates — hash-based exclusions break with every release, and path-based exclusions don't verify the binary's authenticity. Certificate exclusions survive updates automatically and only allow properly signed Level binaries to run.
ℹ️ NOTE: Not all AV/EDR products fully support certificate-based exclusions. SentinelOne, for example, doesn't honor them for interoperability exclusions. If you're not certain your product respects certificate-based rules, use path-based exclusions instead — they're broadly supported and effective.
Publisher information:
Field | Value |
Publisher | Level Software, Inc. |
Issuer | DigiCert, Inc. |
Serial |
|
SHA-1 |
|
SHA-256 |
|
To verify the certificate on the installed binary (Windows):
Navigate to
C:\Program Files\Level.Right-click
level.exeand select Properties.Click the Digital Signatures tab.
Select "Level Software, Inc." and click Details → View Certificate.
Confirm the thumbprint matches the SHA-256 value above.
ℹ️ NOTE: Always verify certificate details against values extracted directly from your installed binary. Details may vary slightly between versions.
Windows Defender Exclusions
If you're running Windows Defender, use the automation or script below to push exclusions across your devices. Both are importable directly into Level.
Import the automation (recommended for multiple devices): https://app.level.io/import/automation/Z2lkOi8vbGV2ZWwvQWxsb3dlZEltcG9ydC8xNzM
Import the script (for individual devices): https://app.level.io/import/script/Z2lkOi8vbGV2ZWwvQWxsb3dlZEltcG9ydC8xOTU
PowerShell Script - Windows Defender Exclusion (manual):
<#
This resource is provided as a convenience for Level users. We cannot
guarantee it will work in all environments. Please test before deploying
to your production environment. We welcome contributions to our community
library
Level Library
https://level.io/library
#>
# Define paths to exclude
$paths = @(
"C:\Program Files\Level\level.exe",
"C:\Program Files\Level\level.update",
"C:\Program Files\Level\winpty-agent.exe",
"C:\Program Files\Level\.level.exe.new",
"C:\Program Files\Level\.level.exe.old"
)
# Add temporary file paths
$tempInstallPath = Join-Path ([System.IO.Path]::GetTempPath()) "install_level.exe"
$tempWindowsAmd64Path = Join-Path ([System.IO.Path]::GetTempPath()) "level-windows-amd64.exe"
$paths += $tempInstallPath
$paths += $tempWindowsAmd64Path
# Add path exclusions
foreach ($path in $paths) {
Add-MpPreference -ExclusionPath $path -ErrorAction SilentlyContinue
}
# Add process name exclusion
Add-MpPreference -ExclusionProcess "level.exe" -ErrorAction SilentlyContinue
Add-MpPreference -ExclusionProcess "level.msi" -ErrorAction SilentlyContinue
Add-MpPreference -ExclusionProcess "install_level.exe" -ErrorAction SilentlyContinue
Add-MpPreference -ExclusionProcess "level-windows-amd64.exe" -ErrorAction SilentlyContinue
# Display confirmation
Write-Output "Current Exclusion Paths:"
(Get-MpPreference).ExclusionPath
Write-Output "`nCurrent Exclusion Processes:"
(Get-MpPreference).ExclusionProcess
⚠️ WARNING: If a device is already offline because the agent was quarantined or removed, you can't push this script through Level. You'll need local or out-of-band access to add exclusions first. See If Devices Are Already Offline below.
If Devices Are Already Offline
When AV/EDR blocks Level without generating an alert, the device goes dark with no obvious indication. Signs this is the cause:
Device is online and reachable by other tools, but offline in Level
Only some devices are affected, even though the same AV/EDR is deployed everywhere (this is normal — behavior-based detection is inconsistent by nature)
Automations are failing or timing out on otherwise healthy-looking devices
The
level.exebinary is missing fromC:\Program Files\Level\— Level has no mechanism to remove its own binary, so absence means AV/EDR deleted or quarantined it
To resolve: get out-of-band access to the device, add the exclusions using your security software's management console or the PowerShell script above, then verify the binary is present. If it was removed, reinstall the agent after adding exclusions.
⚠️ WARNING: Don't reinstall the agent before adding exclusions. AV/EDR will remove the binary again immediately.
FAQ
I added exclusions but the device is still offline. What now? Exclusions prevent future interference but don't undo what already happened. Check whether the
level.exebinary is still present inC:\Program Files\Level\— if it was removed by AV/EDR, you'll need to reinstall the agent. Run--checkafter reinstalling to confirm connectivity is restored. See Offline Troubleshooting.All my devices have the same AV/EDR. Why is Level only offline on a few of them? Behavior-based detection. Your security software isn't matching Level against a known-bad signature — it's watching what processes do at runtime and blocking based on behavior patterns. Whether a detection triggers depends on what the agent happened to be doing at the moment the heuristic ran. It's common to see only 1–3 devices affected out of a much larger fleet with identical AV/EDR configuration.
My EDR shows no detections or quarantine events, but Level is behaving strangely. That's consistent with behavior-based interference. Some products block or throttle specific operations without generating a detection event — no alert, no quarantine log, nothing. AV/EDR can kill websockets, block network calls, cause WMI timeouts, or prevent the agent from spawning child processes, all without touching the binary. Add exclusions and monitor whether the issues resolve.
Should I use path-based or certificate-based exclusions? Certificate-based is more secure and lower-maintenance in theory, but not all products fully honor them. SentinelOne, for example, doesn't support certificate-based exclusions for interoperability exclusions — the option exists but won't have the intended effect. If you're not certain your AV/EDR fully respects certificate-based exclusions, start with path-based. Path-based is broadly supported across all products and is the safer default. Avoid hash-based — Level ships weekly updates and the hash changes every release.
Who should I contact if my EDR vendor keeps flagging Level? Reach out to Level Support. The team works with security vendors directly on classification issues.
