Threat Categories
Threat categories are public explanation families. They tell an authorized customer operator what kind of evidence influenced an assessment without exposing hidden probes, exact scoring weights, anti-evasion methods, or proprietary implementation.
A category is not a verdict and does not map to one fixed action. Read it with the overall risk tier, confidence, other reasons, customer journey, and your own known outcomes. The exact reasons visible to you depend on collection mode, browser support, enabled modules, tenant/domain policy, role, retention, and consent or legal-basis controls.
01. Automation and bots
This category covers evidence consistent with scripted browsers, automation tooling, remote control, repeated machine-driven flows, or known automated clients.
When to use it
Use it to protect routes where automation creates cost or abuse: signup, login, promotion redemption, inventory, checkout, content/API access, or account changes. Define expected automation—monitoring, testing, integrations, or approved agents—before enforcement.
What the customer sees
The result or fingerprint detail can name an automation/bot reason family, while analytics and bot-intelligence views can show aggregate volume and known-agent context where enabled. Risk Actions shows the configured action or shadow outcome.
How to interpret it
Automation evidence is more useful when it repeats across events or agrees with consistency, infrastructure, device, agent, or interaction context. A legitimate automated client should follow an explicit allow or agent policy rather than forcing the whole route to ignore automation evidence.
Outcome
Prioritize likely scripted abuse, route approved automation predictably, and apply proportionate challenge or blocking to protected operations.
Tuning
Start in observe-only mode where available. Segment by route, client, and known agent; review false positives and operational tools; then promote reviewed policy. Do not infer the hidden detection method from a reason name or build a permanent deny rule from a single event.
Limitations
Automation changes, and no detector identifies every tool. Accessibility software, test harnesses, monitoring, remote-work tools, and enterprise automation can create similar context. Signed-agent verification, when enabled, establishes a supported identity state but does not prove safe intent.
02. Fingerprint tampering
This category covers material inconsistency between what a browser or environment claims and what its observable behavior supports. It is intended to distinguish unexplained contradiction from an ordinary privacy choice.
When to use it
Use it as corroboration for spoofing, replay, evasion, or synthetic-environment investigations, especially when a valuable action also has automation, network, device, or account context.
What the customer sees
A public consistency/tampering reason can appear with the overall score and confidence. Authorized operators can compare the record with domain population and prior device history through eligible fingerprint or investigation views.
How to interpret it
One inconsistency can come from browser changes, extensions, restricted APIs, compatibility layers, or partial collection. Repeated contradictions or agreement across independent categories deserve more weight than a single unusual characteristic.
Outcome
Surface sessions that need step-up or review without teaching an attacker which internal test fired.
Tuning
Review the affected browser/OS population, fresh versus cached state, collection mode, CSP, and recent client changes. Provide allow treatment for approved tooling and avoid treating a reason label as identity proof.
Limitations
The category does not prove deliberate deception. Browser privacy changes and software updates can shift the population. Some evidence is unavailable on restricted or unsupported clients, which can lower confidence.
03. Infrastructure abuse
This category covers network context associated with higher abuse risk, such as anonymization, hosting infrastructure, reputation sources, or inconsistent location/network information. It is corroborating evidence, not guilt by network.
When to use it
Use it to prioritize high-cost routes, rate-limit abusive patterns, enrich an investigation, or strengthen a decision already supported by automation or account evidence.
What the customer sees
Eligible results and console views can expose public network/infrastructure reasons, coarse geography or provider context, and reputation status. Detailed or retained network data, external feeds, and geo/investigation views have separate controls.
How to interpret it
Corporate VPNs, privacy relays, mobile carriers, shared egress, cloud workspaces, journalists, and travelers can resemble risky infrastructure. Interpret the category with route, device, behavior, history, and known outcome.
Outcome
Identify concentrated abuse and investigate network patterns while preserving a path for legitimate users on shared or privacy-preserving infrastructure.
Tuning
Keep network-only reasons out of irreversible block rules. Measure by provider type and route, maintain reviewed exceptions, and monitor reputation changes. Connect a customer-selected feed only where supported and approved.
Limitations
Addresses and reputation change, geolocation is approximate, and shared egress is common. Raw-network retention and some feeds can require explicit opt-in, entitlement, additional disclosure, or legal review.
04. Privacy-browser handling
This category provides context for browsers or modes that deliberately reduce, standardize, or restrict observable detail. A privacy choice is not itself a threat.
When to use it
Use it to prevent low detail or standardized output from being mistaken for automation, and to compare policy friction across privacy-preserving browser populations.
What the customer sees
Where recognized, the assessment can identify privacy-browser context separately from tampering. Analytics and fingerprint detail can help authorized operators compare risk, confidence, challenge, and error rates for that population.
How to interpret it
Privacy context explains why some evidence may be limited. Continue to evaluate independent automation, network, device, agent, or interaction reasons, but do not escalate merely because the browser protects users.
Outcome
Keep legitimate privacy-conscious users in the normal or proportionate path while retaining protection against abusive automation using the same browser family.
Tuning
Review challenge completion, abandonment, support contacts, and unknown/error rates by browser family. Prefer reversible step-up when independent evidence is concerning and confidence is limited.
Limitations
Browser identification and behavior evolve. Noxtica does not guarantee that every privacy browser is recognized or that its users will never be challenged. Your CSP, collection mode, consent choices, and browser support affect available evidence.
05. Hardware checks
This category covers eligible device-integrity and environment evidence used to corroborate whether a session is consistent with its claimed execution context.
When to use it
Use it for high-value or high-abuse operations where browser-only evidence needs corroboration. Optional browser, GPU/CPU, mobile-app, or platform attestation should be applied only to supported clients and entitled tenants/domains.
What the customer sees
A customer-facing integrity or attestation status, public reason, confidence contribution, and related console record can be available. The hidden challenge, precise measurement, and validation mechanism are intentionally not exposed.
How to interpret it
A successful supported check is one piece of integrity evidence. An unavailable, unsupported, timed-out, or missing result is unknown, not automatically malicious. A failed or inconsistent result should be combined with route and other evidence before consequential action.
Outcome
Raise the cost of synthetic environments and add device/app integrity context to authentication, fraud, or agent policy.
Tuning
Enable by selected domain or application, validate client coverage in observation first, and define explicit success, failure, and unknown paths. Monitor battery/performance, browser/platform support, challenge completion, and fallback behavior in your real customer journey.
Limitations
Hardware and mobile attestation require supported environments and separate configuration. They do not prove a natural person’s identity or benevolent intent. Availability, quotas, and provider behavior vary by account and client.
06. Behavioral anomalies
This category covers eligible interaction and journey context that differs from the relevant population. It is supporting evidence, not a diagnosis of whether a person is human.
When to use it
Use lightweight timing and journey context to corroborate other risk on selected routes. Use behavioral biometrics only after the required entitlement, explicit activation, disclosure, consent/legal-basis, minimization, and retention review.
What the customer sees
Depending on configuration, the result and behavioral surfaces can show a public anomaly reason, aggregate or subject-level context, journey change, and policy effect. Exact motion, keystroke, timing, or detector mechanics are not published as a customer tuning recipe.
How to interpret it
Interaction patterns vary across accessibility tools, motor ability, devices, cultures, network delays, task familiarity, and page design. Behavioral evidence should corroborate other categories and should not be a sole blocking reason.
Outcome
Identify otherwise-clean sessions or journeys that merit observation or a reversible step-up while measuring customer friction.
Tuning
Start with lightweight, non-biometric context where appropriate. For optional biometrics, activate only reviewed domains and monitor counterfactual or shadow results, affected cohorts, challenge completion, support impact, and reversals.
Limitations
Short sessions and sparse interaction reduce confidence. Journey/UI changes can shift baselines. This category must not be used to infer health, disability, or other sensitive traits, and Noxtica does not promise that it distinguishes every person from every script.
How the categories combine
Noxtica combines the evidence available to the enabled assessment into one score, risk tier, and confidence value, with named public reasons where applicable. Some modules also return a distinct status—such as agent verification, attestation, identity-case, or policy-action state—that should retain its own meaning.
A customer policy should ask:
- Is the result fresh enough and valid for this route?
- Which modules and evidence were available, and how confident is the assessment?
- Do multiple independent reason families agree?
- Is there an ordinary explanation or approved automation path?
- How valuable and reversible is the requested action?
- Is an accessible challenge, review, appeal, or recovery path available?
Do not reconstruct an internal formula from category names. Use your labeled outcomes and the supported Analytics, Fingerprints, Quality/Calibration, Risk Actions, and Audit surfaces to judge policy behavior.
Availability and configuration checklist
- The correct tenant, domain, Site Key, and environment are selected.
- Collection mode and cache interval fit the decision point.
- Optional agent, reputation, attestation, behavioral, replay, identity, or investigation modules are entitled and activated where needed.
- Operator role and API-key scopes expose only required data.
- Consent/legal basis, redaction, retention, and downstream destinations have been reviewed.
- Shadow, unknown, error, rate-limit, and provider-down behavior is defined before enforcement.
Related reading
- Detection signals — how browser, network, device, and interaction layers become an assessment.
- Why calibration, not verdicts — map risk and confidence to policy.
- Customer capability reference — customer surfaces, outputs, eligibility, and limits.
- Browser runtime details — collection modes, events, caching, and troubleshooting.
- Frequently asked questions — common integration and privacy questions.