Risk scoring: AI and ML
Four independent layers look at every request. They feed the confidence score and the evidence panel on the request detail page; none of them replaces the admin's decision.
Layer 1: local antivirus (AMSI)
Before the request ever leaves the device, the Windows agent asks the locally installed antivirus engine (Defender by default) for a verdict via AMSI. A detection blocks the launch on the spot; the result is recorded either way, so approvers see "Local AV: clean" next to the cloud signals.
Layer 2: reputation
The platform keeps a reputation record per executable hash: how often it has been seen, approved and denied across your tenant, plus known-good vendor catalog matches. A binary your fleet has approved four hundred times reads very differently from one nobody has ever seen.
Layer 3: AI binary analysis
Each reviewable request gets a model-written analysis of the binary's full identity: name, version resources, publisher and certificate chain, path, arguments and parent process. It produces:
- a legitimacy score from 0 to 100,
- a short human-readable summary ("well-known installer from a signed vendor, path and arguments consistent with normal use"),
- named risk indicators when something is off: lookalike names, unsigned binaries in user-writable paths, script hosts with encoded arguments, and similar patterns.
Analysis is budgeted per tenant; requests that skipped it (or predate it) can be analyzed on demand from the request detail page.
Layer 4: the ML scorer
A scorer trained on your tenant's own decision history predicts what your team would do with this request. Its inputs include the binary's approval history for this user and fleet-wide, signature status, path characteristics and request timing. Until it has enough labeled decisions to train on, it runs as a transparent heuristic and the console labels its maturity ("training, needs N more samples"); once trained and validated on held-out data, its confidence becomes the primary source of the unified score.
Auto-approval
Optional, off by default. When enabled in policy, a request is auto-approved only after the same binary has been explicitly approved for the same user a configurable number of times (default 5). It is a repetition gate on your own prior decisions, deliberately not a model threshold.