Choose the context your decisions need.
Explore Noxtica capabilities by the customer problem they address, the outputs your team can use, and the requirements to evaluate them.
Start with a customer journey, agree what success means, then confirm the capabilities and access available for your tenant. A capability listed here is not a promise that every plan or deployment includes it.
ONE FRAME FOR THE DIRECTORY
See each capability as evidence, context, or control for an interaction.
Noxtica uses Agentic Security & Risk Intelligence to connect available browser, network, device, behavior, identity, and agent evidence to an explainable risk read. The capability families below show what can contribute to that read, how teams consume it, and where customer-owned policy acts.
Agentic Security & Risk Intelligence is Noxtica’s product framing, not an industry standard or a promise that every module is enabled. Availability still depends on your plan, tenant, role, integration, and applicable consent or legal-basis requirements.
Explore the Agentic Security & Risk Intelligence frameCustomer capability directory
What each capability helps a customer do, what it produces, and the boundary that must be met before it is used.
Risk and decisioningTurn browser, device, network, and behavioral evidence into a risk read your team can explain.
Why teams need it
Teams need more than a yes-or-no verdict. They need confidence, reasons, and a policy boundary they can review.
Open the customer referenceCalibrated risk reads
Provisioned workspaceReturn a risk level, confidence, and consistent reason set for backend decisions and operator review.
Boundary: Available to provisioned workspaces; your application remains the final decision-maker.
Explainable reasons and evidence
Provisioned workspaceTrace an assessment to named evidence categories instead of defending a black-box label.
Boundary: Visible according to workspace role and the evidence available for that event.
Risk policies and actions
Controlled availabilityTranslate risk bands into allow, watch, challenge, or block paths appropriate to each journey.
Boundary: Action paths require explicit tenant configuration; enforcement is not inferred from detection alone.
Quality and calibration review
Controlled availabilityReview population shifts, disputes, and proposed adjustments before changing a production policy.
Boundary: Administrative review and additional approval may be required before a change is applied.
Device and browser intelligenceRecognize returning environments and inspect the evidence behind browser, device, and app posture.
Why teams need it
A stable device view helps teams separate ordinary variation from automation, tampering, and repeated abuse.
Open the customer referenceDevice recognition and history
Provisioned workspaceFind a device, review visits, compare profiles, and carry its identifier into a server-side workflow.
Boundary: History follows workspace retention and access settings.
Browser intelligence
Provisioned workspaceReview browser consistency, privacy-browser context, and signs of automated or modified execution.
Boundary: Signals vary by browser support and are evidence inputs, not identity proof on their own.
Attested device evidence
Controlled availabilityAdd challenge-backed browser or mobile integrity evidence when a higher-confidence decision needs it.
Boundary: Eligibility depends on the client platform, tenant policy, and an explicitly enabled challenge path.
Mobile app posture
Integration dependentAttach supported iOS or Android integrity context to a server-side assessment.
Boundary: Requires a supported mobile integration and the platform attestation service configured for the app.
Bot, abuse, and network defenseCombine automation, abuse, and network context so controls can respond without treating every unusual visitor as hostile.
Why teams need it
Attackers rotate tools and networks. Layered evidence gives operators a safer basis for friction and enforcement.
Open the customer referenceAutomation and bot detection
Provisioned workspaceIdentify headless execution, automation residue, known operators, and suspicious interaction patterns.
Boundary: Detections are returned as evidence and reasons; response policy remains configurable.
Network and reputation context
Integration dependentBring IP, hosting, transport, and reputation context into an investigation or score.
Boundary: Coverage and metering depend on enabled data sources and the selected service package.
Tripwires and step-up challenges
Controlled availabilityEscalate selected traffic with an additional check instead of applying blanket friction.
Boundary: Challenge providers and tenant policy must be configured before this path is eligible.
Edge enforcement
Controlled availabilityApply an approved allow, challenge, limit, or block policy before protected traffic reaches an origin.
Boundary: Requires a compatible edge deployment, explicit arming, and a tenant-approved response policy.
Account linking and investigationFollow relationships across devices, visits, accounts, and cases without losing the evidence for each link.
Why teams need it
Fraud is rarely confined to one event. Investigators need relationship context and a reversible way to act on it.
Open the customer referenceDevice and account linkage views
Provisioned workspaceReview related identifiers and move from a population view to the evidence for one relationship.
Boundary: Relationship visibility is tenant-scoped and follows operator permissions.
Cluster intelligence
Controlled availabilityGroup recurring evidence patterns to prioritize coordinated abuse investigations.
Boundary: Shared-intelligence participation, where offered, requires separate tenant eligibility and controls.
Relationship controls
Controlled availabilityReview, suspend, unlink, or delegate a supported device relationship through governed workflows.
Boundary: Available only for enabled relationship models and appropriately privileged operators.
Recovery, appeals, and disputes
Controlled availabilityRoute contested decisions and account-recovery evidence into a reviewable case.
Boundary: Workflow availability depends on the identity product and roles enabled for the workspace.
Journey and experience observabilityConnect risk events to the session journey, performance, errors, and conversion context around them.
Why teams need it
A score tells you what changed. Journey context helps explain where it happened and what the customer experienced.
Open the customer referenceSession replay
Controlled availabilityReview a recorded journey, timeline, interaction evidence, and diagnostics from a dedicated session view.
Boundary: Recording begins only after tenant, domain, sampling, consent, and policy admission gates pass.
Real user monitoring
Controlled availabilityInspect sampled web vitals, client errors, console diagnostics, and collection health by domain.
Boundary: Capture and read access are separately configured; sampling can remain at zero.
Journeys, funnels, and heatmaps
Controlled availabilitySee navigation paths, interaction concentration, step completion, and drop-off across collected sessions.
Boundary: Results depend on enabled tracker collection, retention, and the selected tenant or domain scope.
Live session view
Controlled availabilityJoin an eligible in-progress session for consented support and investigation workflows.
Boundary: Payload access requires a separately authorized role and a session that is eligible for live viewing.
Monitoring, alerting, and reportingMove from live investigation to scheduled oversight with dashboards, alerts, exports, reports, and status views.
Why teams need it
Operational teams need a durable handoff from an individual signal to the people and systems responsible for response.
Open the customer referenceDashboards, saved views, and cohorts
Provisioned workspaceTrack risk, usage, quality, and selected populations without rebuilding the same view.
Boundary: Available metrics follow the workspace package, data sources, and operator role.
Alerts, webhooks, and event sinks
Integration dependentRoute selected events to an operational destination with tenant-scoped alert rules.
Boundary: A destination and alert policy must be configured; supported sinks vary by integration.
Exports and scheduled reports
Controlled availabilityCreate governed data exports and review the delivery history for periodic usage or status reports.
Boundary: Export scope, report delivery, and sensitive fields follow role and workspace policy.
Synthetic checks, uptime, and status
Integration dependentSeparate generated test traffic from customer events and review public component status and maintenance notices.
Boundary: Synthetic generation is an authorized test tool; status views report observed components without creating an availability promise.
Agent identity and controlVerify supported agent credentials, assess the surrounding request, and apply a policy for automated traffic.
Why teams need it
A signed agent name is useful context, not a complete trust decision. Identity, behavior, and request evidence belong together.
Open the customer referenceVerified agent requests
Controlled availabilityValidate supported signed-agent requests and attach the verification result to the wider risk context.
Boundary: Requires compatible signing and edge integration; an unverified request is not automatically blocked.
Know-Your-Agent policy
Controlled availabilityReview agent identity, request evidence, and the resulting policy decision in one operator view.
Boundary: Agent verification and enforcement are separately enabled for eligible tenants.
Agent identity envelopes
Integration dependentCarry verified agent context into a supported server workflow without treating it as a human identity.
Boundary: Available only where the agent identity issuer, keys, and verifier have been provisioned.
Crawler access and commercial policy
Controlled availabilityUse an attested traffic decision to allow, limit, deny, or route eligible crawler access to a commercial flow.
Boundary: Commercial routing requires an approved payment integration and explicit tenant activation; it is not enabled by default.
AI-assisted operationsInvestigate in the console or connect approved tools to tenant-scoped operational context.
Why teams need it
Assistance should shorten evidence gathering without silently changing policy or crossing tenant boundaries.
Open the customer referenceOperator assistant
Controlled availabilitySummarize and navigate the security, usage, and operational evidence the signed-in operator can already access.
Boundary: Requires assistant access, configured model capacity, and the operator’s existing permissions.
Read-only MCP access
Integration dependentLet an approved external agent query scoped risk and operational data through read-only tools.
Boundary: Requires a scoped token and compatible MCP client; public tools do not authorize mutations.
Model, provider, and usage controls
Controlled availabilitySelect approved providers, manage credentials, and review AI credit or model usage.
Boundary: Provider eligibility, model access, and usage limits depend on workspace configuration.
Assistant oversight and audit
Controlled availabilityReview assistant activity, generated briefs, and any separately approved operator action trail.
Boundary: Oversight views are restricted by role; write actions, where present, require their own approval path.
Developer platform and integrationsCollect in web or mobile clients, verify on the server, and connect outputs to the systems your team already runs.
Why teams need it
Security evidence is only useful when teams can carry it through their existing application and operations stack.
Open the customer referenceWeb SDK and script-tag setup
Provisioned workspaceInitialize collection through a browser API, framework wrapper, or configured script tag.
Boundary: Collection behavior follows the tenant, domain, consent, and feature configuration supplied at setup.
Server SDK and API
Provisioned workspaceVerify results, look up supported resources, and make typed server-side calls with scoped credentials.
Boundary: Endpoints and scopes depend on the provisioned package and key permissions.
Mobile SDK integrations
Integration dependentConnect supported iOS and Android attestation or capture flows to a backend assessment.
Boundary: Platform setup, app registration, and supported SDK capability vary by mobile integration.
Domains, relays, and event integrations
Integration dependentManage protected domains and connect eligible first-party relay, webhook, or event destinations.
Boundary: Each destination requires ownership, credentials, and tenant-specific configuration.
Owned-site search visibility
Integration dependentRun technical checks and site crawls, follow issue trends, and connect read-only Search Console data for an owned property.
Boundary: Checks require verified domain ownership; Search Console features require an approved Google connection.
Identity verification and accessSupport identity evidence, step-up checks, and workforce access controls as distinct governed layers.
Why teams need it
Knowing a device, verifying a person, and authorizing an operator answer different questions and should remain separable.
Open the customer referenceIdentity verification workflows
Integration dependentSubmit supported identity evidence, review verification cases, and route exceptions for operator review.
Boundary: Evidence types, screening, and provider-backed checks require an eligible identity configuration.
Document, selfie, and mobile document capture
Integration dependentCollect supported evidence through browser or mobile capture flows and upload it to an authorized case.
Boundary: Device support, user permission, provider setup, and case policy determine eligible capture methods.
Passkeys and step-up verification
Controlled availabilityBind supported credentials and require a stronger check for sensitive identity or operator actions.
Boundary: Requires compatible authenticators and an enabled credential or step-up policy.
MFA, SSO, sessions, and role-based access
Integration dependentControl who can enter the workspace and which data or actions each role can reach.
Boundary: SSO and advanced role controls depend on workspace configuration and an external identity provider where used.
Governance and data controlsSet collection, retention, access, and audit boundaries around sensitive operational evidence.
Why teams need it
A useful security signal still needs a lawful collection path, a retention limit, and a record of who used it.
Open the customer referenceCollection admission and consent controls
Controlled availabilityCoordinate consent, browser privacy signals, sampling, legal basis, and feature policy before optional collection starts.
Boundary: The customer remains responsible for configuring an appropriate legal and consent basis for its use case.
Retention, archive, export, and deletion
Controlled availabilityManage data lifecycle operations and preserve an auditable record of governed exports or deletion requests.
Boundary: Available operations and retention windows depend on data type, package, and operator authority.
Audit and access review
Provisioned workspaceReview operator activity, assistant actions, key posture, and access assignments from governed views.
Boundary: Sensitive audit and key details are role-restricted and tenant-scoped.
Tenant scope and data-location controls
Integration dependentKeep workspace data scoped and review configured storage or processing locations where the deployment supports them.
Boundary: Location choices depend on the contracted deployment and do not imply a certification or universal residency guarantee.
Workspace and commercial operationsOperate users, domains, usage, package limits, billing records, and support-facing account workflows in one console.
Why teams need it
Enterprise operations fail when product controls and account records disagree. Teams need a visible operational boundary for both.
Open the customer referenceWorkspace, user, and domain administration
Provisioned workspaceManage the people, protected properties, and workspace settings attached to a customer account.
Boundary: Administrative actions follow role, ownership, and workspace provisioning.
Usage, quotas, and add-ons
Provisioned workspaceReview consumed capacity, package allowances, and separately provisioned modules or add-ons.
Boundary: Entitlements and limits come from the customer’s contracted package; code presence does not activate them.
Wallet, invoices, orders, and billing reports
Controlled availabilityReview account balances, order state, invoices, usage charges, and report delivery history where applicable.
Boundary: Payment methods, currencies, and billing views depend on the contracted commercial arrangement and operator role.
Account support and service status
Provisioned workspaceReach customer support, request account deletion, and review public component or maintenance updates.
Boundary: Support channels and operational status are informational and do not add an unstated service-level commitment.