Why we block only after proof

Blocking a request is easy. Knowing that it is safe to block is the product. Reputation, geography, user-agent strings and a single ugly URL are all clues, but legitimate traffic can share every one of them. PharosHub never turns those clues alone into a denial.

Suspicion is not authority

A false positive on a report costs attention. A false positive on an access decision can cost a booking, an account change, or an internal operation. That is why a scoring threshold is not enough authority to interfere with a real application route.

We contain only after behavior crosses from suspicious to impossible for a legitimate visitor: a repeated tripwire sequence, a corroborated exploit attempt, or use of a credential that was never valid.

That proof opens a short-lived quarantine in the application runtime. The decision is local and immediate, then shared with the customer's other application instances through the signed collector channel.

Contain the boundary, not the whole person

The operator names the sensitive routes and methods: an admin API, a checkout mutation, an account recovery action. A contained source is denied there while the public site and every unlisted route remain available. PharosHub does not become the router for the whole website.

The lookup happens in memory. No request waits for PharosHub, an IP reputation vendor, or a database. If reporting fails, the application still serves traffic and the local decision expires on its own.

Why this is different from a WAF

A WAF judges the current request at the edge. PharosHub remembers what the source already proved inside the application and protects the operations that matter there. They solve different parts of the problem and are stronger together.

Every prevented action enters the evidence ledger with the policy reason and expiry. An operator can release the source, and every decision has a bounded lifetime. Active defense should be reversible, explainable, and narrower than the proof that authorised it.