Why detection and mitigation are separate modules
Seeing an anomaly and changing production traffic are different responsibilities. A clear boundary supports observation-only teams, manual response and governed automation.
Begin with a shared evidence foundation
Infrastructure monitoring, HTTP analysis and protection decisions become confusing when every tool invents a different incident. Hostwatch begins with a common evidence layer: a selected window, host and site identity, request totals, response outcomes, service health and individual examples when retention allows them. An operator can move between traffic, application errors and host resource pressure without pretending that a saved example is a complete historical dataset. This shared context is useful even when no detector or mitigator license is enabled. It makes ordinary troubleshooting possible before a security hypothesis is formed.
The evidence layer also needs provenance. An Nginx access log provides a recorded HTTP outcome. A host agent may identify a local interface or process. A header may describe a claimed Referer or User-Agent. An application reports its own errors and latency. These signals have different trust levels, and the control plane must preserve that distinction. Show the time range, sampling limit and data gaps near the conclusion. If the baseline is incomplete, later modules inherit that limitation. They should not convert uncertainty into a confident attack label or broad enforcement action merely because a chart looks dramatic.
The detector explains; it does not write firewall rules
A detector consumes bounded evidence and emits a structured hypothesis. It may identify a burst against an expensive route, sequential URL enumeration, an unusual mix of query parameters, an unverified crawler claim or a coordinated change in client behavior. Its output should include affected scope, window, supporting signals, missing evidence, likely activity class and confidence. “Possible URL enumeration across 120 missing paths” is useful to an operator. A mysterious high risk score is much harder to review, tune or defend after a false positive.
Classification is not enforcement. A real launch or a client bug can resemble a hostile burst. The detector should consider route cost, response mix, verified service identities and the normal rhythm of that site. Repeated packet sizes can be one feature, but normal browsers also make many identical requests. Explain why an incident was raised and what evidence would lower its confidence. This makes observation-only deployment valuable: the team can learn its traffic, compare incidents with application logs and improve thresholds without giving a new classifier permission to alter live traffic. The boundary protects users while the model of normal behavior matures.
The mitigator owns the action lifecycle
The mitigator turns a reviewed intent into a typed production change. It needs the target site and route, client cohort or address scope, requested behavior, expiration and the person or policy that authorized it. Before applying, it should preview the likely blast radius and check that the target still exists. During apply, idempotency prevents a retry from multiplying rules. Afterward it must verify the installed generation, expose matched traffic and offer a dependable reversal path. Those obligations hold whether the proposal came from Hostwatch, a human operator or a separate incident system.
An observed response code is not proof of a mitigation. A 429 may come from an application, an existing proxy rule or the new action. A closed connection can reflect a different Nginx directive or an overload path. Link the action ID to the installed configuration and its counters. Track expiry and rollback as first-class states. If the expected configuration cannot be verified, the interface should say “unverified” rather than display a reassuring Protected badge. This is where careful state management matters most: an invisible rule or one that outlives the incident can deny real customers long after the burst has ended.
Independent entitlements match real operating modes
Teams differ in how much automation they can accept. Some want host and traffic visibility only. Another team needs detection reports for existing firewall operators. A third wants governed manual mitigation without automatic classification. Independent Detector and Mitigator entitlements express those choices. The interface can show a capability unavailable under the current contract without making the underlying evidence disappear. License boundaries should not create duplicate menus, duplicate traffic charts or incompatible incident records. An operator still needs one path from a suspicious signal to an understood decision.
Separate commercial modules do not automatically imply physically separate executables. The current Hostwatch agent and API can gate capabilities through entitlements while sharing binaries and data contracts. A self-hosted deployment therefore requires clear provisioning, audit and contract enforcement; it should not be described as physically isolated code by default. The value of the split is the capability boundary. A detector can be improved without changing the meaning of an enforcement action. A mitigator can support manual operation without pretending a classifier approved the rule. Physical packaging can evolve later while the event and permission contracts remain stable.
Make the handoff a proposal, not an implicit command
The critical interface between the modules is a proposal. A detector might propose a five-minute route-specific rate limit after finding elevated request cost and low completion among a suspicious cohort. The proposal carries an evidence snapshot, assumptions, scope, expiry and expected effect. The mitigator checks whether the operator or delegated automation policy permits that exact action. The control plane records the decision. Without a detector license, a person can create a manual proposal from observed evidence. Without a mitigation license, an incident can remain readable with no Apply control. Neither module should silently stand in for the missing one.
This boundary clarifies failures. If a rule hurts users, was the classification wrong, the proposed scope too broad, or the installed configuration different from the approved scope? Those require different fixes. Combining them into one “attack blocked” event makes review difficult. A useful event history preserves evidence at detection time, approval or policy decision, exact installed rule, match counts and application outcome. It also shows rejected proposals and failed applies. That record is a stronger foundation for automation than a single green checkmark, because it tells the team which part of the chain needs correction.
When visibility degrades, automation loses authority
Automatic response can help at thousands of requests per second, when waiting for a human lets an expensive route collapse. Speed does not justify an unlimited deny rule. Delegated policy should name the sites, routes, action types, maximum duration and client cohorts automation may touch. It also needs health gates: current telemetry, working enforcement verification and an available rollback path. If any of these conditions fail, Hostwatch can continue observing and alerting but should stop issuing fresh automatic changes. A detector does not become more certain merely because traffic is loud.
The first automatic action can be deliberately mild. A short route-specific limit may reduce origin cost while the team checks whether legitimate sessions still complete. Expansion requires fresh evidence and must remain within policy. Controls should expire when the pressure ends. A broad country block is a poor default: country is not intent, and real users share networks and proxies. The operator should see what automation did in ordinary product language: why it acted, how many requests matched the actual rule, which errors moved, when the action expires and how to reverse it immediately. An action that cannot be explained should not be automatic.
Keep web and native views in agreement
Operators work in different contexts. A website can compare long windows, route tables, policy history and deployment state. The native app can make a focused incident readable away from a desk, show a geographic distribution and support a quick review or reversal. Both surfaces should describe the same underlying event and action states. If one says “blocked” while the other shows only 429 observations without a rule ID, neither is dependable. Labels such as Recorded requests, Saved examples, Suspected bot and Verified action must mean the same thing everywhere.
Visual design is operational safety. A dramatic chart can make a small sample look like a complete window. A map with equally sized pins can make every location look equally important. Show scale, sample coverage, unknown geography and the selected time range near the value. For actions, a compact summary of scope, duration, installed generation and rollback is more valuable than decorative severity color. The modules may have different licenses, but an operator should be able to follow one coherent investigation across the web control plane and iPhone app. A back button should preserve that path rather than force them to reconstruct it.
Judge the design by the outcome for users
The goal is not to maximize incident or block counts. It is to keep the application usable under pressure and explain every production change. After enforcement, compare accepted traffic, latency, upstream errors, completion of important flows and the rule’s own matches. If the site still times out, a correct detector has not solved the operating problem. If the origin recovers but genuine customers are denied, the mitigation scope is wrong. Both outcomes belong in the same review window, next to the original hypothesis and action. A rollback that is never tested is only a promise.
Hostwatch’s direction is evidence first, action second, verification always. The module split gives teams room to adopt and license the capabilities they need, but it does not replace careful telemetry, configuration checks or human judgment. An honest product keeps unresolved uncertainty visible: bounded request retention, unknown process attribution, unverified bot identity and incomplete rule counters. These are not untidy details to hide at the bottom of a screen. They are the conditions under which a responsible operator decides to wait, fix the application, or temporarily constrain traffic. The architecture succeeds when that choice is clear and real users remain able to work.
A detector describes evidence. A mitigator owns a scoped, expiring action. The control plane records identity, approval, installed state and measured outcome.