AI risk register

Overview

Govern → Compliance program → Risk register lists the AI risks in the current environment. Most of them are raised by the risk scan, which runs every hour over the AI inventory and the last 30 days of violations. You can also add risks the scan cannot see, such as a vendor contract or a regulation.

Each risk has:

• a title, category and description
• a likelihood and an impact, each from 1 to 5. The score is likelihood × impact, from 1 to 25
• a status: open, being treated, accepted or closed
• a treatment (mitigate, accept, transfer or avoid) and a treatment plan
• an owner and a review date
• the AI inventory assets it is about
• for a risk the scan raised, the evidence it was raised on: counts, the first and last time it was seen, how many people were involved, and a link to the violations or the asset

Evidence never contains a prompt, a value a guard stopped, or the names of the people involved. It gives their number, and the link opens the page that already shows them to people allowed to see it.

The page

• Tiles count open risks, high and critical risks, risks raised from observation, risks with no owner, risks past their review date, and accepted risks (with how many acceptances run out within 30 days).
• The heat map places open risks and risks being treated on a 5 × 5 grid of likelihood against impact. Select a cell to list its risks.
• The table lists risks worst first. Filter it by status, category, level, source (observed or entered by hand), owner or text.
• Select a risk to open it. You can see its evidence and linked assets, and, with permission, change it.

Levels follow the usual bands of a 5 × 5 matrix:

Score	Level
1–4	Low
5–9	Medium
10–16	High
20–25	Critical

Risks raised from observation

Rule	Raises a risk when	Category
rejected_in_use	An asset your team rejected in the AI inventory is still in use	Unapproved AI
shadow_ai	A tool, application, agent or MCP server is in use, outside the approved list, and nobody has recorded a decision about it	Shadow AI
unapproved_model	Requests went to a model or provider outside the approved list (warned or blocked)	Unapproved AI
sensitive_data	People were warned about sensitive data they sent to AI, or sent it anyway. Blocked and masked data is not counted, because it never left	Data leakage
prompt_injection	Prompt injection was detected in what an agent read or sent	Prompt injection
agent_sequence	An agent broke a sequence policy	Excessive agency
unowned_asset	An asset used by ten or more people, used heavily, or rated high risk has no owner	Compliance
unused_access	The agent access review found an agent holding grants it does not use	Excessive agency
decision_lapsed	A decision recorded in the AI inventory has expired	Compliance
key_hygiene	Key hygiene flagged a live vendor key (owner disabled, no owner, stale or never used)	Vendor

Violations are grouped by tool or, for unapproved models, by model, so there is one risk per tool or model, not one per event.

Likelihood follows how often something was seen in the window: once is 1, twice 2, five times 3, 25 times 4, and a hundred times 5. It drops by one when nothing has been seen for two weeks. Sensitive data sent anyway adds one. Impact follows what was at stake: the severity of the data, whether a request or an injection got through, or how serious the key issue is.

How the scan keeps the register current

Each risk the scan raises has a key made of the rule and what it is about, for example sensitive_data:cursor. Each run finds the same risk again rather than adding another:

• A new finding creates an open risk.
• An open risk, or one being treated, gets fresh evidence and likelihood. The impact, owner, treatment, status and linked assets your team set stay as they are. The scan may add assets, but it never removes them.
• A closed risk stays closed. It reopens only when the evidence was observed after it was closed.
• An accepted risk is not touched while the acceptance stands. When the acceptance runs out, the risk reopens and an alert is raised.

A run creates or refreshes at most 200 risks per environment, worst first. Two runs at the same time cannot create the same risk twice.

Accepting a risk

To accept a risk, set its status to Accepted and give:

• a rationale: why the organisation accepts it
• an expiry: the date the acceptance runs out. It must be after today and within three years

Shield360 records who accepted the risk and when. If you change the rationale or the expiry, that counts as accepting it again. If you move the risk out of Accepted yourself, the acceptance is cleared. When the scan reopens a risk because its acceptance ran out, the page shows that the acceptance lapsed.

Alerts

Kind	When	Dedupe key
risk.threshold	An AI asset’s risk score rose to the threshold since the previous scan. Each crossing is raised once; an asset that drops below and rises again is raised again. The first scan in an environment records the assets already above it without an alert.	risk:threshold:<asset key>:<day>
risk.acceptance_expired	An accepted risk’s acceptance ran out and the risk reopened. Each lapse is raised once.	risk:acceptance:<risk id>:<expiry>

Both are warnings. A single scan raises at most 25 of each. The acceptance alert gives the risk’s category and score, not its title, because a risk entered by hand may name a person. The threshold alert names the asset and the main factors in its score.

The threshold is 70 by default. To change it, select Score alert at on the heat map panel. It applies to the current environment.

To send these alerts to a channel, add an Event rule for the kind under Alerts → Rules. The scan’s schedule can be changed with the AI_RISK_SCAN_SCHEDULE environment variable, which takes a cron expression. The default is 47 * * * *, a few minutes after the inventory scan.

Export for auditors

The page has two downloads, both limited by the filters you have set:

• Export CSV: one row per risk, with its ratings, level, status, treatment and plan, owner, review date, linked assets, source, evidence summary and acceptance.
• Export JSON: the summary, the heat map, the threshold and every risk in full.

You can also call the API directly:

curl -H "Authorization: Bearer $SHIELD360_API_KEY" \
  -H "x-shield360-organisation-id: $ORG_ID" \
  -H "x-shield360-project-id: $PROJECT_ID" \
  -H "x-shield360-environment: production" \
  "https://your-shield360-host/api/governance/risks/export?format=csv&status=live"

The filters are status (open, treating, accepted, closed, or live for open and being treated), category, level (low, medium, high or critical), source (auto or manual), owner (text, or unassigned), asset (an inventory asset key) and q (text in the title or description).

API

Method and path	Does	Permission
GET /api/governance/risks	Lists risks with the summary and heat map; takes the filters above	risk.read
POST /api/governance/risks	Adds a risk: title, category, likelihood and impact are required	risk.manage
GET /api/governance/risks/<id>	Returns one risk	risk.read
PATCH /api/governance/risks/<id>	Changes a risk; send only the fields to change	risk.manage
PUT /api/governance/risks/settings	Sets scoreThreshold (1–100)	risk.manage
GET /api/governance/risks/export	Downloads the register	risk.read

Malformed JSON and invalid values return 400. A risk in another environment returns 404.

Permissions

Permission	Allows	Held by
risk.read	Viewing and exporting the register, and seeing the risks linked to an inventory asset	Owner, Administrator, Compliance officer, Analyst, Member, Viewer
risk.manage	Adding and changing risks, accepting them, and setting the score threshold	Owner, Administrator, Compliance officer

Both are project permissions, so a project role can grant or withhold them in one project. The server checks them on every request. Every read and change applies to the environment you have selected. A database config named in the request is ignored.

Each change is written to the audit log as risk.create, risk.update or risk.settings.update. The entry records which fields changed, the category, likelihood, impact, score, status, treatment, acceptance date, expiry and review date. It does not record the title, description, owner, treatment plan or acceptance rationale, because they may name a person. Exports are recorded as data access (risk.export).

Personal data

The title, description, treatment plan, owner and acceptance rationale are free text and can name a person:

• A person export includes every risk in which one of those fields names the person as a whole word.
• Erasure clears those fields and keeps the risk. A title that names the person is replaced with a neutral one.
• An organisation export includes every risk as ai_risks, and the threshold as ai_risk_settings.

Limits

• Violations link to inventory assets by the tool and model they name. A violation from a tool the inventory does not know still raises a risk, but it is not linked to an asset.
• The number of people in a risk’s evidence is the largest count in any one group of violations. It is never more than the true number, but it can be less.
• The scan reads the last 30 days of violations and the inventory’s 90-day lookback. Older behaviour does not raise or refresh a risk.