---
title: "Use Cases"
description: "Customer reference patterns for marketplaces, financial services, identity-sensitive journeys, and automated-agent access—with configuration, outputs, impact measures, and limits."
canonical_url: "https://noxtica.com/docs/use-cases/"
markdown_url: "https://noxtica.com/docs/use-cases/index.md"
last_updated: 2026-10-27
published: 2026-05-22
section: "capabilities"
section_title: "Product & Capabilities"
site: "Noxtica"
language: "en"
source: markdown
---

# Use Cases

These are implementation patterns, not customer case studies or promised results. They show where to collect, which Noxtica surfaces to use, what the customer application decides, and how to measure both abuse coverage and legitimate-user friction.

Before using any pattern, confirm the required module, tenant, domain, role, quota, client, data policy, and contract eligibility in Backoffice and with your Noxtica contact.

## Marketplaces

**The problem:** repeated accounts can manipulate reviews, rankings, referrals, promotions, inventory, or seller/buyer trust. Shared devices and networks are also normal, so a single match is not enough to establish abuse.

**When to use:** apply assessment at account creation and at the valuable action being protected, such as promotion redemption or review publication. Keeping both events lets an analyst distinguish ordinary signup volume from coordinated use of the platform.

**The signal:** a calibrated risk assessment and tenant-scoped device handle can be compared with account, journey, network, and prior-event context. Eligible linkage or cluster views can suggest related activity for review; they do not prove common ownership.

### How the signal compounds

A marketplace can review several evidence families together:

- **Automation and bots (01):** automated interaction or browser inconsistency reasons across attempts.
- **Fingerprint tampering (02):** a mismatch or manipulation reason that appears alongside other evidence.
- **Infrastructure abuse (03):** network context that raises concern but remains weak on its own.
- **Behavioral anomalies (06):** eligible interaction context that corroborates a pattern after required activation and review.
- **Account and journey context:** repeated attempts, promotion state, device familiarity, and confirmed platform outcomes from your own systems.

### Configure and use

1. Register the signup and protected-action origins in **Domains** and install the collector.
2. Send the returned device handle with the marketplace event to your backend; never expose a secret API key in the browser.
3. Review baseline distributions in **Analytics** and individual records in **Fingerprints**.
4. If entitled and legally approved, use **Compare**, linkage, investigation, tracker, or journey views for analyst triage.
5. Create a route-specific policy in shadow mode where available.
6. Label confirmed legitimate and abusive outcomes through the supported customer workflow.

### The policy

A practical starting policy allows low-risk traffic under ordinary account controls, observes medium risk, and uses a reversible step-up or moderation queue for high risk. Reserve blocking for reviewed conditions with stronger corroboration. Maintain explicit handling for shared households, managed devices, schools, libraries, VPNs, accessibility tools, and approved automation.

### Expected output

Operators receive risk, confidence, reason families, a device handle, and eligible relationship or journey context. The marketplace application receives only the fields it needs to decide whether to proceed, step up, hold publication, or queue review.

### The outcome

Measure duplicate-account confirmation, promotion or review-abuse rate, moderation yield, challenge completion, signup and publication abandonment, support contacts, appeal reversals, and unknown/error rates. The desired outcome is a better-ranked abuse queue and proportionate friction—not a guaranteed percentage reduction.

### Limitations

Shared attributes are hypotheses, device continuity can reset, and sparse or expired data reduces linkage quality. Investigation, linkage, detailed network, replay, and behavioral surfaces may require separate activation, legal basis, or consent.

---

## Financial services

**The problem:** account takeover, card-not-present abuse, scripted credential testing, and high-risk account changes require more context without turning every new device into a denial.

**When to use:** collect at login or session establishment and re-check or look up context at the protected transaction, payout, recovery, credential change, or beneficiary change.

**The signal:** device familiarity, browser consistency, network context, automation reasons, available integrity status, risk, and confidence can corroborate the institution's authentication, transaction, account, and fraud controls.

### How the signal compounds

- **Device context:** familiar, new, changed, or unavailable device history.
- **Automation/tampering context:** reasons that indicate scripted or inconsistent access.
- **Infrastructure context:** reputation and network-type evidence, interpreted with VPN and mobile-network exceptions.
- **Customer context:** transaction value, account history, authentication strength, recovery state, and your confirmed fraud labels.

A new device is common and must not be treated as proof of takeover. The value comes from combining it with the protected action and other evidence.

### Configure and use

1. Associate the device handle with the authenticated session on your trusted backend.
2. Create a narrowly scoped server key for eligible device or assessment reads.
3. Define separate policies for login, payment, recovery, and irreversible account changes.
4. Use shadow evaluation before enforcing and review distributions by client and journey.
5. Route eligible cases into your existing fraud or manual-review workflow through a supported event sink, webhook, export, or API integration.

### The policy

Keep normal authentication in force for every tier. A familiar low-risk session can follow the ordinary path. A new or elevated-risk session can require a stronger factor or review. A missing result, low confidence, or unavailable module should follow an explicit unknown path rather than being silently allowed or blocked.

### Expected output

Your backend receives the supported risk/device response; authorized operators can review reasons, timestamps, policy actions, and eligible investigation context in Backoffice. Optional mobile or hardware attestation adds corroborating integrity status on supported, entitled clients.

### The outcome

Measure confirmed fraud, review precision, step-up volume and completion, payment or recovery abandonment, customer-support contacts, reversals, latency in your actual path, and error/unknown rates. No chargeback reduction, false-positive rate, latency, or customer-friction result is guaranteed by this pattern.

### Limitations

Noxtica is not authentication, transaction authorization, sanctions screening, or a guarantee of account ownership. Device changes, browser restrictions, network mobility, third-party provider availability, and traffic drift can affect output. Mobile attestation, identity, advanced reputation, and event delivery are separately eligible capabilities.

---

## Identity-sensitive platforms

**The problem:** login links, passwordless flows, account recovery, credential enrollment, and identity-evidence journeys can be relayed, initiated on one device and completed on another, or interrupted for legitimate reasons.

**When to use:** capture context at both initiation and completion when the workflow needs continuity, and apply stronger authentication when the context changes or evidence is incomplete.

**The signal:** compare the tenant-scoped device handles and available assessment context at both points. If the identity module is included, its case or evidence status can be combined with device risk; neither should silently substitute for the other.

### How the signal compounds

- **Initiation context:** device handle, time, risk, confidence, and protected workflow state.
- **Completion context:** the same fields collected when the link or challenge is completed.
- **Continuity:** match, change, missing result, expired record, or low-confidence comparison.
- **Authentication/identity context:** your factor result or an eligible provider/case result.

A mismatch can mean relay abuse, but it can also mean a user moved from desktop to phone, changed browsers, or opened mail elsewhere. Treat it as a reason for step-up—not automatic guilt.

### Configure and use

1. Store the initiation device handle with the short-lived workflow record on your backend.
2. Collect again at completion and compare through the supported server or console surface.
3. Define an explicit expiration and unknown-device path.
4. If using identity, liveness, passkeys, recovery, mobile attestation, or review queues, confirm each sub-flow is entitled and configured for the supported client and jurisdiction.
5. Keep evidence access, retention, deletion, and appeal responsibilities in the workflow design.

### The policy

A matching, sufficiently evidenced context can proceed under normal authentication. A changed, missing, low-confidence, or elevated-risk context should receive the additional factor appropriate to the action. High-impact recovery or credential changes should not rely on device continuity alone.

### Expected output

The application can consume device comparison and risk inputs; eligible identity flows can add case state, evidence-processing or provider status, integrity context, review disposition, and audit history.

### The outcome

Measure successful legitimate completion, step-up completion, relay or takeover confirmations, recovery time, support contacts, accessibility exceptions, expiry rate, manual-review yield, and appeal reversals. The expected value is a consistent escalation path, not a promised fraud-reduction number.

### Limitations

A matching browser installation is not legal identity proof, and a mismatch is not proof of attack. Identity and liveness results are bounded by the configured provider, evidence, device, geography, and contract. Noxtica does not replace your authorization and recovery controls.

---

## AI agents and crawler access

**The problem:** site owners want to admit useful automated agents while limiting unknown, unverifiable, or disallowed automation. User-agent strings alone do not provide a durable trust decision.

**When to use:** use Know Your Agent for supported signed-agent traffic when the module is active. Use ordinary bot/risk controls for unsigned automation. Use read-only MCP only when _your own_ external agent needs scoped Noxtica context; MCP does not identify inbound crawlers.

### How the signal compounds

- **Agent verification:** supported credential verification can establish an agent identity state.
- **Tenant policy:** the verified identity can be allowed, denied, or observed by your tenant policy.
- **Route context:** different content or APIs can apply different actions.
- **Risk context:** device, network, automation, and request context can still matter after identity is verified.

### Configure and use

1. Enable the eligible Agentic Security/KYA module for the tenant.
2. Define allowed, denied, and unknown agent treatment.
3. Attach the policy to selected routes and start in observe-only mode.
4. Review verified, failed, and unknown traffic before enabling challenge or block actions.
5. If connecting your own agent over MCP, mint a separate scoped, rate-limited token and review its audit history.

### The policy

Separate identity from authorization. A verified agent can still be denied on a sensitive route; an unknown agent can remain observable rather than automatically blocked. Apply payment or crawl-monetization workflows only if separately offered and contracted.

### Expected output

KYA provides verified, unverified, allowed, denied, or unknown agent context plus the resulting customer policy action and audit record. MCP provides scoped read-only responses about eligible Noxtica state.

### The outcome

Measure wanted-agent success, unknown and failed-verification volume, content/API load, blocked unwanted automation, policy exceptions, support requests from agent owners, and route-specific errors. The expected value is explicit machine-traffic governance, not proof of an agent's benign intent.

### Limitations

Agent verification proves the supported credential check, not who ultimately controls the software or whether a request is safe. Protocol and agent support vary. KYA, MCP, enforcement, and crawl-commercialization capabilities have separate eligibility and configuration boundaries.

---

## Account takeover evaluation

Evaluate login and account-recovery decisions with a synthetic interaction before you change a live policy. Account takeover is a hypothesis to evaluate: ordinary customer behavior can create the same surface patterns as abuse, and a familiar environment does not prove the account is safe. One unusual signal is not proof of compromise.

Your application marks the consequential interaction. Noxtica returns the supported assessment context and the evidence state available for that interaction. Your authentication, recovery, and authorization controls remain responsible for the decision. For the wider pattern around payments and account changes, see [Financial services](https://noxtica.com/docs/use-cases/#financial-services).

### Login and recovery workflow

A login or recovery attempt can look unfamiliar for many reasons. Keep the action, the evidence state, and your application policy separate so you can review and reverse the result.

1. **Mark the consequential interaction.** Identify whether your application is evaluating a login or an account-recovery attempt. Attach the permitted server-side context that decision needs, and nothing more. Input: a bounded login or recovery event.
2. **Inspect what is known and what is not.** Read the assessment, its reasons, and the availability of contributing evidence together. Missing or failed evidence stays visible instead of becoming a reassuring result. Output: assessment context with evidence state.
3. **Apply your recovery and access policy.** Your application decides whether to continue, ask for an additional check, send the interaction to review, or stop it. The Noxtica result is an input, not authorization on its own. Decision: owned and recorded by your application.

### Evidence states for login and recovery

Absence is not the same as safety. Your evaluation must preserve the difference between an observed input, an input that was not supplied, and a check that could not complete.

| State | What it means | What you do |
| --- | --- | --- |
| Evidence present | A supported input contributed context. | Review which evidence was available, why it contributed, and whether your application has enough context to apply its chosen policy. |
| Evidence missing | An expected input was not supplied. | Treat the gap as unknown. Do not turn an omitted, blocked, or uncollected input into a low-risk signal. |
| Evidence unavailable | A check could not produce a result. | Keep timeout, unsupported, and processing-failure paths distinct so your application can use an explicit fallback. |

The server-side result states follow the same rule; see [Backend integration](https://noxtica.com/docs/backend-integration/#handle-transport-before-risk).

### Benign explanations for unfamiliar logins

Suspicious context still needs an explanation. These explanations are plausible and benign:

- A customer signs in from a replacement device, a newly installed browser, or after clearing local data.
- Travel, mobile routing, a corporate network, or a privacy service changes the apparent network context.
- A legitimate customer starts recovery after losing access to a device or password manager.
- Accessibility, privacy, or browser settings prevent an otherwise expected input from being collected.

### What cannot be inferred about an account

- A valid password or familiar device does not prove that the person is the account owner.
- A new device, network change, or automated pattern does not by itself prove compromise.
- Missing or unavailable evidence does not mean low risk and must not be displayed as safe.
- Risk context does not replace authentication, multi-factor checks, authorization, or a secure recovery process.

### Access and recovery policy

Your application owns access and recovery policy. Define the allow, additional-check, review, and stop paths in your own policy. Keep the fallback explicit when evidence is missing or unavailable, and preserve a route for legitimate customers to complete recovery.

### Implementation boundary for login and recovery

This guide does not promise a deployment mode, response time, or automatic enforcement. Scope the evaluation around the current reviewed integration and the data your application is permitted to process. [Backend integration](https://noxtica.com/docs/backend-integration/) covers the server-side lookup.

1. Verify the interaction result on the server before it can influence an access or recovery decision.
2. Limit collection to disclosed and permitted inputs; document purpose, access, retention, deletion, and unavailable behavior.
3. Define timeout, error, missing-evidence, and unsupported-client fallbacks before you observe representative traffic.
4. Keep policy changes reversible and require application-owner approval before you add customer friction.

### Evaluation plan for login and recovery

Measure abuse and legitimate recovery together. Start with a bounded login or recovery journey and outcomes your team can verify. The goal is an evaluation plan, not a promised reduction.

1. Confirmed unauthorized-access outcomes among interactions with a known final disposition.
2. Legitimate login and recovery completion, including additional-check abandonment and support escalation.
3. Review volume and time for cases that remain uncertain after you inspect the available evidence.
4. Coverage of missing, unavailable, timeout, and unknown-outcome paths rather than silently dropping them.

Define labels, observation window, population, simultaneous policy changes, and stop conditions before you interpret the evaluation. Page visits or form submissions are not product-effect evidence.

---

## Signup abuse evaluation

Evaluate repeated signup and promotion abuse with a synthetic account-creation or promotion-eligibility interaction before you change a live rule. Related-looking activity can guide investigation; it does not prove one person or one intent. Shared context does not prove a shared actor.

Your application marks the signup or promotion decision. Noxtica returns the supported assessment context and the evidence state available for that interaction. Your application remains responsible for account creation, promotion eligibility, and any additional check. For marketplace-style repeated accounts, see [Marketplaces](https://noxtica.com/docs/use-cases/#marketplaces).

### Signup and eligibility workflow

A repeated or related signup can be abusive, accidental, or expected. Evaluate the interaction in context before an application rule changes account access or promotion eligibility.

1. **Mark the signup decision.** Identify whether your application is evaluating account creation, a referral, a trial, or promotion eligibility. Attach the permitted context that rule needs, and nothing more. Input: a bounded signup or eligibility event.
2. **Inspect evidence and uncertainty.** Read the assessment, the contributing reasons, and the evidence availability together. Similarity can identify a question for review without becoming a claim about identity or intent. Output: assessment context with evidence state.
3. **Apply your account and promotion rules.** Your application decides whether to continue, ask for an additional check, limit an incentive, queue review, or stop the attempt. The policy and the customer-remedy path remain yours. Decision: owned and recorded by your application.

### Evidence states for signup

Repeated-account evaluation is especially sensitive to missing context. Keep gaps visible before you compare activity, and preserve what was observed, what was not supplied, and what could not be evaluated.

| State | What it means | What you do |
| --- | --- | --- |
| Evidence present | A supported input contributed context. | Review the available context and its reason before an account or incentive rule treats the interaction differently. |
| Evidence missing | An expected input was not supplied. | Do not treat an absent attribute as proof that the signup is isolated, related, legitimate, or abusive. |
| Evidence unavailable | A check could not produce a result. | Keep unsupported, timeout, and processing-failure paths distinct so the signup flow can use a reviewed fallback. |

### Benign explanations for related signups

Signup and promotion policy can affect legitimate customers at the start of a relationship. Review these plausible benign explanations and your recovery paths before you add friction or deny eligibility.

- People in one household, classroom, workplace, or public venue share a device or network legitimately.
- A customer retries after a form, email, payment, or verification step fails to complete.
- Corporate routing, mobile carriers, privacy services, and accessibility tools make unrelated signups look similar.
- A promotion legitimately permits separate people, teams, or accounts under terms your application defines.

### What cannot be inferred about related signups

- Matching or related attributes do not prove that two accounts belong to the same person.
- Automation context does not by itself prove harmful intent or a promotion-policy violation.
- Missing or unavailable evidence does not prove that a signup is isolated or legitimate.
- Risk context does not replace account verification, promotion terms, appeals, or customer support.

### Account and promotion policy

Your application owns account and promotion eligibility. Define which repeated activities are permitted, which require an additional check, and how a legitimate customer can correct or appeal a decision. Noxtica context does not create the promotion rule or identify a person on its own.

### Implementation boundary for signup

This guide does not promise identity certainty, automatic blocking, response time, or a deployment mode. Scope the evaluation around current reviewed integration surfaces and your published account and promotion terms.

1. Verify the interaction result on the server before it can influence account creation or incentive eligibility.
2. Limit collection to disclosed and permitted inputs; document purpose, access, retention, deletion, and unavailable behavior.
3. Define retry, duplicate, shared-environment, timeout, error, and unsupported-client handling before you change policy.
4. Start with observation and reversible review paths; application owners approve any rule that adds friction or denial.

### Evaluation plan for signup

Measure policy violations and legitimate completion together. Start with one bounded signup or promotion rule and outcomes your team can verify. The goal is to understand tradeoffs, not promise a result.

1. Confirmed account or promotion-policy violations among interactions with a known final disposition.
2. Legitimate signup completion, additional-check abandonment, appeals, and support escalation.
3. Review volume and time for possible related activity that remains uncertain after inspection.
4. Coverage of shared-environment, retry, missing, unavailable, and unknown-outcome paths.

Define the policy, labels, observation window, population, simultaneous changes, and stop conditions before you interpret the evaluation. Page visits or form submissions are not product-effect evidence.

---

## Pattern: when to block, when to challenge

Across these use cases, use the same decision sequence rather than a universal threshold:

1. **Is a valid result available?** Handle missing, expired, errored, or unsupported output explicitly.
2. **How confident is it?** Limited evidence should move the action toward defer, ordinary controls, or reversible step-up.
3. **Which reasons agree?** One network, privacy, new-device, or behavior reason is rarely enough for a consequential decision.
4. **What is the route's value and reversibility?** Reading content, redeeming a promotion, moving funds, and changing credentials need different policy.
5. **What customer safeguard exists?** Provide an accessible challenge, manual review, appeal, or recovery path.
6. **What does your shadow and labeled traffic show?** Promote only after reviewing both abuse coverage and legitimate-user friction.

A common starting map is low/minimal → allow under normal controls, medium → observe or low-friction step-up, high → challenge/hold/review, and critical → strong challenge or block under a reviewed rule. It is an example, not a default promise.

## Production readiness checklist

- Required account, tenant, domain, role, module, client, quota, and contract eligibility confirmed.
- Exact collection, optional-signal, consent/legal-basis, retention, redaction, and destination settings reviewed.
- Browser result and trusted backend lookup/error paths implemented without exposing secret keys.
- Unknown, low-confidence, provider-down, quota, and rate-limit behavior documented.
- Shadow results compared with confirmed outcomes and customer-friction measures.
- Support, appeal, recovery, rollback, and policy ownership assigned.
- Alerts, exports, event sinks, and investigations limited to necessary data and authorized recipients.

## Related reading

- [Customer capability reference](https://noxtica.com/docs/features/) — how, outputs, eligibility, and limits for each family.
- [Threat categories](https://noxtica.com/docs/threat-categories/) — public reason families used in these patterns.
- [Why calibration, not verdicts](https://noxtica.com/docs/why-calibration/) — design the risk/confidence policy.
- [Engineering principles](https://noxtica.com/docs/principles/) — review the operating constraints before enforcement.
- [Backend integration](https://noxtica.com/docs/backend-integration/) — trusted lookups and error handling.