Managed EDR

We'd like Huntress to add the ability to deploy Microsoft Defender for Endpoint on Windows computers through the Huntress agent, then keep it running and monitor its health. Many of our clients use Google Workspace and don't want their computers joined to Entra ID or enrolled in Intune, which is normally how MDE gets deployed. The agent would handle MDE the same way Huntress Managed AV handles standard Defender today: if MDE isn't onboarded, is disabled, or stops running, Huntress would fix it automatically and report its status in the Huntress portal.

It would be great to have remote shell access to Huntress-isolated devices. This would allow us to investigate a compromise without having to remove isolation, keeping it more secure.

opt-in capability to detect and remove third-party antivirus products automatically, ideally at the account or organisation level and with safeguards to prevent Microsoft Defender from being removed. This would significantly reduce the manual effort involved in customer migrations, help clear persistent antivirus remnants, and improve endpoint health and compliance reporting.

It would be helpful if Huntress had a way to prevent isolated devices from going to sleep--especially if plugged in. It can be difficult to coordinate with end users to keep laptops active while we investigate an issue.

For cloud-hosted RMMs, only being able to allow by static IP limits our ability to use the RMM during host isolation. Allowing FQDN allowlisting would let cloud-based RMMs connect to an isolated agent to remediate issues.

Employees are using OpenAI ChatGPT, Anthropic Claude, OpenClaw, browser copilots, AI extensions, personal API keys, and many other tools..... often without IT visibility. Our IT departaments need What AI tools are being used What data is being uploaded or pasted If sensitive information is leaving the company Which tools are approved vs shadow AI How to manage risk without killing productivity Many companies are blind here are risk is very high. Traditional firewalls and DNS filters are not enough. In February during The Product Lab, they mentioned the idea of an AI Scraper to detect AI tool usage, APIs, exfiltration risks, and user activity. Two months later, that idea already feels necessary.

Managed antivirus (Defender) policy settings can currently only be changed individually per agent in the GUI – this is not possible via the API. It is not possible to select multiple agents (or an entire group) and adjust Defender policy settings together. Use Cases: Onboarding: newly set up servers require the correct Defender policy Environment-specific settings (e.g., exclusions on test VMs, restrictive in Prod) Audit/Remediation: Apply a policy change to hundreds of agents without clicking through them individually Suggestion: GUI: Select multiple agents (or filter by group/day) → Edit Managed Antivirus Policy API: Endpoint to update Defender/AV policy settings for a list of agent IDs (or as a account-wide default policy) Sub-Organization groups (feature idea): Allow sub-groups within existing organizations. New agents assigned to a sub-group automatically inherit the correct policy – no manual individual work is required for newly added agents.

Huntress now supports an IP address allow list for isolated hosts, but this doesn't work with Cloud RMM, AV, or other tooling which typically uses dynamic IP addresses for agent connectivity. Vote here if you'd like to see this capability added. Even better, it would be great to hear what specific tools you'd want to use it with; the list of DNS names that need allowing for typical cloud tooling is long, and we could potentially preconfigure them (just check a box) for common-needed tools.

We recently had an incident where Huntress detected a malicious ScreenConnect installation and successfully initiated remediation. While the report identified the malicious ScreenConnect instance, it did not show whether anyone actually connected through it, when those connections occurred, or who initiated them. ScreenConnect connection and disconnection events are typically available in Windows Event Viewer under Windows Logs → Application, depending on the installed version and logging configuration. It would be extremely valuable if Huntress could automatically collect these records, including timestamps, type of connections, commands ran etc. This should also include historical connection records, particularly when Huntress is newly deployed to an endpoint. A malicious remote-access tool may have been installed and used long before Huntress was deployed, and reviewing past connections could help establish the timeline and extent of a compromise. In this case, I received the incident report and wanted to investigate further, but the device had already been offline for several hours, preventing me from accessing its local logs. Having Huntress automatically collect and preserve available historical and current session records during an investigation, ideally before remediation, would help MSPs determine the extent of unauthorized access without depending on the endpoint remaining online. This would be particularly valuable when investigating malicious remote-access tools, where identifying actual remote sessions is just as important as detecting the installation itself.