Appearance
Modern social engineering has evolved well beyond traditional phishing emails. Today’s attacks increasingly rely on human-in-the-loop techniques , including direct interaction with help desks, executive impersonation using AI-generated voices, and the use of remote or intermediary systems to appear geographically and operationally legitimate.
These attacks routinely bypass traditional perimeter defenses such as firewalls, web application firewalls (WAFs), and IP-based controls. In many cases, attackers operate with valid credentials , access systems through real browsers, and deliberately mimic legitimate user behavior. As a result, network-centric and credential-centric security controls alone are insufficient.
imper.ai identifies the technical seams and inconsistencies that emerge when an attacker attempts to impersonate a legitimate user. Rather than relying on a single signal, it correlates browser behavior, device characteristics, execution environment, network routing, and organizational context - cross-referencing real-time session data with authoritative sources such as identity provider history, HR records, and known user baselines to surface indicators that are hard for an attacker to fully replicate, even when authentication succeeds.
How imper.ai Determines Risk
Every interaction is given a single risk level. It is an aggregated assessment - not the result of any one signal - that combines several layers:
Infrastructure signals. What the session itself reveals about the connection, location, device, tooling and behavior, and the identity presented. imper.ai evaluates these across five categories, detailed in Detector categories and signals below.
Verification questions (LLM). When enabled, an LLM scores the user's answers to knowledge-based questions - judging each as correct, close, or wrong - and combines them into a questions score that feeds the overall assessment.
Optional escalation layers. For higher-risk or sensitive cases, IDV or manager verification can be added and can influence the risk level. See Verify with Document and Verify with Manager.
The detection pipeline
Behind the risk level, every verification runs through the same pipeline - each stage adds context, and no single signal decides the outcome on its own:
Collect - JavaScript in the user's browser gathers raw session signals: device and browser characteristics, network origin, media devices, and interaction behavior. Nothing is installed on the user's device.
Enrich - imper.ai adds external context to those raw signals: IP reputation and routing (VPN, proxy, datacenter), geolocation, email and phone intelligence, and the organization's own trusted sources (identity provider history, HR records, known baselines).
Detect - detectors evaluate the enriched signals and emit named anomalies - for example, Virtual machine detected or Access from restricted region. Each detector contributes a contextual signal, not a binary verdict.
Score - the anomalies are grouped into categories and combined into a single risk score, as described below.
How the risk score is built
Both layers contribute probabilistically - there is no fixed pass or fail per signal. Instead, each signal is weighted by its confidence (how sure imper.ai is that it is real) and its severity (how dangerous it is), graded against imper.ai's knowledge base of known-risky infrastructure, high-risk patterns, and documented attack techniques. These are combined into a single risk score, which is compared against your configured risk threshold: a verification scored within the threshold is marked Passed, and anything above it Failed.
For example: a user with no signed-in accounts on the device, using an email from a recently registered domain, and connecting through Astrill VPN. This combination of signals is consistent with suspicious infrastructure and potentially DPRK/Lazarus-associated activity - and is very rare among valid users - so the risk score will be high.
The score is not static - it sharpens as configuration and history accumulate:
Historical context. As a user completes more verifications, imper.ai builds a baseline of their normal devices, locations, and behavior. Later sessions are weighed against that history, so deviations - or consistent, expected patterns - increasingly shape the score over time.
Verification settings and questions. In the questions layer, how many questions are asked and how the policy is configured shape the score; stricter settings and better-covered questions produce a sharper, more confident result. See Verification Policies.
Risk Levels
Every assessment resolves to one of three risk levels:
Low - the signals are consistent with a legitimate, expected user. Nothing notable stands out, and the interaction can usually proceed.
Medium - there is some uncertainty or inconsistency. The identity is neither confirmed nor clearly fraudulent - often a good candidate for an additional verification step.
High - strong or combined indicators of impersonation. The interaction should be treated as untrusted and handled accordingly.
Risk and Premeditation
Alongside risk, imper.ai weighs premeditation - the degree of preparation and intent behind an attempt:
Risk - the likelihood that an interaction involves impersonation, social engineering, or unauthorized access.
Premeditation - how deliberately the attempt was set up to bypass controls and sustain access.
Premeditation shows up in patterns that indicate deliberate setup rather than incidental anomalies - specialized or disposable environments, consistent geographic alignment with a target despite indirect routing, repeated probing of verification workflows, or behavior that evolves over time to better mimic a legitimate user. Individually these can look benign; correlated over time and context they reveal intent and preparation, which typically represents a higher threat level than an opportunistic attempt.
Detector Categories and Signals
The infrastructure layer draws on detectors grouped into five categories. Each detector contributes a contextual signal, not a binary verdict, and they are most powerful in combination - an indicator that looks benign on its own can become significant alongside others.
imper.ai brings domain expertise to this assessment. It maintains a knowledge base of known-risky infrastructure and patterns - for example, high-risk VPN providers and known malicious IP ranges - along with the high-risk combinations most associated with impersonation and social engineering, so signals are interpreted with real-world context rather than in isolation.
Signals are collected at three levels of depth, depending on how imper.ai is deployed:
Web-based detection - active JavaScript running in the browser during a session, requiring no software installed on the user's device.
Point-in-time device scan - a lightweight script run on managed endpoints at the time of a verification event. Available in the Continuous Verification use case only.
Deployed agent - a continuously running agent on managed devices that builds behavioral baselines over time and detects persistent or evolving signals. Available in the Continuous Verification use case only.
Network
Network signals evaluate how traffic is routed to the platform and whether the connection is being obscured. These detectors identify anonymization infrastructure and routing inconsistencies that attackers use to hide their true origin.
| Detector | Primary Social Engineering Risk |
|---|---|
| Masked Network Connection | Use of Tor, proxies, or anonymization infrastructure to hide origin |
| VPN | Impersonation of remote workers or geographic alignment with a victim |
Location
Location signals evaluate where access appears to originate and whether the reported location is consistent with expected user geography.
Because social engineering attacks often rely on geographic plausibility to support impersonation pretexts, location signals frequently expose attempts to appear legitimate.
| Detector | Primary Social Engineering Risk |
|---|---|
| Unexpected Location | Location mismatches relative to HR records, CVs, or identity provider history |
| Restricted Region | Access from high-risk, sanctioned, or unexpected regions outside the organization's legitimate footprint |
Device
Device signals focus on the hardware and execution environment used to access the platform. These detectors evaluate whether the hardware, operating system, browser, and usage history align with what is expected for the claimed user.
Attackers frequently rely on disposable, virtualized, or specially configured environments. While credentials can be stolen, reproducing a legitimate device profile over time is significantly more difficult.
| Detector | Primary Social Engineering Risk |
|---|---|
| Virtual Machine | Use of disposable or isolated attack environments |
| Anomalous Browser | Use of anti-detect or identity-spoofing browsers |
| Anomalous Device | Use of attack rigs or low-end hardware inconsistent with the user profile |
| Device Mismatch | Session or identity hijacking from an unauthorized machine |
| Inconsistent Patterns | Deviations from established technical fingerprints and usage habits: browser, OS, working hours, application patterns |
| Clean / Burner Device | Use of freshly created or wiped environments with no usage history |
Tools
Tools signals detect software and hardware used to automate, remotely operate, or tamper with a session - and, above all, the behavioral tells that give an operator away. These signals span browser-visible artifacts, point-in-time device scans, and the deployed agent.
Many of these are behavioral signals - inferred from how the session actually behaves in real time (input timing, automation artifacts, injected audio) rather than from static device attributes.
| Detector | Primary Social Engineering Risk |
|---|---|
| Remote Access & Control | Hardware (KVM-over-IP) or software remote desktop tools used to operate the device from a hidden third-party location |
| Hardware KVM (KVM-over-IP) | A hardware KVM appliance (PiKVM, TinyPilot) detected on the device's local network, indicating the session may be driven by a hidden remote operator |
| Malicious Tooling on Device | Presence of OS-level hacking tools, exploit scripts, or attacker-oriented repositories - detected by scan or agent |
| Bot-like Behavior | Automation of credential abuse, brute-force attempts, or MFA guessing |
| Suspected Attack Device | Presence of browser-visible attacker tooling: debuggers, hacking extensions, or automation artifacts |
| Anomalous Input Patterns | For Continuous Verification - typing timing, key hold duration, and mouse movement shifts indicating a different person or automated input is operating the device |
| Virtual Audio Devices | Injection of AI-generated or pre-recorded audio into voice interactions |
Identity
Identity signals evaluate the contact identifiers a user presents - email address, domain, and phone number - to determine whether they belong to a real, established identity or are disposable, virtual, or otherwise high-risk.
Attackers routinely rely on identifiers that cannot be traced back to a verifiable identity, letting them appear plausible while avoiding attribution.
| Detector | Primary Social Engineering Risk |
|---|---|
| Email and Domain Checks | Use of disposable providers, newly registered or low-reputation domains, or domain inconsistencies to avoid attribution |
| Phone Checks | Use of virtual, VoIP, or disposable numbers to receive verification codes without a traceable identity |
From Risk to Response
The risk level is evaluated in real time against administrator-defined policies that set how imper.ai responds at each level. Typical outcomes:
Allow the interaction to continue
Require additional verification or user confirmation
Escalate the interaction for review
Block or terminate the interaction
When a policy threshold is reached, imper.ai executes a remediation action within the native environment - a meeting platform, chat interface, or helpdesk workflow - such as ending a live meeting, blocking a sensitive helpdesk request, or preventing further interaction until verification succeeds.
Remediation can be automated (triggered immediately when a threshold is exceeded) or manual (risk context is surfaced to an operator or analyst, who decides before any action is taken).