Risk analysis and LLM reviews

The per-message detectors score one prompt at a time. Risk Analysis is the tier that reasons across a person: when the same user trips jailbreak or prompt-injection detection often enough inside a window, a local LLM analyst reads their detections across sessions and reaches a verdict that can warn them or take their AI access away. This page holds those verdicts, the locks, the unlock queue, the knowledge the analyst reasons with, and the trigger that starts it all.

What do I need?

Licence

Enterprise

Role

admin_userviewer

Prerequisites

• The analyst stack is running — see Ask the AI Analyst for what the llm-analyst compose profile needs.
• RISK_ANALYST_SERVICE_ENABLED is 'true'. Anything else fails every dispatch as analyst_disabled.
• Redis is reachable: the sliding window and the cooldown live there.
• You are signed in as an admin_user or the superadmin. A viewer may read every tab and decide nothing.

Everything on this page is scoped to what you may read. An admin_user sees their own tenant and the members of the groups they own; an id outside that answers 404, never 403, so the endpoint cannot be used to discover another team's locked users.

Screenshot pendingRisk Analysis with four stat tiles above the Reviews, Analyses, Locked users, Unlock requests, Attack knowledge, ATLAS, OWASP and Trigger settings tabs/assets/screenshots/llm-review@0.4.png

How a review starts

Every detection the gateway writes — dashboard chat, /chat/completions, image analysis — passes through one funnel. A detection counts toward the window when its entity type is a jailbreak or prompt-injection label and its confidence is at or above the floor.

The floor is deliberately below the level that blocks a single message: the signal this feature acts on is repetition of attempts that individually were not enough. When the window fills, one review is opened, the window is emptied, and a cooldown starts so the next review needs fresh attempts rather than inheriting the ones already reviewed.

Tune the trigger

Read a verdict

Restore someone's access

A lock stops AI access wherever CID can identify the person. Sign-in keeps working on purpose, so the user can see the notice and ask for it to be lifted.

Curate what the analyst knows

The Attack knowledge tab holds the cards every review reasons against — techniques, and the benign shapes that look like them. Nothing here is written from any user's data.

Sign off on a set analysis

The Analyses tab is a different object from a review: one report over a whole filtered slice of All detections, started with Analyse on that page rather than by a trigger. A review is about a person; an analysis is about a filter.

Fields reference

Trigger settings

Tabs

Stat tiles

Verify

1. With the trigger on, send the same user's account past the attempt threshold inside the window. A row appears on Reviews at Pending, then Analysing, then Completed.
2. Open Event logs. The trigger writes LLM_REVIEW_TRIGGERED, the verdict writes LLM_REVIEW_COMPLETED, and a failure writes LLM_REVIEW_FAILED. A lock the analyst asked for writes USER_AI_LOCKED_PENDING and the applied lock writes USER_AI_LOCKED.
3. Approve an unlock request. The lock's Status becomes Cleared, and USER_AI_UNLOCKED appears in the audit trail — as does UNLOCK_REQUESTED for the user's own request and UNLOCK_DENIED for a refusal.
4. Approve or reject a report on Analyses and confirm the Review column changes. The decision is written to the audit trail as a resource update.
5. No event metadata ever carries the analyst's reasoning or evidence. What leaves for SIEM is the review id, verdict, score, confidence, verification flag, status and counts.

If it fails

• This feature (risk.llm_review) is not included in the installed license tier. Contact your CID representative to upgrade. — a 403 with the code FEATURE_NOT_LICENSED. An Enterprise key. An already-applied lock keeps enforcing regardless, and the page a locked user sees keeps working.
• Could not save settings — the trigger config was rejected. Every field is range-checked; attempts above 50, a window above 1440 minutes or a confidence outside 0–1 are refused.
• Reviews pile up at Pending and nothing completes — the analyst is not reachable, or RISK_ANALYST_SERVICE_ENABLED is not the string true. A disabled integration fails a review terminally rather than leaving it pending forever, so persistent Pending points at the queue, not at the flag.
• Reviews complete as Failed with a timeout and users are being warned instead of locked — the circuit breaker has stood the Lock fallback down after three consecutive failures. Look for LLM_REVIEW_ANALYST_UNAVAILABLE; the problem is infrastructure, and detections are going unreviewed.
• That lock was already cleared. — somebody decided it elsewhere. Not an error.
• Approving or denying returns a 409 — the request was already decided. The row refreshes itself.
• A review, lock or request you expect is missing — it belongs to a tenant outside your scope, and is deliberately indistinguishable from one that does not exist.
• Could not change the entry or Import refused on Attack knowledge — most often a 409 on an official or bootstrap card. Disabling it is always allowed.
• Nothing ever triggers although jailbreak detections are recorded — check the confidence floor against the detections' own confidence, and check that Redis is up. A Redis failure loses the window silently rather than failing the user's chat turn.

Next steps

• Ask the AI Analyst — the same analyst, answering your questions instead of judging users, and where its infrastructure requirements are written down.
• My team — what a group leader sees of these verdicts about their own members.
• All detections — the detections that fill the window, and where a set analysis is started.