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.

The engine in four stages

Stage	What happens	Detail
01. Browser	A lightweight collector reads the visitor’s browser the moment they land, without slowing the page down.	Integration Flow → Customer client
02. Hand-off	What it sees is handed safely to your backend — it cannot be faked, copied, or replayed on the way.	Integration Flow → Noxtica processing
03. Risk read	Your server checks the available evidence and returns a reasoned assessment: score, five-level risk tier, confidence, and named reasons.	Detection Signals
04. Decision	Your 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.

Pattern	Score	Verdict	Read in
Headless automation flood — a wave of headless, scripted sessions hitting login in lockstep	94 / 100	Blocked	410 ms
Spoofed-fingerprint session — a browser lying about its own canvas output and runtime APIs	78 / 100	Step-up	470 ms
Datacenter proxy origin — a request routed through an anonymizing datacenter range	86 / 100	Blocked	350 ms
Privacy-browser visitor — a real person on a hardened privacy browser, waved through	24 / 100	Allow	340 ms
Throwaway virtual machine — an emulated device posing as real consumer hardware	90 / 100	Blocked	520 ms
Non-human interaction pattern — a form filled with tell-tale precision no person types with	71 / 100	Step-up	430 ms

Integration Flow — the full browser-to-policy evaluation, step by step.
Detection Signals — what each evidence layer contributes and how missing evidence affects confidence.
Threat Categories — public reason families and their interpretation limits.
Why Calibration, Not Verdicts — map risk and confidence to route-specific policy.
Agentic Security & Risk Intelligence — the product framing this engine supports.
Concepts & Glossary — agentic security, know-your-agent, MCP, and the assistant, explained.
Customer Capability Reference — every customer-facing capability, configuration, and limitation.