The Trust Engine

Five conditions in. One verdict out.

Identity, device posture, location, time and risk score, evaluated together, per session, before a single packet reaches the app.

Book a demo

Trace a decision ↓

decision timemilliseconds. Trust assumed: zero.

A machine diagram: five labelled hoppers — identity, device, place, time and risk — feed one sealed evaluation chamber, whose output shaft drives a press that stamps an ALLOW verdict onto a ticket.

21policy combinations
12risk trigger types
4automatic responses
202logged event types

What is the Trust Engine?

trust_engine

Administrators compose the conditions. It returns one verdict, per session.

The Trust Engine is the policy evaluation layer of the InstaSafe controller, not a marketing name for a firewall rule. Administrators compose conditions; it resolves them into one verdict, per session.

21combinations of identity, device, location, time and risk

12trigger types feeding the risk score

4automatic responses when it crosses threshold

Conditions are composed, not chosen from a listIdentity, device posture, location, time window and behavioural deviation combine. An administrator writes the rule that says which combination opens which resource, and for how long.
One verdict, not five pass/fail resultsThe inputs are weighed as a set and resolved once. A perfect identity does not rescue a failing device, and a compliant device does not rescue an impossible journey.
Risk is continuous, so the verdict is tooThe score keeps moving during the session. A session that started clean and stops being clean is re-answered mid-flight rather than left alone until it expires.
Every decision is written downAllow, step-up, restrict or terminate. Each verdict lands in the event log with the inputs that produced it, so an auditor reads the reasoning and not just the outcome.

Book a demo Device posture check

policy.evaluatesession

$ evaluate sophia@acme.co → erp-core
→ identity   directory match · mfa satisfied
→ device     bound · posture 25/25
→ location   SG · 41 min after last IN login
→ risk       78 / 100 · impossible travel
→ threshold  40
$ verdict
→ RESTRICT · session narrowed · event logged

1verdict per session

202event types recorded

0decisions left unlogged

The engine

One movement, checked on every beat.

Not five gates in series, each waving the request through to the next. One mechanism, turning once per request, that only opens when every part of it lines up.

identitydevicelocationtimerisk

watch it decide_

Change an input. Watch the verdict move.

Set each of the five families yourself. The readings feed a risk score, the score meets one threshold, and the band it lands in selects which of the four automatic responses fires. Nothing here is a prepared scenario: the combination is yours, and so is the answer.

set the five inputs

Identitydirectory identity, group, auth strength presented

Devicebinding certificate, 25 posture check results

LocationIP, geolocation against policy and against history

Timewindow compliance, and this person's historical pattern

Behaviourdeviation score against this person's own baseline

policy.evaluatesession

identity: directory match · MFA satisfied
device: certificate matched · posture 25 of 25
location: IN · inside the allowed geography
time: 14:02 IST · inside the policy window
behaviour: matches the established pattern

signals raised

Nothing above baseline. The score stays where it started.

risk score4/100

threshold 40not crossed

ALLOWbelow 40

Under the threshold, so no automatic response fires. The session opens with the entitlements the policy already grants.

logged one of 202 event types, with all five readings attached

one verdictdemo weights

The policy grammar

Twenty-one combinations, written out.

Administrators compose conditions rather than pick from presets. Read these three in order: the second is the first with one condition changed, and the third is a condition that overrules the other four.

finance groupmanaged deviceIndiabusiness hoursAllow, standard MFA
The ordinary path. Everything the policy asked for is present, so nothing is asked of the person.
finance groupunmanaged deviceClientless portal, watermarked, no download
The same group, one condition changed. Access is not refused, it is reshaped.
anyoneanywhereposture failedDeny and alert
A condition that overrides the rest. No identity is good enough to rescue a device that failed its checks.

twenty-one combinationsEnough grammar to say what you mean, few enough dimensions that somebody can still audit what you said.

The evaluation

From request to verdict.

A request arrives

One person, one application, one moment. Nothing is open yet — the gateway stays dark until the engine has answered, so evaluation happens before a packet reaches the app rather than after.

01 / 05

Step 1: A request arrives. One person, one application, one moment. Nothing is open yet — the gateway stays dark until the engine has answered, so evaluation happens before a packet reaches the app rather than after.
Step 2: The five are read. Identity: the directory record and the auth strength actually presented. Device: the binding certificate and 25 posture results. Location against policy and against history. The time window. Deviation from this person's baseline.
Step 3: The readings score. Twelve trigger types move the number at runtime — impossible travel, posture drift, repeated auth failures, unusual-hours access, new-device patterns, and behavioural classes scored against each user's own baseline.
Step 4: The threshold decides. One line, not a debate. Under it the session opens on the standard path. Over it, the band the score has landed in decides which response fires — and none of the five readings gets to overrule that on its own.
Step 5: A response, recorded. Step-up, restriction or termination, with alerting alongside all three. The verdict lands in the log as one of 202 event types, carrying the readings that produced it rather than only the outcome.

Twelve things move the score.

A trigger is a runtime condition, not a login check.
Each one is watched while the session is open, and each one moves the risk score the engine is already holding. That is why a session can start clean and stop being clean without anybody signing in again.

locationImpossible travelA sign-in from somewhere the person could not physically have reached since their last one. Two valid logins, one impossible journey between them.

devicePosture driftA device that passed its 25 checks at sign-in and stops passing during the session. Antivirus switched off at four in the afternoon is a mid-session event, not a login event.

identityRepeated auth failuresFailed attempts stacking up against one account. A password being guessed looks nothing like a password being remembered.

timeUnusual-hours accessActivity outside the window this person actually works. Measured against their own history, not a company-wide curfew.

deviceNew-device patternsHardware the account has never authenticated from before, or a run of unfamiliar devices in a short window.

behaviourFurther anomaly classesThe remaining trigger types are behavioural deviation classes, scored against each user's own baseline and enabled per tenant. Ask for the set your environment would run in a demo rather than reading a list here.

The responses

Ordered force. Challenge, constrain, then end it.

Four automatic responses are available once risk crosses the threshold, and they are not interchangeable. Challenge before constraining, constrain before killing, and record all of it. Account suspension is deliberately not on this list; that stays an administrative action.

allowedstep-up mfasession restrictionsession termination

alerting, for every crossing

40 to 59Step-up MFA

Re-challenges the person before anything continues, with a factor the auth profile decides rather than the user.

they seeOne extra prompt. The session opens if they answer it.

60 to 79Session restriction

Narrows what the session can still reach instead of ending it, so work that carries no risk keeps going.

they seeFewer tiles in the portal, and the sensitive ones stop responding.

80 to 100Session termination

Ends the session outright. Getting another one means a fresh evaluation, not a resumed connection.

they seeThe session closes. Signing in again starts the decision over.

every crossingAlerting

Raises the crossing to the security team with the inputs that produced it, without interrupting the person.

they seeNothing. That is the point of having it.

The record

Every verdict, with its reasons.

Every input read, every decision made and every action taken becomes structured, exportable evidence. Logins, failures, posture results, policy decisions, session starts and ends, and in-session actions are all one of 202 event types.

The part that matters at audit time is not the count. It is that the entry keeps the readings that produced the verdict, so the answer to a question about last March is a log line rather than a meeting.

202: event types
11: built-in report types
7: SIEM export formats

See how ZTAA sessions are recorded

audit entry

event.detailrecord