Risk Score and signals
How AbuseZero reports what it assessed on each evaluation, from one score down to each signal family and input.
Every evaluation reports what AbuseZero assessed at three levels of detail:
- the AbuseZero Risk Score, one number and a band;
- signal families, one assessment for each area AbuseZero examines;
- inputs, which of your identifiers the evaluation received.
Why it matters
The result tells your code what to do. These fields tell your team why, and show you where your integration can send more. Use them to explain a decision to a colleague, to set a risk threshold in your own policy, and to spot an identifier your server stopped sending.
Key capabilities
- The AbuseZero AI Risk Engine. The score comes from the AbuseZero AI Risk Engine.
- Five signal families on every call. Identity, device, network, automation and benefit history are assessed together, in real time, inside the evaluation's time limit.
- Your full claim history. Every identifier is checked against everything your workspace has recorded for the benefit, not a recent sample.
unavailableassessments. When a family has nothing to work with, it reportsunavailableinstead of guessing. When a source of evidence is slow, the evaluation finishes on time with what it has.- Previews, simulations and replays. Previews run the full evaluation. Simulations and replays apply your policy with the same engine as live evaluations.
The AbuseZero Risk Score
"risk": { "score": 80, "band": "high" }| Field | Values | Meaning |
|---|---|---|
score | Number from 0 to 100 in steps of 5, or null | How strongly the evidence points to a repeat or abusive claim. Higher means riskier. |
band | low, elevated, high or not_assessed | The score's band, for dashboards and quick decisions. |
not_assessed means no score was needed or available for this evaluation. The result still stands.
The score feeds your policy through its risk threshold. When nothing else in your policy has decided a claim, a score that reaches the threshold denies it, with the reason risk_threshold. See Policies and rules.
Signal families
Each family is assessed separately. The assessments are reported in the signals array of an evaluation's evidence, which needs the evaluation_evidence:read scope, and on the evaluation in the dashboard.
| Family | What it covers |
|---|---|
identity | The email address and identity details you send, assessed by AbuseZero Identity Intelligence. |
device | The device and browser behind the claim, and how they connect to earlier claims. |
network | The connection behind the claim, assessed by AbuseZero Network Intelligence. |
automation | Bots and scripted activity, assessed by AbuseZero Automation Defense. |
benefit_history | Earlier claims of this benefit that share this claim's identifiers. |
| Assessment | Meaning |
|---|---|
clear | Nothing in this family counts against the claim. |
elevated | Some evidence in this family counts against the claim. |
high | Strong evidence in this family counts against the claim. |
unavailable | This family had nothing to assess, usually because an input was missing. |
"signals": [
{ "family": "identity", "assessment": "clear" },
{ "family": "device", "assessment": "elevated" },
{ "family": "network", "assessment": "clear" },
{ "family": "automation", "assessment": "unavailable" },
{ "family": "benefit_history", "assessment": "high" }
]Evaluation details and previews don't include signal family assessments. The response to POST /v1/evaluations stays small: it carries the result, the score and the reason.
Inputs
inputs reports each identifier type as received or missing. It is the fastest way to confirm that your integration sends what you think it sends.
| Input | Comes from |
|---|---|
email | subject.email |
ip | context.ip |
user_id | subject.external_id. missing when you don't send one, although the email address still identifies the user. |
phone | identifiers.phone_hash |
payment | identifiers.payment |
device | identifiers.device_id, or device data from the browser SDK |
browser | identifiers.browser_cookie_id, or browser data from the browser SDK |
"inputs": { "email": "received", "ip": "received", "user_id": "received", "phone": "missing", "payment": "missing", "device": "received", "browser": "received" }A missing input means that family had less to work with. It never causes an error. Send identifiers shows how to send each one.
Configuration
- Which identifiers you send. Each additional identifier gives every later evaluation more history to connect.
- How much the score counts. Your policy's risk threshold decides at which score claims are denied. Your protection level sets a sensible default.
- How automation counts. Each benefit's automation setting decides whether automated activity is scored, denied or allowed. See Bots and AI agents.
Programmatic access
| Interface | Use |
|---|---|
| AbuseZero REST API | GET /v1/evaluations/{id} and POST /v1/evaluation-previews return risk and inputs; GET /v1/evaluations/{id}/evidence adds signals |
| AbuseZero Node.js SDK | evaluate(), previewEvaluation(), getEvaluation(), evaluationEvidence() |
| AbuseZero CLI | abusezero evaluations get, preview, evidence |
| AbuseZero MCP server | abusezero_get_evaluation, abusezero_preview_evaluation, abusezero_get_evaluation_evidence |
| Dashboard | Evaluations |
Next steps
How is this guide?
Last updated on