Dark
Request a walkthrough
On this page
Developer overview

Browser Security

Definition. Browser Security is the decision and enforcement layer. Browser Intelligence supplies an assessment; your application or a separately provisioned policy surface decides what that assessment means for a particular route.

The problem it solves is inconsistent response. Without an explicit policy, teams either ignore useful risk evidence or apply one blunt threshold everywhere. Browser Security keeps the risk input separate from the business action so a public page, signup, account recovery, and payment flow can use different responses.

Key points

  1. The decision layerBrowser Intelligence supplies an assessment; your application or a separately provisioned policy surface decides what that assessment means for a particular route.
  2. Different routes, different responsesA public page, signup, account recovery, and payment flow can use different responses.
  3. Observe before you enforceUse Browser Security after you can observe representative traffic and explain the fields your policy consumes.
  4. Shadow modeWhere available, shadow mode records what a policy would have done without applying the traffic action.
  5. Not proofA risk output is not proof of identity, intent, fraud, or policy compliance.
  1. When it applies
  2. How customers use it
  3. How Noxtica does it
  4. How outputs inform decisions
  5. Eligibility and limitations
  6. Where it fits
  7. Read deeper
How this page is organisedBar length shows each section’s share of the text. Select a section to jump to it.

  1. Browser Intelligence

    Supplies an assessment

    Score, risk level, confidence and flags for the session.

  2. Your policy

    Decides what it means

    Route sensitivity, risk level, confidence, flags, and your own account or transaction context.

  3. Per route

    Takes an action

    Allow, observe, challenge or step up, block. Tarpit, where provisioned.

The assessment is the input; the action is yours

When it applies

Use Browser Security after you can observe representative traffic and explain the fields your policy consumes. It is most useful on routes where automation, account abuse, or transaction risk has a defined response and owner.

For a first rollout:

  1. collect the browser result;
  2. record score, risk level, confidence, flags, route, and customer outcome;
  3. review the distribution by surface;
  4. define the least disruptive useful action for each band; and
  5. enable enforcement only after owners agree on fallback and review procedures.

  1. Collect

    Collect the browser result.

  2. Record

    Record score, risk level, confidence, flags, route, and customer outcome.

  3. Review

    Review the distribution by surface.

  4. Define

    Define the least disruptive useful action for each band.

  5. Enable

    Enable enforcement only after owners agree on fallback and review procedures.

A first rollout, one step at a time

How customers use it

A tenant can implement customer-owned policy in backend code using the documented risk output. Eligible tenants may also have managed risk-action controls in the product.

Common actions are:

  • Allow — continue the normal path.
  • Observe — retain the assessment for analysis without adding friction.
  • Challenge or step up — ask the application to perform additional verification. Your application owns the actual second factor or challenge.
  • Block — deny the requested operation and retain enough context for review.
  • Tarpit — where provisioned, slow a class of abusive traffic under an explicit policy.

Choose an action from the combination of route sensitivity, risk level, confidence, flags, and your own account or transaction context. Do not block solely because one browser characteristic is unusual.

How Noxtica does it

The product represents enforcement as policy-driven directives or customer-consumed API fields rather than an autonomous security decision. Two rollout controls are especially important:

  • Per-domain or per-surface policy — apply a posture to the context it was designed for instead of assuming one global threshold.
  • Shadow mode — where available, record what a policy would have done without applying the traffic action.

Shadow output supports threshold review, expected-impact analysis, and investigation playbooks. It does not prove that future traffic will have the same distribution, so teams should continue monitoring after activation.

The risk-action engine

Where the risk-action engine is enabled, operators configure policies that can consider:

  • Device risk from Know Your Device.
  • Supported agent identity or policy context from Know Your Agent, where provisioned.
  • URL or route patterns that define the protected surface.
  • Network or IP reputation context available to the tenant.

The engine’s useful outputs are the matched policy, intended or applied action, and associated risk context visible through the supported product views. Those records help operators answer: Which policy matched? What evidence was available? Was the action observed or enforced?

How outputs inform decisions

Observed conditionTypical customer-owned response
Low risk with expected contextAllow and retain normal telemetry
Elevated risk with limited confidenceObserve or use a reversible step-up
High risk with corroborating flags on a sensitive routeStronger verification or manual review
Repeated critical-risk automation under an approved policyBlock or another provisioned mitigation
Collection error or missing assessmentUse the application’s documented fallback; do not assume safe

These are decision patterns, not universal defaults. The right consequence depends on customer journey, loss exposure, contractual requirements, accessibility, and support capacity.

Low risk, expected context

Observed condition

Low risk with expected context.

Typical customer-owned response

Allow and retain normal telemetry.

Elevated risk, limited confidence

Observed condition

Elevated risk with limited confidence.

Typical customer-owned response

Observe or use a reversible step-up.

High risk, corroborating flags

Observed condition

High risk with corroborating flags on a sensitive route.

Typical customer-owned response

Stronger verification or manual review.

Repeated critical-risk automation

Observed condition

Repeated critical-risk automation under an approved policy.

Typical customer-owned response

Block or another provisioned mitigation.

Collection error or missing assessment

Observed condition

Collection error or missing assessment.

Typical customer-owned response

Use the application's documented fallback; do not assume safe.

From observed condition to a typical responseDecision patterns, not universal defaults.

Eligibility and limitations

  • Managed enforcement, shadow mode, tarpit, and KYA inputs can require tenant-specific provisioning. Confirm them before making them a launch dependency.
  • A challenge directive does not supply your application’s MFA, identity verification, or authorization logic.
  • Browser controls do not replace server-side validation or protect non-browser protocols unless separately integrated.
  • A risk output is not proof of identity, intent, fraud, or policy compliance.
  • Always define behavior for timeouts, missing results, stale cached results, and unavailable optional signals.

Where it fits

Browser Security is the Security pillar. It consumes the outputs described by Calibration and can combine device risk with separately eligible agent context. In the agentic-security model, the policy remains customer-owned even when the product carries out a configured action.

Read deeper