Configurable data residency
From evidence to your decision.
A guided tour of the engine behind the score — how the browser is read, turned into a calibrated risk read, and handed back to your code. Follow it end to end: the signals we measure, the threats we catch, and the outcomes behind every call.
Every device tells a story. We catch the fictions.
Stop fraud and bots without challenging the customers you worked hard to win. Get a clear risk read on every visitor — and decide what to do with it.
Agentic security and risk intelligence, now built for the agentic web — operate your console with a built-in AI assistant, let your agents read Noxtica over a read-only MCP server, and verify and observe the agents you interact with.
THE PUBLIC MODEL
From evidence to a customer-owned decision
Noxtica frames this path as Agentic Security & Risk Intelligence: understand the risk of the current interaction without collapsing identity, evidence, policy, and action into one black-box verdict.
Gather available evidence
Browser, network, device, behavior, and supported identity or agent verification add context. Availability depends on the browser, deployment, enabled modules, and applicable privacy or consent controls.
Read the interaction
The available evidence becomes an explainable risk read with score, confidence, and reasons. It describes risk; it does not prove identity, intent, fraud, or safety.
Apply your policy
Your team combines the read with route, account, transaction, and authorization context, then chooses whether to allow, observe, step up, review, or block.
Keep assistance bounded
The AI Assistant and MCP help eligible operators and workflows read approved context. Optional browser enforcement follows customer-configured policy; these tools do not autonomously rewrite it.
Trace one risk-bearing interaction from evidence to accountable action.
Noxtica uses Agentic Security & Risk Intelligence to describe this architecture: assess the available context around a policy-relevant action, return an explainable risk read, and let the customer’s application or configured policy decide what happens next.
An observable, customer-owned decision workflow
INTERACTION
Bind the assessment to a business event.
Capture context where uncertainty matters—a signup, login, checkout, recovery change, promotion, or agent request—and keep the result beside the route and event it informs.
EVIDENCE
Read risk, confidence, and reasons together.
Inspect which supported evidence was available and distinguish a scored result from suppressed, missing, low-confidence, or unavailable states. Optional signals and modules remain subject to eligibility, consent, and policy.
POLICY
Map context to a proportionate customer action.
Combine the read with account, authentication, transaction, and journey context, then define when to allow, observe, step up, review, or block. A verified identity or agent is context, not proof of safe intent.
OUTCOME
Keep the reason trail with the eventual result.
Compare the proposed and final actions with confirmed abuse, challenge completion, abandonment, review work, appeals, reversals, and error states. Change thresholds deliberately from your labeled evidence.
Where adjacent tools fit in the workflow
The categories below can complement one another. Evaluate the evidence handoff, failure states, and policy owner instead of asking one product to perform every job.
- Identity-only lookup
- Use recognition and authentication to establish the claims your journey needs. Add interaction context when the current action also requires risk, confidence, reasons, and an explicit unknown path.
- Perimeter and bot controls
- Keep broad controls at the edge or perimeter. Feed additional context into routes where one uniform rule is too coarse for the business decision.
- Analytics and replay tooling
- Use journey and replay evidence to investigate what users experienced where those capabilities are eligible and consented. Pair it with the policy record when you need to review the action taken.
EVALUATE THE HANDOFF
- FRAUD & RISKCan reviewers explain why the read changed?
- Check reason usefulness, unknown-state handling, route-specific thresholds, and how the read changes triage without treating one signal as proof.
- ENGINEERINGIs the integration safe under failure?
- Verify browser states, authenticated server reads, deadlines, quotas, module availability, and the fallback for blocked collection or provider errors.
- BUSINESSDoes the policy improve the whole trade-off?
- Judge confirmed unwanted activity together with customer friction, review and support load, reversals, and operating ownership. The score alone is not the outcome.
From signal to decision.
Four stages. The browser is read, the result is handed safely to your backend, your server gets a clear risk read, and your code makes the call.
A lightweight script reads the visitor's browser the moment they land — quietly, without slowing your page down.
What it sees is handed safely to your backend — it can't be faked, copied, or replayed on the way.
Your server checks it and gets back a clear risk read, with the reasons behind it — about 500 ms in native mode or from TTL cache, and about 700 ms–1.2 s for a fresh KHAN read.
Your code makes the call: block, challenge, watch, or wave through. Your policy, your context, your decision.
One risk read. The reasons attached.
87
Low risk — allow
Illustrative sample — not live traffic.
Why we don't tell you 'this is a bot.'
Most tools tell you what you want to hear: bot or human. Clean, simple, and often wrong — with no way to see how they got there. You either trust the answer or you don't.
Real customers and real attackers can look surprisingly alike. The useful question isn't 'is this a bot' — it's 'how unusual is this visitor, and how hard would the suspicious parts be to fake?' That's what we answer.
// We don't just say 'this is a bot.'
// We give you a clear risk read — and the reasons.
// You decide.
When a flag lands on a real customer, your team can explain it — to legal, to product, to the customer. Every decision comes with its reasons, so there's nothing to take on faith and nothing you can't tune.
You don't get a black-box yes/no. You get a clear risk read, a confidence level, and the reasons behind both — the receipt. The final call is yours, because only your team knows what's at stake.
Most tools hand you a yes/no and hide how they got there. We give you a clear risk read, with the reasons — and let your team make the call.
Five clear levels, not a blunt yes/no — and never a silent block.
What we measure.
We read four things about every visitor — the browser, the network, the device, and how the person behaves. Together they tell a real customer apart from a clever fake.
Is the browser real?
Browser intelligence
Catch automated traffic, masked browsers, and synthetic visitors the moment they arrive — before they reach your signup, login, or checkout. Real customers pass through. Fake ones don't.
Is the network safe?
Network signals
Spot suspicious origins and high-risk infrastructure without punishing legitimate traffic. Remote workers, VPN users, and corporate networks stay welcome. Wholesale fraud sources get flagged.
Is the device real?
Hardware verification
Verify the real device behind the session — not just the software running on it. Genuine users on genuine devices breeze through. Bots running on shared, throwaway infrastructure surface immediately.
Is the user real?
Behavioral fingerprints
Tell a real person from a script by the rhythm of how they interact with the page. Humans hesitate, correct themselves, and explore. Automation moves with a tell-tale precision it can't hide.
And one we verify: Know Your Agent
These four layers measure visitors. AI agents and bots are different — you need to verify their identity and observe their activity. Know Your Agent does that per tenant by JWK thumbprint or Signature-Agent host, integrated with Web Bot Auth verification. Enforcement is on the roadmap.
What we catch.
The threats that cost you — automation, fraud, and abuse — caught without false-positively challenging real customers.
Catching fraud isn't a single check. Real-world abuse blends automated traffic, suspicious origins, and behavior that doesn't add up. We turn all of it into the kind of decision your team actually makes — block, challenge, allow, observe.
Bots & automated traffic
Headless browsers, browser-automation frameworks, and scripted abuse — including the 'stealth' variants designed to evade detection. The fast lane and the slow lane both get caught.
Recognize automated traffic before it reaches login, signup, or checkout.
Sessions that hide what they are
Sessions where the browser is lying about its own fingerprint. Spoofed canvas output, manipulated runtime APIs, anti-fingerprint extensions running aggressive countermeasures.
Surface deliberate evasion attempts without blocking honest privacy choices.
Suspicious origins
Traffic originating from datacenters, anonymizing proxies, deprecated protocols, and known-bad ranges. We flag the patterns without blocking real users who happen to be on a corporate VPN.
Identify the wholesale-fraud signal — without misfiring on remote workers.
Privacy users, treated fairly
Tor, Brave Strict, Firefox-RFP, LibreWolf — recognized and treated with calibrated leniency. Privacy-conscious users stay welcome; bots hiding behind privacy browsers do not.
Welcome legitimate privacy users while still catching the actors hiding among them.
Fake & throwaway devices
We look past the browser to the device itself, so emulators and throwaway virtual machines can't pose as real hardware. The bots that beat browser-only checks get caught here.
Verify the device is what it claims to be — not just the browser running on it.
Activity that doesn't behave human
How a person moves, types, and scrolls looks nothing like a script. Real people hesitate and explore; automation gives itself away with tell-tale precision.
Catch the sessions that look human on paper but don't behave like a person.
A visitor's request is read across the threats we catch, which combine into a single clear risk read.
- Browser request
- Clear risk read
- Your decision
Each one gives you a clear risk read and a confidence level — not a blunt yes/no. Your team owns the final call. We just make sure what you're acting on is honest.
See what we catch.
Six attack patterns, each derived from a threat category above — replayed to show the calibrated risk read and the call it drives.
- Headless automation flood
94/ 100 risk
BLOCKEDread in 410msA wave of headless, scripted sessions hitting login in lockstep.
- Spoofed-fingerprint session
78/ 100 risk
STEP-UPread in 470msA browser lying about its own canvas output and runtime APIs.
- Datacenter proxy origin
86/ 100 risk
BLOCKEDread in 350msA request routed through an anonymizing datacenter range.
- Privacy-browser visitor
24/ 100 risk
ALLOWread in 340msA real person on a hardened privacy browser — waved through.
- Throwaway virtual machine
90/ 100 risk
BLOCKEDread in 520msAn emulated device posing as real consumer hardware.
- Non-human interaction pattern
71/ 100 risk
STEP-UPread in 430msA form filled with tell-tale precision no person types with.
Illustrative patterns derived from the categories above — not customer data. Scores sit on the same 0–100 scale your policy acts on.
Held the line on fraud. Kept customers moving.
Numbers from an early design partner's rollout — shared anonymously
- 47%chargebacks a design partner cut in their first 90 days
- 99.6%of real customers waved through untouched in that rollout
- ~500 msverdict latency for cached checks
$ noxtica use-case --marketplaceMarketplace
Marketplaces use Noxtica to catch coordinated fake-account rings before they bury honest sellers in fake reviews. Different logins, different addresses — but the same automated setup gives them away.
Fake-account rings caught before they bury your honest sellers.
$ noxtica use-case --financialFinancial services
Card-not-present merchants use Noxtica to add a quick extra check only when a payment looks like it's coming from somewhere new. Real customers feel nothing; fraud rings hit a wall on every attempt.
An extra check only when it's warranted. Real customers feel nothing.
$ noxtica use-case --identityIdentity-sensitive platforms
Passwordless and magic-link platforms use Noxtica to make sure the link is opened by the same person who asked for it. Phishing kits that relay the link to someone else get stopped at the door.
Magic links open only for the person who asked. Phishing stops here.
Four audiences. One signal.
Agentic security and risk intelligence are rarely just about one team. The same signal shapes outcomes for businesses, platforms, and the people who use them.
For companies
Fraud teams, security engineers, platform PMs. The teams that pay when fraud lands and the teams that pay when real customers churn.
- Cut chargebacks by catching fake signups before they cost you
- Spot account takeovers before the attacker gets in
- Audit-ready trails for SOC 2, ISO 27001, and GDPR
For platforms
Marketplaces, social networks, multi-sided platforms. Trust between users is the whole business — and stopping fake accounts at scale is your moat.
- Catch duplicate-account abuse without locking out real users
- Cut moderation load by surfacing only the accounts that look off
- Stop paid-review farms and review-bombing rings at signup
For people
End-users. The under-discussed stakeholder. The people who get false-positively challenged, blocked, or asked to solve CAPTCHAs for being on Brave.
- No CAPTCHAs unless something genuinely looks suspicious
- Real people on privacy browsers stay welcome, not punished
- No personal data collected. No tracking cookies. No cross-site identity.
For AI & agents
The agentic web. Verify and observe agents with Know Your Agent, run the console with a built-in AI assistant, and let your own agents read Noxtica over a read-only MCP integration.
Three honest ways we're agentic.
"Agentic" gets thrown around. Here's exactly what it means at Noxtica — three capabilities that ship today, with no autonomous changes to your systems.
We operate the console
A built-in AI assistant — powered by Claude, with OpenAI, Gemini, and xAI options — runs server-side under the operator session to read policies, rules, domains, and risk distribution for you, with per-tenant budget caps and full audit logging.
How the assistant works →Your agents read Noxtica
An opt-in, read-only Model Context Protocol (MCP) server lets your own AI agents read policies, rules, alerts, and risk distribution over JSON-RPC, using scoped, rate-limited, audited bearer tokens you mint — read access only, never write.
Read the MCP docs →Govern the agentic web
Know Your Agent (KYA) verifies and observes AI agents and bots per tenant by JWK thumbprint or Signature-Agent host, integrated with Web Bot Auth verification. Policy enforcement is on the roadmap.
Explore Know Your Agent →
Where we're headed
We're building toward self-calibration and feedback loops; today operators tune policies and thresholds with full control.
Built to clear security review.
The security posture reviewers ask about — six controls you can check yourself, not take on faith.
GDPR-ready
Documented integration
Privacy controls
Evaluate on your traffic
A clear read, not magic
Fingerprint and server metadata can be personal data. Evaluate the selected modules, lawful basis, consent where required, redaction and retention settings for your deployment.
A partner, not a pricing page.
Everything you need to ship with confidence — and nothing you don't.
What's included
- Transparent pricing — published, not gated behind a demo
- Hands-on onboarding from real engineers
- GDPR-compliant, configurable data residency, SOC 2-ready
- Direct human support — no sales sequence
Questions teams ask first.
The things buyers and engineers want to know up front. The full technical FAQ — bundle size, the API, iframes, thresholds — lives in the docs.
Will this wrongly block my real customers?
That's exactly what we build against. A blocked customer rarely comes back, so the defaults lean cautious: we'd rather let a bot slip than wrongly stop a real person. You get a clear risk read and decide how strict to be — and you can dial it tighter or looser as you learn your own traffic.
Does it work for privacy-minded users — Brave, Tor, LibreWolf?
Yes, and they stay welcome. Privacy browsers don't break anything; we simply recognize them and treat them fairly instead of silently punishing the person behind them. If your product is built for sensitive audiences, you can choose to give those users extra leeway.
What if Noxtica has an outage?
Your site keeps working. If a check can't reach us in time, you get a safe default back so your code can fall back gracefully — challenge instead of block, for example — rather than locking anyone out. We commit to 99.95% uptime and publish a public status page.
Do we need engineers to run this?
A little. A small script goes on your site and a single check happens on your server when you want a decision. There's nothing to host, nothing to keep running, and the heavy lifting is on us. Most teams are live in an afternoon — the step-by-step guide is in the docs.
Is it compliant — GDPR, CCPA, EU data?
Yes. We collect only the signals a check needs, store fingerprints as one-way hashes and no raw IP by default, and keep data in the EU. We'll sign a data-processing agreement, support hard-delete on request, and publish our subprocessor list. Your privacy and legal teams get straight answers, not hand-waving.
More in the docs — bundle size, the API, iframes, threshold tuning, and the full technical Q&A.→ Read the docs: full technical FAQ