Technical Flow
From risky action
to verified outcome.
Five steps. End-to-end audited. No frontend dependency. Here is exactly what happens when Anti Social Engine intercepts an event.
Event risk is low. Action proceeds immediately. No user interruption. Event logged.
Event risk is elevated. User receives a checkpoint. Action is paused until identity is confirmed.
Event risk is critical, or verification failed. Action blocked. Incident opened. SOC team notified.
A high-risk action is triggered on your platform.
A user initiates something sensitive — a wire transfer, password reset, bulk order, or admin action. Your platform sends the event to the Anti Social Engine ingest API with full context: user ID, event type, IP, user agent, and any platform-specific signals.
The event is normalized by the connector layer and passed to the risk engine. No platform-specific logic exists in the core — connectors keep it clean.
The risk engine scores the event in milliseconds.
The risk engine evaluates the event against a configurable policy model. Signals include event type, account age, device recognition, behavioral baselines, and historical patterns. A score from 0 to 100 is computed. The engine returns one of three outcomes immediately.
Low score → allow (action proceeds, no interruption). Medium score → delay_verify (challenge issued). High score → block_escalate (action blocked immediately, incident opened).
The user is interrupted mid-flow with a checkpoint.
For delay_verify outcomes, the user is redirected (or shown an embedded popup) to the Anti Social Engine hosted challenge page. The challenge is fully isolated — no JavaScript on your frontend, no SDK dependency. The user's session is paused until the challenge resolves.
The challenge page is server-rendered, tamper-proof, and branded. It cannot be bypassed by manipulating your frontend. Every challenge event is immediately logged.
A single question breaks the social engineer's script.
The user sees the company's policy statement — "our support team will never instruct you to do this" — and is asked one direct question: is anyone on a call, chat, or screen share guiding you right now? A legitimate user confirms no and proceeds. A user acting under outside influence cannot honestly answer that way — the Break Contact flow activates, warns them, and blocks the action.
If the risk level warrants it (delay_verify), users who confirm independent intent are issued an OTP for identity confirmation. OTP delivery is tracked. Attempts are logged and throttled. Both stages are independently auditable.
Allow or block. Signed token returned. Everything logged.
The session resolves with a signed decision token — a short-lived HMAC-SHA256 JWT containing the outcome, session ID, and expiry. Your backend calls /decisions/verify before completing the protected action. If the outcome is allow: the action proceeds. If block_escalate: the action is stopped.
The final outcome, all intermediate signals, and every audit log entry are persisted to PostgreSQL. The dashboard shows the full incident timeline immediately. No state lives only in the browser.
Ready to add a checkpoint to your platform?
Integrates in hours via API. No frontend changes required.