Features Reference

Use this page to decide which Noxtica capability families belong in your deployment and what your team will receive from each one. It describes customer-visible behavior, not every implementation detail.

Noxtica is provisioned for an account, tenant, domain, and plan. A capability can be present in the platform without being enabled for your tenant or appropriate for every domain. Treat the status shown in Backoffice, the scopes on your API key, and your order form or service agreement as the source of truth for availability. If a page or setting described here is not visible, ask your Noxtica contact whether it requires an entitlement, an operator role, tenant activation, a supported client, or legal-basis review.

Risk and decisioning

Use this family when signup, login, checkout, content access, or an API operation needs more context than an allow/deny list can provide.

01. Risk Scoring

A browser assessment returns a numeric score, a five-level risk_level, a separate confidence value, and named flags or reasons when applicable. The tier is an input to your policy, not a statement about a person’s identity or intent.

Configure and use it

1. Add each origin in Backoffice → Domains and install the collector with that domain’s Site Key.
2. Review score distributions and reason categories in Analytics, Fingerprints, and Quality & Calibration before choosing actions.
3. Set different policy thresholds for different customer journeys. A high-value account change can require step-up verification earlier than a read-only page.
4. Start enforcement in observe-only or shadow mode where available, compare proposed actions with known outcomes, and then promote a reviewed policy.

Outputs and customer value

• Browser callbacks expose the score, tier, confidence, flags, device handle, and cache state.
• Server lookups expose the current risk assessment and device timestamps for backend policy checks.
• The console provides population distributions, reason breakdowns, and decision history for investigation and policy review.
• Risk-action views show what a configured policy did or would have done, helping teams measure fraud coverage and customer friction before changing enforcement.

Eligibility and limits

Core scoring is part of an activated web integration; advanced calibration, metered scoring, and enforcement surfaces depend on plan, role, and tenant configuration. A score is probabilistic and context-specific. It does not guarantee that a visitor is human, fraudulent, or safe, and a particular false-positive rate is not promised unless it appears in your contract and measurement plan.

Device and browser intelligence

Use this family when you need to recognize returning browser installations, compare device context across sessions, or corroborate an authentication or fraud decision.

Configure and use it

• Install the browser collector automatically or initialize it through the JavaScript, React, Next.js, or Vue surface documented in Getting Started.
• Choose the supported collection mode for the customer journey and use checkOnce() when you want the configured cache interval respected.
• Use Fingerprints, Compare, Population Data, and device detail views to review the evidence available for a session.
• Link the returned device handle to your own account or transaction only where your disclosed purpose and retention policy permit it.

Expected outputs

You receive a tenant-scoped device handle, risk fields, named reason categories, timestamps, and the browser/device context exposed by the applicable API or console view. Optional attestation can add an integrity result that corroborates the device assessment without exposing the underlying challenge method.

Customer value

Recognition and comparison help distinguish a familiar installation from a new or inconsistent one, support step-up authentication, and give investigators a repeatable reference across events.

Eligibility and limits

Browser storage clearing, private modes, browser changes, operating-system changes, limited APIs, and consent choices can reduce continuity or confidence. A device handle is not a verified natural-person identity. Hardware and mobile attestation require supported clients, an entitled module, and tenant/domain activation; absence of an attestation result must be handled as unknown rather than automatically hostile.

Bot, abuse, and network defense

Use this family to triage automation, scripted abuse, suspicious infrastructure, and known bot traffic without treating any one network or browser characteristic as proof.

02. Bot Detection

Noxtica combines browser consistency, automation, network, device, and interaction evidence into the same calibrated output used by your policy. Privacy browsers, corporate networks, assistive technology, monitoring tools, and approved automation can resemble parts of an abusive pattern, so reason categories should be interpreted together.

Configure and use it

• Review Bot Intel, Geo Risk, fingerprint details, and analytics by domain.
• Connect an eligible reputation source or use the provided network context where your account includes it.
• Define approved automation separately from general traffic, then use policy conditions to allow, observe, challenge, or block.
• Validate actions in shadow mode and monitor customer-support and conversion outcomes after rollout.

Outputs and customer value

Outputs include calibrated risk, confidence, explainable bot/network reason categories, known-agent context where available, and aggregate trends. Teams can prioritize abuse queues, protect expensive routes, and allow expected automation without weakening policy for everyone.

Eligibility and limits

IP reputation, advanced bot intelligence, emerging-threat reporting, and some feeds can be metered or module-gated. Network reputation changes over time; VPN, relay, mobile, and datacenter use is not inherently malicious. No bot detector catches every automation tool, and Noxtica does not promise frictionless treatment for every legitimate visitor.

Account linking and investigation

Use this family after detection when an analyst needs to determine whether events, devices, accounts, or infrastructure may be related.

Configure and use it

• Begin with Fingerprints, Compare, and account-associated device history.
• Use linkage, cluster, investigation, OSINT, or geo views only when they are visible for your tenant and your documented legal basis covers the data involved.
• Save the evidence and rationale that matter to your case; do not treat a shared attribute as identity proof.
• Feed confirmed outcomes back through the supported labeling or review surface so future calibration can be evaluated against your traffic.

Expected outputs

Customer surfaces can show side-by-side device evidence, event timelines, related-profile or cluster hypotheses, geographic/network context, investigator notes, and exportable case material. These outputs help an analyst move from a single alert to a reviewable account or abuse pattern.

Eligibility and limits

Investigation, linkage, raw-network detail, and external enrichment are separately controlled and may require entitlement, an operator capability, recorded legal basis, or explicit tenant opt-in. Relationships are leads, not proof that two accounts belong to the same person. Sparse traffic, shared devices, shared networks, and expiring retention windows can limit conclusions.

Journey and experience observability

Use this family when risk needs to be understood in the context of a customer journey: what route was visited, what failed, and where friction appeared.

Configure and use it

1. Choose a domain in Backoffice and enable only the tracker, real-user monitoring, replay, heatmap, journey, or funnel surfaces included for that domain.
2. Set sampling, capture level, redaction, console/error capture, consent or legal-basis admission, and retention before collecting production sessions.
3. Use Client RUM, Session Replay, Runtime Tracker, Heatmaps, Journeys, and Funnels to move from aggregate performance or risk to an eligible session.
4. Compare operational findings with risk reasons; observability context should inform a decision, not silently become a blocking rule.

Expected outputs and customer value

Depending on configuration, outputs can include route and journey summaries, web-performance measurements, error aggregates, replay timelines, heatmaps, funnel progression, and session context attached to an investigation. They help product, fraud, and support teams see whether a security control protected a route or merely created friction.

Eligibility and limits

These capabilities are domain-scoped, opt-in, and subject to plan limits, sampling, browser support, consent/legal-basis requirements, redaction, and retention. The small synchronous recorder helper has no transport; capture is admitted or discarded by the configured policy when the asynchronous collector starts. Replay is not a complete record of everything a user saw, and sampled data must not be treated as a full traffic census.

Monitoring, alerting, and reporting

Use this family to run Noxtica as an operational control rather than checking individual records by hand.

03. Operator Console

The Backoffice brings together account health, risk analytics, device records, live monitoring, policy outcomes, alerts, audit history, exports, and usage. Navigation and actions are filtered by the signed-in operator’s role and tenant scope.

Configure and use it

• Build saved views and domain/time filters around the routes your team owns.
• Configure eligible alert channels, webhooks, or event sinks with the minimum data needed by the destination.
• Use audit and risk-action history to review who changed a setting and how a policy behaved.
• Schedule your own review cadence for false positives, missed abuse, delivery failures, quotas, and retention.

Outputs and customer value

Dashboards provide trends and breakdowns; live and alert surfaces identify records needing attention; exports, webhooks, and event sinks move eligible events into customer workflows. Together they support investigation handoff, policy governance, and evidence collection without requiring every stakeholder to query an API.

Eligibility and limits

Views depend on role, tenant scope, retained data, and enabled modules. Alerting and event delivery require explicit destination configuration and can be affected by downstream availability or quotas. Audit records document platform activity; they do not by themselves certify compliance with a framework.

Agent identity and control

Use this family when signed automated agents, AI crawlers, and other machine clients need a different trust policy from anonymous automation.

Configure and use it

• In the eligible Agentic Security or KYA surface, define which verified agent identities are allowed, denied, or observed for a tenant.
• Associate those trust outcomes with route-specific risk actions rather than applying one global rule.
• Start in observe-only mode, review unknown and failed-verification traffic, then enable challenge or block actions deliberately.
• Keep unsigned or unverifiable traffic in an unknown path unless your own policy has other evidence for escalation.

Expected outputs and customer value

Customer-visible results distinguish verified, unverified, allowed, denied, and unknown agent states and connect them to policy outcomes and audit records. This lets content, security, and platform teams admit wanted agents while applying stronger controls to unwanted or unverified automation.

Eligibility and limits

Know Your Agent, agent verification, and associated enforcement require the module to be included and activated for the tenant. Verification proves possession of an accepted agent credential under the supported protocol; it does not prove the agent’s intent, the human behind it, or the safety of every request. Payment or crawl-monetization rails, where separately offered, are optional workflows rather than a detection differentiator.

AI-assisted operations

Use this family when operators need faster summaries and investigation context inside the console without handing policy control to an autonomous system.

Configure and use it

• Enable the assistant only for eligible tenants and operators, select an available provider configuration, and set usage/budget controls.
• Ask it to summarize the Noxtica state the operator can already access, such as policies, domains, recent risk activity, or audit history.
• Verify important findings in the linked console records before changing policy through ordinary operator workflows.
• Review assistant usage and audit/oversight surfaces as part of your access-review process.

Expected outputs and customer value

The assistant produces conversational summaries and pointers to relevant customer data under the current operator session. It can shorten investigation setup and explain where to look next while preserving the human decision point.

Eligibility and limits

Provider, model, budget, region, and module availability are account-specific. Current assistant tools described in the public documentation are read-only. Generated text can be incomplete or wrong; it is not a verdict, compliance determination, or autonomous enforcement action.

Developer platform and integrations

Use this family to collect browser context, consume results in your application, or connect Noxtica events and reads to existing systems.

04. Fast Verification

The collector loads asynchronously after any required early recorder helper, caches assessments according to configuration, and exposes results through browser events and APIs. Backend services can perform scoped lookups or use supported server SDKs. Performance depends on client, route, cache state, configuration, geography, and network conditions; no universal latency value is implied here.

06. Open Integration

Supported customer surfaces include the script-tag loader, programmatic browser client, framework wrappers, scoped Server API keys, server SDKs, browser events, exports, webhooks/event sinks, and a read-only MCP connection for eligible tenants.

Configure and use it

• Copy the current install snippet and Site Key from Backoffice; keep production and non-production origins separate.
• Create the narrowest server key scopes required and keep secret keys off the client.
• Choose browser callbacks for in-page experience, server lookups for trusted backend policy, and event delivery or exports for downstream operations.
• Monitor errors, rate limits, cache behavior, sink delivery, and usage quotas.

Outputs and customer value

Integrations deliver typed risk/device responses, lifecycle events, scoped API reads, event records, export files, and read-only agent context. You can place the decision at the right boundary while retaining Noxtica’s explainable reasons and tenant scope.

Eligibility and limits

Endpoints, scopes, quotas, SDK packages, event sinks, MCP, relay hosts, and offline verification options vary by account and contract. A public Site Key is origin-bound; a Server API key is secret. No self-hosted, air-gapped, or migration guarantee applies unless it is explicitly included in your agreement. See Getting Started and Backend Integration for the current public contract.

Identity verification and access

Use this family when a workflow must collect identity evidence, verify device/app integrity, bind an approved credential, or route an exception for human review.

Configure and use it

• Confirm that identity verification is included for the tenant, jurisdiction, evidence type, and platform you intend to support.
• Configure policy and provider requirements before presenting capture, liveness, passkey, mobile-attestation, recovery, or review flows.
• Use verification and review queues to separate completed, inconclusive, rejected, expired, and escalated cases.
• Keep the resulting decision in your own authorization flow; device risk can corroborate identity evidence but should not replace it.

Expected outputs and customer value

Eligible flows can return case status, evidence-processing status, provider result, device or app integrity context, passkey state, review disposition, and an audit trail. These outputs help onboarding and access teams route exceptions consistently and keep high-risk changes behind step-up controls.

Eligibility and limits

Identity, liveness, mobile, recovery, screening, and passkey surfaces are separately entitled and can depend on an external provider, supported device, geography, evidence quality, role, and policy. Availability in the console does not mean every sub-flow is activated. No result should be described as legal identity proof outside the scope of the configured provider and contract.

Governance and data controls

Use this family to define who can operate Noxtica, which domains may collect, what data is retained or exported, and what legal/consent conditions admit optional collection.

05. Privacy by Construction

Noxtica minimizes and scopes browser/device data, but does not describe all such data as non-personal. A returning-device handle, network context, and browser characteristics can be personal data depending on law and use. Your configuration, disclosures, legal basis, retention, processors, and contract remain part of the control boundary.

Configure and use it

• Register exact origins and use separate Site Keys for environments.
• Assign least-privilege roles; enable MFA or configured SSO controls for operators where available.
• Set retention, export, deletion, redaction, consent, DNT/GPC, optional biometric, and raw-network policies for each applicable surface.
• Review Audit, Data Operations, domain settings, the privacy notice, subprocessor page, and your signed terms together.

Outputs and customer value

Governance surfaces expose domain state, roles, sessions, policy/consent receipts, audit events, retention status, exports, deletion workflows, and configuration history. They help security, privacy, and engineering teams establish a reviewable operating record.

Eligibility and limits

Specific hosting location, transfer restrictions, deletion timelines, subprocessor commitments, certifications, and data-processing terms come from current legal documents and the customer’s contract—not this feature reference. Optional behavioral biometrics and raw network storage require explicit activation and additional review. Exports and audit trails support your controls but do not make a deployment automatically compliant.

Workspace and commercial operations

Use this family to administer tenants, domains, users, plan modules, quotas, usage, invoices, and available account services.

Configure and use it

• Invite or assign operators according to the roles enabled for your account and select the correct tenant before making changes.
• Add domains, inspect module status, and compare current usage with plan or metered limits.
• Use package, wallet, invoice, order, or report surfaces only where they are present for your commercial arrangement.
• Contact Noxtica for provisioning or contract changes that are not offered through your visible account controls.

Expected outputs and customer value

Workspace surfaces show tenant/domain status, operator access, active modules, usage and quota records, and eligible commercial documents or balances. This gives account owners one place to understand what is enabled and what operational limit needs attention.

Eligibility and limits

Commercial surfaces vary by role, billing arrangement, currency, provider, region, and contract. A module listed in pricing or represented in code is not necessarily available to purchase or activate in your account. No free tier, instant provisioning, self-serve checkout, price, or service level is promised by this page.

How to choose a starting set

• Protect a web journey: start with Device and browser intelligence, Risk and decisioning, and a shadow policy.
• Investigate abuse: add Bot, abuse, and network defense, Account linking and investigation, and operational reporting.
• Understand friction: add Journey and experience observability with reviewed capture and retention settings.
• Govern automated agents: add Agent identity and control and route-specific enforcement.
• Connect existing operations: use Developer platform and integrations plus scoped alerts, sinks, or exports.

Related reading

• Getting Started — install the collector and configure domains.
• Threat categories — interpret public reason families without relying on hidden probes.
• Why calibration, not verdicts — turn risk and confidence into a customer-owned policy.
• Use cases — apply these families to specific journeys.
• Engineering principles — the operating constraints behind the defaults.