Podcast Cleaning up the internet, upstream: what web hosts can learn from Monarx’ CTO By MailChannels | 9 minute read In enterprise security, a false positive is annoying. A user calls support and asks why a file was quarantined. Someone investigates, restores it, and the business moves on. In hosting and multi-tenant infrastructure, the same mistake can take down an ecosystem. On the MailChannels Podcast, Rob Seger (CTO at Monarx) describes a reality that every platform operator eventually learns the hard way: in shared environments, the blast radius of a bad decision is huge. One misclassification can disrupt email, web traffic, or application workflows for hundreds or thousands of downstream customers. This episode is a useful blueprint for how security teams should think about abuse prevention, malware cleanup, and reliability at scale, especially when you do not control what your customers run. Listen to the full episode here: The core problem: multi-tenant security has a different failure mode Rob frames the difference clearly: Enterprises can tolerate some friction when a tool blocks the wrong thing. Hosting providers and platforms cannot. The “cost” of a false positive is measured in customer outages. That is the part most security narratives miss. Security teams often focus on catching more badness. Platform operators need to focus on catching badness without breaking legitimate traffic and legitimate code paths. That tradeoff is not theoretical. For MailChannels customers, a wrong decision can impact transactional email delivery across many tenants. For Monarx customers, a wrong decision can break websites at scale. Both companies sit in the same category of infrastructure security where reliability is part of the security promise. “Attackers always win” is not a slogan. It is an economic model Rob’s career path helps explain why this matters. He started in offensive security, then moved into defensive work and learned a lesson that many teams only learn after painful incidents: Attackers have unlimited options. Defenders do not. Defenders have to cover every path. Attackers only need one path. That asymmetry forces a different objective. You are not trying to “never lose.” You are trying to reduce the consequences when something slips through. Rob calls that out directly: the goal is mitigating blast radius. For platforms, blast radius is not just “how many servers” or “how many IPs.” It is how many customers lose core functionality when an enforcement decision is too blunt. What blast radius looks like in email Email filtering has the same dynamic. If a provider reacts to abuse by hard suspending an entire account or shutting off an API key, the platform can accidentally knock out password resets, receipts, alerts, and other business-critical transactional messages for legitimate tenants. That is why proportional enforcement matters. The closer you can get to tenant-level or sender-level reputation and controls, the more you can contain abuse without creating a customer outage. Why hosting is where so many attacks start Rob makes a point that is obvious once you see it: most attacks originate somewhere in the cloud, and a large share of that cloud is hosting provider infrastructure. Security vendors often focus on enterprise perimeters, endpoints, and SaaS. Meanwhile, compromised shared servers and vulnerable web stacks keep fueling malware, phishing kits, miners, and spam. This is why cleaning up matters even if it feels upstream and thankless. If you remove phishing kits from servers, victims click links and get a 404 instead of a credential-harvesting page. That is real harm reduction, even if nobody sends you a thank you note. How Monarx approaches the hosting malware problem Monarx’s bread and butter is identifying and cleaning malware living on hosting servers. They encourage providers to install their agent on shared servers because the baseline reality is harsh. Rob claims that on many shared systems, “one in three of your users are popped,” meaning compromised in some way. That is not an enterprise style sales motion where you hope to find one suspicious file to justify a purchase. In hosting, you can land on a test box and immediately find massive volume. The challenge is not proving malware exists. The challenge is acting safely at scale. PHP makes the problem harder The episode gets technical in a way that matters for operators. PHP is flexible, dynamic, and extremely common in hosting because of WordPress and the broader ecosystem. That flexibility also makes it easy to do shady things that still execute. Simple blocking patterns like “never allow exec” are not enough, because attackers and sloppy code can bypass naive rules. Monarx addresses this by working inside the PHP engine. They use a Zend extension and load as a shared library so they can observe and control execution paths in a way that plugins cannot. A plugin runs on the same playing field as an attacker. A shared library that effectively changes how PHP behaves is harder to evade. This is the kind of engineering you end up doing when the environment is hostile and you cannot assume developers wrote defensively. Defense in depth is unavoidable Rob also points out a reality that applies to email as much as it does to web stacks: there are cases where abuse uses legitimate code paths. In hosting, that can mean a poorly designed PHP endpoint that allows sending arbitrary email headers or content through a normal mail function. In those cases, malware cleanup alone does not solve the whole problem, because nothing malicious is running. The system is behaving as designed, just designed badly. In email, that is the equivalent of legitimate SMTP traffic that still carries abusive content. You cannot solve everything at one layer. You need multiple layers, each doing the work it is best positioned to do. Why “fancy AI” is often the wrong tool in infrastructure security There is a section in this conversation that every buyer evaluating security tooling should internalize. Rob is blunt: you cannot throw a large language model at the problem when you have strict latency and cost constraints. Even if a large model could classify perfectly, it is too slow and too expensive for high-throughput, real-time decisioning at hosting scale. Instead, Monarx leans on symbolic AI, effectively expert systems, because they are fast, cheap, and easy to update frequently. The expensive part is transforming raw inputs into a representation the expert system can evaluate efficiently. That pattern matches what many high-scale abuse prevention systems discover: Most wins come from good feature extraction, instrumentation, and data pipelines. The model is often the easy part. When the model is expensive, you do not deploy it in the hot path. Mail filtering sees the same thing. In many cases, simpler classifiers using robust structural features outperform more glamorous approaches, especially when adversaries adapt quickly. The hidden hard part: knowing what you have already seen Rob and Ken (MailChannels CEO) bond over a shared engineering pain: “stupid simple” lookups at absurd scale. At Monarx, one of the earliest steps is: do we already know this content? Compute a hash, check if it has been seen, and avoid duplicating work. That sounds easy until you do it millions of times and need sub-millisecond responses. Rob mentions using Bloom filters and needing custom approaches once you pass certain scale thresholds. For email infrastructure, the equivalent is real-time reputation and behavior tracking: Counting events for millions of entities Querying counters across multiple time windows Enforcing policy in under a millisecond Never going down, because if the counters go down, the filtering logic collapses This is where reliable infrastructure stops being a tagline and becomes a design requirement. Why the economics feel broken for upstream security A candid part of the episode is the frustration: upstream security reduces harm for the whole world, but the money tends to flow to downstream enterprise tooling. Hosting providers often do not have large security budgets. They also do not always have strong economic incentives to invest, because many consequences land on victims, recipients, and other networks. Rob argues this type of protection should be treated like a utility because it benefits everyone. Whether or not you agree with the policy angle, the operational implication is clear: if you sell into hosting and multi-tenant platforms, your product must be cost-effective, low-touch, and extremely predictable. You cannot rely on expensive compute to justify the bill. What platform operators should take away from this episode 1) Optimize for proportional enforcement Hard shutdowns and blanket suspensions are easy to implement. They are also a common cause of customer outages. Design controls that can isolate bad actors without cutting off every tenant who shares infrastructure, IP space, or a sending path. 2) Treat false positives as an availability incident In multi-tenant environments, a false positive is not a support ticket. It is downtime. Invest in testing, safe rollout mechanisms, and rollback plans. Build your detection and enforcement so that failure modes are contained. 3) Put expensive analysis off the hot path If you need heavyweight analysis, do it asynchronously or in a centralized system where you can control cost and compute. Keep the real-time path lean and predictable. 4) Win with instrumentation and feature extraction Good detection is rarely just a model choice. It is the plumbing: the signals you collect, how quickly you can look them up, and how reliably you can apply them. 5) Accept that one layer cannot solve the entire problem Hosting malware cleanup cannot solve email content abuse. Email filtering cannot patch broken PHP plugins. Defense in depth is not optional. Where MailChannels fits in this story If you are building or operating a platform that sends transactional email, the problems Rob describes will sound familiar. Your customers do not care how clever your detection is if it causes login emails or password resets to disappear. MailChannels is built around a simple operational goal: keep legitimate email flowing even under stress, while applying abuse controls that are granular enough to avoid unnecessary shutdowns. If you want a transactional email provider designed for multi-tenant reality, evaluate the MailChannels Email API and SMTP delivery options