Dark
Request a walkthrough
On this page
Developer overview

Agentic Security & Risk Intelligence

Noxtica uses Agentic Security & Risk Intelligence to describe the layer that connects available runtime and verification evidence to an explainable risk read for a specific digital interaction. Your policy decides what happens next.

Agentic Security & Risk Intelligence is Noxtica’s product framing. This page does not present it as an established industry standard, legal classification, or proof of market leadership.

A digital interaction is a context-bound action or flow: creating an account, signing in, recovering access, checking out, changing a sensitive setting, or an agent calling a protected route.

Key points

  1. A read for one interactionIt connects available evidence to an explainable risk read for one digital interaction. Your policy decides what happens next.
  2. Product framingIt is not presented as an industry standard, a legal classification, or proof of market leadership.
  3. One signal is evidenceOne unusual characteristic is not identity proof, intent, fraud, or permission to act.
  1. The unit of risk: start with the action that matters
  2. From evidence to risk to policy
  3. Compose, do not discard
  4. Current product boundary
  5. Three ways Noxtica is agentic today
  6. Evaluate on your traffic
  7. How this maps to the rest of the documentation
  8. Who it fits
  9. How teams connect
  10. Limits
  11. Common questions
  12. Related reading
How this page is organisedBar length shows each section’s share of the text. Select a section to jump to it.

The unit of risk: start with the action that matters

Risk is evaluated for a moment with business meaning. The same device, identity, or agent can appear in interactions with different context and different consequences.

  • Signup. Combine the available browser, device, network, and behavior evidence with the signup context. The resulting risk read can support normal passage, observation, or a customer-owned step-up path without treating one unusual signal as proof of abuse.
  • Login and recovery. Use the current environment and interaction evidence alongside your own authentication and account history. Risk can inform a reversible step-up or review, but it does not replace authentication, authorization, or recovery controls.
  • Checkout. Read browser, device, network, and behavioral evidence together, then combine it with the amount, account, payment, and fulfillment context your systems own. Your policy decides whether to continue, observe, step up, or review.
  • Agent interaction. Where Know Your Agent is provisioned, supported cryptographic identity evidence can add context to the interaction. Verification identifies a supported claim; it does not prove intent, delegated authority, or that every requested action is safe.

From evidence to risk to policy

Noxtica separates what can be observed, what the evidence suggests, and what your business chooses to do.

  1. Interaction evidence — observe what is available now. Collect supported browser, network, device, and behavior evidence. Add identity, reputation, transaction, or agent evidence only when the relevant module and customer workflow provide it. Output: evidence with context and provenance.
  2. Explainable risk read — interpret the evidence together. Noxtica returns a risk assessment with a named level, confidence, and available reasons. These fields are read together so uncertainty and contributing evidence stay visible. Output: risk, confidence, and reasons.
  3. Customer-owned policy — choose what the interaction requires. Your application, operator, or configured policy maps the read and your business context to an action. Eligible Browser Security deployments can apply reviewed directives; the policy and fallback remain yours. Outcome: allow, observe, step up, review, or block.

One unusual characteristic is evidence. It is not identity proof, intent, fraud, or permission to act.

  1. Evidence with context and provenance.

  2. Risk, confidence, and reasons.

  3. Allow, observe, step up, review, or block.

  1. Interaction evidence

    Collect supported browser, network, device, and behavior evidence.

  2. Explainable risk read

    Noxtica returns a named level, confidence, and available reasons, read together so uncertainty and contributing evidence stay visible.

  3. Customer-owned policy

    Your application, operator, or configured policy maps the read and your business context to an action.

From evidence to risk to policy, one stage at a time

Compose, do not discard

Identity, device, bot, agent, and fraud systems answer useful questions. Agentic Security & Risk Intelligence provides a shared frame for considering those answers at a specific action before policy responds. Evaluate the evidence handoff, failure states, and policy owner instead of asking one product to perform every job.

  • Identity and KYC: verify supported claims or evidence. The result can inform an interaction without becoming a permanent trust label or replacing application authorization.
  • Device intelligence: describe and compare the participating environment. Device continuity and integrity remain evidence about the current action, not proof of the person behind it.
  • Bot and automation controls: classify automation and infrastructure patterns. Interaction context helps policy distinguish expected automation, unknown traffic, and corroborated abuse.
  • Agent authentication: establish a supported signing identity where available. Route sensitivity, runtime evidence, authorization, and customer policy still determine how the action is treated.
  • Fraud and transaction systems: contribute account, payment, loss, and outcome context, then consume the interaction read as another explainable input to the business decision.

Current product boundary

The useful boundary is explicit: explainable interaction evidence now, customer-controlled action, and no claim of autonomous policy or automatic learning.

  1. Availability follows the deployment. Evidence classes and product surfaces vary by browser support, plan, role, tenant provisioning, jurisdiction, consent, legal basis, and enabled integrations. Confirm the modules required for your evaluation.
  2. Enforcement follows reviewed policy. The standard integration returns decision evidence to customer code. Optional Browser Security can execute customer-configured directives, including eligible challenge, block, or tarpit paths and shadow mode. It does not invent or autonomously change policy.
  3. AI remains operator-assisted and read-only. The AI Assistant summarizes permitted console context under the signed-in operator. The opt-in MCP surface exposes eligible tenant-scoped reads. Neither currently changes Noxtica configuration or acts on traffic.
  4. Calibration is operator-tuned today. Current scoring is operator-tuned rather than a self-learning model. Noxtica does not claim automatic learning from customer outcomes or self-directed threshold changes.
  5. Authentication does not prove intent. KYA can verify supported agent identity evidence and compare it with tenant policy. It does not prove a request is authorized, beneficial, or safe, and unknown agents require a customer-defined fallback.
  6. Privacy controls remain part of the system. Browser and device data can be personal data depending on law and use. Purpose, disclosure, legal basis, consent where required, retention, redaction, and domain policy remain customer responsibilities. Optional behavioral, replay, biometric, and raw-network features require their own eligibility and review.

Three ways Noxtica is agentic today

“Agentic” gets thrown around. Here is exactly what it means at Noxtica: three capabilities that ship today, with no autonomous changes to your systems.

  • Noxtica operates the console. A built-in AI assistant 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. 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, using scoped, rate-limited, audited bearer tokens you mint — read access only, never write. See MCP Integration.
  • Noxtica governs 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. See Know Your Agent.

Noxtica is building toward self-calibration and feedback loops; today operators tune policies and thresholds with full control.

Evaluate on your traffic

A useful evaluation measures the risk read against outcomes your team can verify. It also tests unavailable states, customer friction, and the policy review path — not only successful collection.

  1. Choose one consequential journey and define the decision, fallback, and owner.
  2. Instrument scored, suppressed, missing, and unavailable result paths.
  3. Observe representative traffic before changing the customer experience.
  4. Join proposed actions with outcomes your team can verify, including false positives.
  5. Review thresholds by surface, introduce reversible step-up first, and promote policy gradually.

How this maps to the rest of the documentation

The “Agentic Security & Risk Intelligence” frame above is the product story that connects the following implementation-level docs. Start here, then go deeper on the piece you need:

I need to…Read
See the exact browser → server → policy flowIntegration Flow
Understand what each evidence layer contributesDetection Signals
Interpret the public reason familiesThreat Categories
Turn risk and confidence into policyWhy Calibration, Not Verdicts
Apply this to a specific journeyUse Cases
See the impact per audience (companies, platforms, people, AI & agents)Impact by Audience
Review every customer capability familyCustomer Capability Reference
Review Noxtica’s own security and trust evidenceSecurity and Trust Evidence

Who it fits

A risk read suits journeys where the cost of being wrong differs. The unit of risk walks through signup, login, checkout, and agent interactions, and Why calibration, not verdicts lists what to configure per surface. Evaluate on your traffic covers comparing what a policy did, or would have done, with confirmed outcomes before you change enforcement.

  • Abuse queue triage. Use reasons to prioritize reviews, protect expensive routes, and allow expected automation without loosening policy for everyone.

How teams connect

Scoring uses the same browser script and authenticated server lookup as Device Intelligence. Evaluation access is required. Three surfaces expose the read:

  • Browser script. The page callback exposes the read to your page code.
  • Authenticated server lookup. Your backend reads the current assessment with a server-held credential.
  • Operator console. Operators review distributions, reason categories, and calibration views. Navigation follows operator role and tenant scope.

Detection signals lists the fields each surface returns. Integration flow and Backend integration cover the steps.

Limits

Plan for these boundaries before you set a threshold. Current product boundary describes how availability, enforcement, AI, calibration, and privacy controls work today.

  • Evaluation access. Core scoring belongs to an activated web integration. Advanced calibration, metered scoring, and network reputation context depend on plan, role, and tenant configuration.
  • Enforcement is controlled. Challenge, limit, and block actions need controlled provisioning and explicit configuration for your tenant. Detection alone does not trigger them.
  • Estimates, not facts. A score does not prove a visitor is human, fraudulent, or safe. Output is probabilistic, and no accuracy or false-positive rate is promised. Your team makes the decision. Read the disclaimer.
  • Missing evidence is not low risk. Blocked scripts, privacy browsers, corporate networks, and assistive technology can hide evidence or resemble abuse. Treat unknown as unknown.

Common questions

Does Risk Scoring decide for me?

No. It returns evidence and a risk read, and your team chooses the action. Challenge, limit, and block actions need controlled provisioning; see Limits.

Can I see why an assessment scored the way it did?

Assessments carry named reasons, visible according to your role and the evidence gathered. Internal weights and detection mechanics are not published. See The reasons are the audit trail.

Does the score learn on its own?

No. Operators tune thresholds and policies today. Current product boundary has the full statement.