Skip to content

AI analyst

The AI analyst does the first look at an alert that people tend to skip. When an alert is raised, the analyst queues an investigation. A few minutes later the alert carries a short report:

  • What happened
  • Scope: who, what and where is affected
  • When it started
  • Likely cause
  • Related signals: earlier occurrences, other alerts around the same time, spend
  • Recommended action
  • Confidence: high, medium or low, and why
  • Could not check: what it could not verify

Each report is stored as a finding. Findings appear under the alert in Alerts, and in Detect & respond → Detections → Analyst findings. The analyst’s own daily checks add their findings to the same inbox: the plausibility auditor, the cost waste finder, policy tuning and the unknown-AI classification, and stories and behaviour drift: risk signals that only matter together, and agents, people and MCP servers whose behaviour moved away from their own normal. So does the weekly briefing.

The analyst gathers evidence with read-only tools: the alert’s history, related alerts, and the same spend report Rex uses. It cannot change anything. It does not have Rex’s tools that create rules, prompts or secrets, or the tool that reads request contents.

Every Monday at 08:00 in your organisation’s time zone (UTC if none is set), the analyst writes a briefing for each environment, for a CISO and a CFO. It covers the previous seven days:

  • Spend this week against last week, from the spend report the executive summary is built on
  • Top risks from the risk register
  • Control status for each framework, and the change since the last briefing
  • Notable findings, and the open cost findings’ possible monthly savings
  • Violations this week against last week, with how many were blocked and how many were sent anyway
  • Inventory changes: AI assets first detected this week
  • Decisions lapsing in the next 14 days: inventory decisions and accepted risks

The numbers are gathered first. Each source is read separately, and one that cannot be read is named in the briefing as not available. The model then writes the prose from those numbers only. It gets the figures as data, pseudonymised like every other analyst run. Before the prose is kept, every number in it is checked against the figures. If any number does not appear there, or the model could not run (the analyst is off, no model is configured, or the budget is spent), the briefing is assembled from the figures without prose. The briefing says which.

The briefing is stored as a finding (Weekly briefing), one for each environment and week. The new one resolves last week’s. The latest briefing also appears on the Executive page. A role that may triage findings can select Write now there to rewrite this week’s briefing, at most once every ten minutes. This is recorded in the audit log.

When a week’s briefing is first written, the analyst raises an analyst.weekly_briefing alert at info severity. Add an event alert rule for that kind to send it to Slack, Microsoft Teams, email or a webhook. The alert carries only a link to the briefing and the week. The briefing’s text and anything about people stay in Shield360. These alerts are never investigated.

An alert is investigated automatically when the analyst is on and either:

  • its severity is at or above the organisation’s severity floor. The default is warning, so warning and critical alerts are investigated.
  • the feature that raised it asked for an investigation. Detections can set the attribute investigate: true.

Some alerts are still skipped, and the alert says why:

ReasonWhat it means
DuplicateAn alert with the same dedupe key was investigated within that kind’s dedupe window (an hour unless the kind says otherwise).
StormThe organisation has reached its hourly cap of automatic investigations. Alert storms cannot start hundreds of runs.
BudgetToday’s token or cost budget is spent.
No modelNo AI model is configured for the environment.
ExpiredThe investigation waited more than a day to run.

For any alert that was not investigated, someone whose role may triage findings can select Investigate now. The budget and hourly cap still apply.

Alert notifications never wait for an investigation. Slack, Microsoft Teams and email channels that received the alert also get a short follow-up when the investigation is ready. It says Investigation ready and links to the finding. It does not include the findings, the alert’s text or any personal data. PagerDuty and webhook channels do not get the follow-up, because a second PagerDuty event would re-trigger the incident.

The analyst builds what it sends the model from aggregates and metadata only: counts, kinds, severities, times, tool and model names, and rule settings.

It never sends:

  • prompts or responses
  • the values a guard found (card numbers, keys, personal data)
  • secrets, tokens, API keys or authorisation headers

Fields with these names are removed from alert attributes and tool results before the model sees them. Strings shaped like credentials are redacted.

People are pseudonymised by default. Each person and machine gets an alias for the run, such as person-1 or machine-2. The alias is the same everywhere in that run: in the alert, in tool results and in free text. The analyst also hides other spellings it can derive from the email or handle. For ana.lima@acme.com that includes “Ana Lima”, “Ana” and “Lima”.

Before each run, the analyst loads the people and machines the environment is known to have. They come from these sources:

  • user and computer names the collector saw in the last 30 days
  • enrolled computers and the accounts they were enrolled from
  • subscription seats and their display names
  • AI inventory owners
  • people and machines named in the organisation’s recent alerts

A name from this roster is pseudonymised wherever it appears, including in an alert’s free-text title or body and in tool results. Emails are always pseudonymised. Matching is case-insensitive and on whole words only, so the rest of the text is unchanged. For roster names, the analyst matches full names, handles and emails, but not a lone first or last name, because those would hide ordinary words. The roster is capped at 8,000 spellings for each run. The model writes its report using the aliases, and the stored finding keeps them. The real names are added back only when the finding is shown in Shield360, and only to roles that may see people (View computers and people). Everyone else sees the aliases.

An administrator can turn pseudonymisation off under Settings → AI analyst. Names are then sent to the model, but content and credentials are still never sent.

The analyst uses the model Rex uses in each environment. That is the provider and key saved in Chat settings, or Shield360’s managed model in the cloud. On a self-hosted installation, nothing leaves your network except calls to the model you configured.

Every run is recorded with what it was about, the model, the tokens, the estimated cost and the outcome. The record also counts its inputs, such as how many attributes there were, how many people were aliased and how many fields were withheld. The prompt itself is never recorded.

The analyst’s settings apply to the whole organisation:

SettingDefaultWhat it does
Investigate alertsOnTurns automatic investigations on or off.
Investigate alerts fromWarningThe severity floor.
Daily token budget1,000,000Tokens a day across the organisation, reset at midnight UTC.
Daily cost budget$10Estimated cost a day (approximate; see Limits).
Runs per hour20No more investigations than this start in any hour.
Pseudonymise peopleOnSee Privacy.

Each run is capped at ten tool steps and has a time limit. If a run uses up its steps while still gathering evidence, the analyst asks the model once more, without tools, to answer from what it has. Budgets are checked before each run starts, so the last run of a day can take it slightly over budget. In the cloud, analyst usage is metered to your organisation in the same way as Rex’s.

The settings page shows the model in use, with a link to change it, and this month’s runs, tokens, estimated cost, findings and feedback.

Each finding has a status: new, acknowledged, dismissed or resolved. Anyone who can view findings can mark one Useful or Noise and add a note. Feedback records who gave it and when, and it is counted on the settings page. Only roles that can triage findings can change a finding’s status.

PermissionWhat it allowsLevel
View AI analyst findingsRead findings and alert investigations, and mark them useful or noisePer project
Triage AI analyst findingsChange status, select Investigate now, Run checks now and Write now for the weekly briefingPer project
Change AI analyst settingsChange the organisation’s analyst settingsOrganisation only. A project role cannot grant it.

Every role that can view alerts can view findings. Administrators, compliance officers and analysts can triage findings. Only administrators can change the settings.

Findings, and each environment’s approved and rejected AI catalogue entries, are included in the organisation export. A person export includes every finding whose aliases stand for that person or whose text names them. Erasure removes the person from those findings and keeps the findings. The alias can no longer be resolved to a name, and any name in the text is replaced.

  • The analyst reads Shield360’s own data: alerts, alert history and spend. It does not read request contents, so it cannot say what someone actually asked a model.
  • Pseudonymisation replaces the names it knows. Those are names in the alert and tool results, the environment’s roster, the spellings derived from them, and email addresses. A person Shield360 has never seen, named only in free text, can still reach the model.
  • An alert raised for a whole project or organisation, rather than for one environment, is investigated in the project’s production environment, or its oldest environment if none is called production. Its finding appears in that environment’s Findings. Status changes must be made there, though the investigation also shows under the alert.
  • Cost is an estimate. The analyst uses Rex’s flat per-token estimate, not your price table or the provider’s bill. Budgets and the cost shown on the settings page are approximate.
  • Confidence is the model’s own judgement. Check findings against their evidence links before you act on them.
  • Investigations run on a schedule, every two minutes by default. Self-hosted installations can change this with AI_ANALYST_SCHEDULE.