Dark
Request a walkthrough
On this page
Developer overview

Architecture: From Evidence to Decision

Every device tells a story. Noxtica reads the available evidence, checks whether that story holds together, and hands your application a clear, explainable risk read — not a black-box verdict. This page is the guided tour of that engine: how the browser is read, how it becomes a calibrated risk read, and where the outcome is handed back to your code. It connects the deeper implementation guides so you can follow the whole path end to end or jump straight to the stage you need.

Noxtica frames this as Agentic Security & Risk Intelligence, now extended for the agentic web: you can operate your own console with a built-in AI assistant, let your agents read Noxtica over a read-only MCP server, and verify and observe the agents that reach your application. See Agentic Security & Risk Intelligence for that product framing; this page stays focused on the mechanics.

Key points

  1. Four stagesBrowser, hand-off, risk read, decision. Your code makes the call: block, challenge, observe, or allow.
  2. Four things measuredThe browser, the network, the device, and how the person behaves. No single layer proves human, bot, or safe on its own.
  3. A read, not a verdictNoxtica separates what can be observed, what the evidence suggests, and what your business chooses to do.
  4. Bounded agent workflowsThree customer-controlled workflows extend the engine to AI agents, with no autonomous changes to your systems.
  1. The engine in four stages
  2. What we measure
  3. What we catch
  4. Why a read, not a verdict
  5. Governing the agentic web
  6. Example risk reads
  7. Related reading
How this page is organisedBar length shows each section’s share of the text. Select a section to jump to it.

  1. Your page

    Browser

    A lightweight collector reads the visitor's browser when they land.

  2. Noxtica

    Hand-off

    What it sees is handed safely to your backend.

  3. Your server

    Risk read

    A score, a five-level risk tier, confidence and named reasons.

  4. Your policy

    Decision

    Your code chooses: block, challenge, observe or allow.

The engine in four stages, from browser evidence to your decision

The engine in four stages

StageWhat happensDetail
01. BrowserA lightweight collector reads the visitor’s browser the moment they land, without slowing the page down.Integration Flow → Customer client
02. Hand-offWhat it sees is handed safely to your backend — it cannot be faked, copied, or replayed on the way.Integration Flow → Noxtica processing
03. Risk readYour server checks the available evidence and returns a reasoned assessment: score, five-level risk tier, confidence, and named reasons.Detection Signals
04. DecisionYour code makes the call — block, challenge, observe, or allow. Your policy, your context, your decision.Integration Flow → Customer policy

This is a summary, not a substitute for the implementation guide: follow Integration Flow for the full five-step evaluation checkpoint list, error handling, and rollout sequence.

What we measure

Noxtica reads 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; no single layer proves “human,” “bot,” or “safe” on its own.

  • Browser intelligence — is this browser context internally consistent?
  • Network signals — does the connection add risk context?
  • Device verification — does the environment and history support the claimed context?
  • Behavioral patterns — does eligible timing or journey context corroborate the rest?

See Detection Signals for what each layer can contribute, its common limitations, and how to configure the evidence you need.

What we catch

The threats that cost you — automation, fraud, and abuse — caught without false-positively challenging real customers: bots and automated traffic, sessions that hide what they are, suspicious origins, privacy users treated fairly, fake or throwaway devices, and activity that doesn’t behave human. Each one gives you a risk read and a confidence level, not a blunt yes/no — your team owns the final call.

See Threat Categories for the public reason families, their appropriate uses, and their common false-positive boundaries.

Why a read, not a verdict

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. Noxtica separates what can be observed, what the evidence suggests, and what your business chooses to do — 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?”

See Why Calibration, Not Verdicts for how to turn risk and confidence into route-specific policy.

Governing the agentic web

Three bounded, customer-controlled workflows extend this engine to AI agents, with no autonomous changes to your systems:

  • Noxtica operates the console. A built-in AI assistant reads policies, rules, domains, and risk distribution for you under the operator session, with per-tenant budget caps and full audit logging. See AI Assistant.
  • 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 — read access only, never write. See MCP Integration.
  • Noxtica governs incoming agents. 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. See Know Your Agent.

See Agentic Security for how these three workflows relate, and Agentic Security & Risk Intelligence for the product framing that connects them to the risk read above.

Example risk reads

Illustrative patterns derived from the threat categories above — not customer data. Scores sit on the same 0–100 scale your policy acts on.

PatternScoreVerdictRead in
Headless automation flood — a wave of headless, scripted sessions hitting login in lockstep94 / 100Blocked410 ms
Spoofed-fingerprint session — a browser lying about its own canvas output and runtime APIs78 / 100Step-up470 ms
Datacenter proxy origin — a request routed through an anonymizing datacenter range86 / 100Blocked350 ms
Privacy-browser visitor — a real person on a hardened privacy browser, waved through24 / 100Allow340 ms
Throwaway virtual machine — an emulated device posing as real consumer hardware90 / 100Blocked520 ms
Non-human interaction pattern — a form filled with tell-tale precision no person types with71 / 100Step-up430 ms

Blocked

  • Headless automation flood: a wave of headless, scripted sessions hitting login in lockstep.
  • Datacenter proxy origin: a request routed through an anonymizing datacenter range.
  • Throwaway virtual machine: an emulated device posing as real consumer hardware.

Step-up

  • Spoofed-fingerprint session: a browser lying about its own canvas output and runtime APIs.
  • Non-human interaction pattern: a form filled with tell-tale precision no person types with.

Allow

  • Privacy-browser visitor: a real person on a hardened privacy browser, waved through.
The example risk reads, grouped by the decision they end inIllustrative patterns, not customer data.