AI analyst
Overview
Section titled “Overview”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.
Weekly briefing
Section titled “Weekly briefing”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.
Which alerts are investigated
Section titled “Which alerts are 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:
| Reason | What it means |
|---|---|
| Duplicate | An alert with the same dedupe key was investigated within that kind’s dedupe window (an hour unless the kind says otherwise). |
| Storm | The organisation has reached its hourly cap of automatic investigations. Alert storms cannot start hundreds of runs. |
| Budget | Today’s token or cost budget is spent. |
| No model | No AI model is configured for the environment. |
| Expired | The 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.
Privacy
Section titled “Privacy”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.
Budgets and limits
Section titled “Budgets and limits”The analyst’s settings apply to the whole organisation:
| Setting | Default | What it does |
|---|---|---|
| Investigate alerts | On | Turns automatic investigations on or off. |
| Investigate alerts from | Warning | The severity floor. |
| Daily token budget | 1,000,000 | Tokens a day across the organisation, reset at midnight UTC. |
| Daily cost budget | $10 | Estimated cost a day (approximate; see Limits). |
| Runs per hour | 20 | No more investigations than this start in any hour. |
| Pseudonymise people | On | See 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.
Feedback and triage
Section titled “Feedback and triage”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.
Permissions
Section titled “Permissions”| Permission | What it allows | Level |
|---|---|---|
| View AI analyst findings | Read findings and alert investigations, and mark them useful or noise | Per project |
| Triage AI analyst findings | Change status, select Investigate now, Run checks now and Write now for the weekly briefing | Per project |
| Change AI analyst settings | Change the organisation’s analyst settings | Organisation 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.
Personal data
Section titled “Personal data”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.
Limits
Section titled “Limits”- 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.