Skip to main content
Praxis Shield is the platform’s background safety layer. It reviews conversations across your Digital Twins in the background for signs of misuse: people trying to trick the twin into ignoring its instructions (prompt injection), trying to make it break its own rules (jailbreaking), fishing for passwords or details of how the system works, sending abusive email through it, or hammering it with automated traffic. Suspicious activity is assessed by an AI reviewer and surfaced to you as incidents for human review.
Detection never acts on its own. Praxis Shield does not block messages, interrupt conversations, or suspend anyone automatically. It flags, you decide. Every action taken on an incident is a deliberate reviewer decision, and every decision is recorded in the incident’s audit trail. Pria does not email you about new incidents — check the panel.
Praxis Shield complements Content Moderation: moderation screens individual messages as they are sent, while Praxis Shield reviews conversations afterwards for security and abuse patterns that only emerge in context.

Where to find it

Open Admin → Instances and switch the view at the top of the page to Threats Detection (Praxis Shield) (Studio UI: the Security threats tab of Instances, with a count of open incidents). The panel shows incidents from every Digital Twin you manage in one list, so you don’t have to check each one separately.
Privacy by scope. You only ever see incidents belonging to Digital Twins where you hold admin rights — enforced on every request. Other Digital Twins’ incidents are invisible to you, and yours are invisible to their admins. End users see nothing at all: scanning is silent and changes nothing about their experience.

The incident list

Each row is one incident — a user whose recent activity triggered detection — showing its status, severity, the user (name and email), the Digital Twin(s) involved, category badges, when the activity was last seen, and when it occurred and was first seen. By default the list is ordered by first occurrence, newest first; untick Order by first occurrence to sort by severity, then most recent. Scroll to load more, and use the refresh button to pick up new incidents.

Filters

Severity levels

Status lifecycle

Incidents move through a simple workflow:
  • open — newly detected, not yet reviewed
  • reviewing — a reviewer is investigating
  • escalated — needs attention from another reviewer or your security team
  • resolved — reviewed and closed
  • false_positive — reviewed and judged benign
Resolved and false-positive incidents drop off the default Active view and stay available (set the status filter to All) for 90 days from detection; then they are removed, notes included. Open, reviewing and escalated incidents are kept.

Categories

Category badges tell you at a glance what kind of behaviour was detected — for example prompt injection, jailbreak attempts, credential-exfiltration attempts, probing of internal systems or authentication, email abuse, misuse of tool chains, unusual automation volume, or coordinated activity across accounts. One incident can carry several categories.

The incident report

Click the report icon on any row to open the full incident report with its management controls. Evidence tabs:
  • Summary — what happened, in plain language, with the assessed impact
  • Signals — the specific detection signals that fired
  • Evidence — the relevant conversation transcripts (inputs, outputs, and tool activity)
  • LLM Adjudication — the AI reviewer’s assessment of the evidence
  • Cost — usage of the flagged conversations, and what the review itself cost
  • Cluster — shown when the incident is part of coordinated activity across accounts
Workflow tabs:
  • Workflow — change the incident’s status and severity
  • Reviewer Notes — add timestamped notes for yourself and other reviewers
  • Action History — every status and severity change, recorded action and suspension, with who did it and when (notes stay under Reviewer Notes)
Use the previous/next arrows to move through the incident list without leaving the report.
Evidence transcripts are written by the very users being investigated, so the report renders all of it as inert plain text — no formatting is interpreted and URLs are never clickable. This protects reviewers: a malicious link planted in a flagged conversation cannot be opened by accident. Don’t copy URLs out of evidence and visit them.

Triaging an incident

1

Open the report

Start from the highest-severity open incidents. Read the Summary, then check the Evidence tab to see the actual conversation.
2

Mark it as reviewing

Set the status to reviewing, and adjust the severity up or down if your reading of the evidence differs from the initial assessment.
3

Record what you find

Add a reviewer note summarizing your conclusion. Notes are visible to other admins of the Digital Twin and stay with the incident (resolved and false-positive incidents are removed after 90 days).
4

Close it out

Set the status to resolved (real issue, handled), false_positive (benign — e.g. a security class legitimately discussing injection techniques), or escalated if someone else needs to take over.

Suspending a user

If the evidence warrants it, Suspend user in the report’s footer (Suspend in this Digital Twin) sets the person’s membership in the affected Digital Twin(s) you manage to inactive — they immediately lose AI access there (they are not signed out), while their memberships in other Digital Twins are untouched. The suspension is recorded in the incident’s action history, and you can reinstate the user at any time from Users. You cannot suspend yourself from an incident.

Marking false positives

Set the incident’s status to false_positive in the Workflow tab. The incident leaves the active queue and stays available under All until it is removed 90 days after detection.

Sharing an incident report

Every report has a Copy report link button that puts a shareable URL on your clipboard. Send it to a colleague to put them in front of the exact same report. The link is safe to share because it is login-gated: the recipient must sign in, and the server only serves the report to admins of the incident’s Digital Twin(s). Anyone else gets “Access denied”. The shared view is read-only.

Researching further

An incident is often the starting point, not the whole story:
  • View flagged history (the eye icon on a row) shows the exact conversation records that triggered the incident — inputs, responses, and tool activity — rendered as plain text (rows from Digital Twins where you lack histories.list are withheld).
  • Histories lets you search the user’s wider conversation activity in the Digital Twins you manage.
  • Sessions shows where and on what devices the user has been signing in — useful for judging whether an account is shared or compromised.

Required permissions

See Entitlements for how to grant these.
  • Content Moderation — real-time screening of individual messages as they are sent
  • Histories — search and review conversations across your Digital Twins
  • Sessions — who signed in, from where, on what device
  • Users — membership status, suspension, and reinstatement
  • Entitlements — the institutions.* permissions behind this panel