Managed ITDR

Hi Huntress Team, We use Huntress heavily across our own environment and dozens of client M365/Azure tenants. I’d like to request native support for context bomb canaries. Quick basics Context bombs are short text strings planted in decoy resources (Key Vault secrets, Entra app secrets, Intune profiles, AVD env vars, etc.). When a malicious AI agent reads them, the string trips the LLM’s safety guardrails and frequently causes the agent to stop or refuse to continue. You still get the canary alert. Tracebit’s recent tests showed this cut AI agent success rates dramatically (admin access from ~57% down to 5%, full compromise from 36% to 1%). Good overview of how it works: https://www.csoonline.com/article/4198524/context-bombing-heralds-a-new-ai-era-of-deceptive-defense.html Full research + placement details: https://agentic.tracebit.com/context-bombs/ Why it matters AI agents can now escalate and persist in cloud environments in minutes. Traditional canaries only alert — context bombs both detect and actively disrupt the attack. That extra stop/slow-down is huge when the kill chain is this fast. For Azure/M365 specifically, the highest-value spots are: • Azure Key Vault secrets • Entra ID app registration secrets • Intune/AVD environment variables and configs • Other decoy secrets/docs agents tend to enumerate This would be a strong differentiator for Huntress MDR/ITDR and something we could immediately offer our clients (especially regulated ones). Would you be open to logging this as a feature request and letting me know if it’s already on the radar? Happy to jump on a quick call or share the research/links if helpful.

Add the ability to add access rules per device type. For example, we use MAM policies in Intune so users can access Outlook via personal mobiles. One user uses a personal VPN on his phone. However, he doesn't and isn't allowed to use this VPN on his work laptop. To stop Huntress from flagging the escalation of the VPN detection on his personal phone, I've had to an access rule for his whole account for the VPN he uses.

It seems that Huntress just wants this Entra Usage Location set so they can use it as a datapoint, setting it per user it tedious. MSP and IT also use JIT accounts which can create accounts on the fly. As an MSP, we are getting these alerts for every JIT account being created. For all our clients, we could simply just tell you (in settings) that USA is the only Usage Location, vs setting this on a per user basis. Above that, if there was a single user in say Japan, it would be better for us to set that usage location on their identity in Huntress, not in Entra.

Add the ability to add multiple countries when creating location rules.

We need a better alerting system, or at least some kind of notification should you suddenly not get any data from client tenants.

We can't use the new iOS app. We use Entra SSO, and we force passkeys.

Trusted device suppression would be very useful for location alerts, but I don't want to suppress alerts from unknown VPNs on managed devices. This varies from multiple clients and granular control would be an improvement.

Often the same phishing email is sent to multiple individual recipients at the same organization. Once adversary activity is detected on one account and an incident is triggered, it would be phenomenal if Huntress would proactively find and remove (soft delete automatically with an option to push a button to hard delete) these emails from all other mailboxes. It would cutdown on additional work required to secure the environment after the first user is successfully phished. MSPs and their partners would really benefit from a feature like this.

It would be great to get escalations anytime a new Global Admin is created, or an existing user is elevated to global admin, allowing us to mark these as expected or not. For orgs using PIM, while UserA may not always have GA permissions, if they often do/or can, you could add them as an expected rule. We already create a weekly report of these using Huntress SIEM, but its a bad solution for a very common issue. Seems like this could be a low lift to implement.