How Google’s console explains itself
Before adding anything to a console, read what’s already there. This is what a Google SecOps case explains on screen, and what it leaves to the documentation.
Contents
Before arguing that a console is hard to read, count it. A number can be disputed; an adjective cannot.
So an AI agent counted every icon, badge, colour and label in one case investigation view, by written rules: one row per mark per place, colours that vary get their own row, and near-universal conventions count as readable but are flagged.
By the AI agent’s count, under those rules, 51 of the 72 marks that are not text have no meaning stated on screen.
Two things have to be said in the same breath as that number. Static screenshots cannot show tooltips, so some of them may speak on hover; the audit lists exactly which rows to check in a live tenant. And the console does one thing here that nothing else in the study does: the Security Graph, one click away, carries its own legend in the product, naming every shape and colour it draws.
What “explained only in the docs” looks like
This is the case header, as Google’s own documentation draws it. The green arrows are the documentation’s; the product has none of them.
Look at the left edge. A red bar, and nothing beside it says it means priority. The words are on a documentation page, and in the Priority dialog, one menu away, which names each colour. The stage is a circular arrow. The time is a clock. On the header, all three are marks with no words.
Hold on to that red bar. Option 0, one of the six designs in How it was made, put a red bar down its own card to mean Malicious, and failed a gate for it.
The Case Wall — the running record of everything that happened to a case — carries eight more, and these are Google’s images too. Not one of them carries a word.
In the order shown, they mean: actions taken on alerts · case status changes · task details · a comment · insights · a pinned chat · a favourite · the sort order. The screen says none of it. The pairings come from one documentation page, and there is nothing on screen that would get you there.
The verdict this study is about is Wiz Blue Agent’s: Wiz’s AI investigates a threat and returns a verdict, such as MALICIOUS, with a confidence and a conclusion. In the integration as published, it reaches the analyst one of two ways. Where an admin has added it, a ready-made widget lists the result’s seven fields as rows. Otherwise it arrives as verdict: MALICIOUS — a string inside a JSON tree, five selections into the case by the AI agent’s count of the published screenshots. The Case Wall entry for the same action says the analysis was returned. It never says what it concluded.
So: raw, or hard to find — and either way silent about what it covered or what came after.
You can try both. The prototype on the case study page opens on Today: Google’s widget, running its own code. Without a widget, the verdict exists only as raw data, behind the playbook’s results.
Whoever ships an agent into a console cannot design what the console controls, so the constraints come before the criteria. The console documents three layers, and only the third belongs to the integration.
| Layer | Who controls it | What that means here |
|---|---|---|
| The console | Case queue, case header, the priority bar, Escalate and Close, the tab strip, the Case Actions menu and the Manual Action dialog, and what the host’s own widgets show, such as Alerts and Entities highlights. A design that needs any of this to change is answering a different question | |
| The Overview grid and playbook views | The customer’s admin | The admin decides which widgets exist, where they sit and how wide they are, and builds HTML widgets that read an action’s result (Safe HTML returns them “without potentially malicious JavaScript”). An integration cannot assume its card is installed at all, or that it sits where its maker drew it |
| The widgets themselves | The integration | Ready-made widgets for some actions (partners write them in the content hub, Google publishes them, and admins can change only the name, description and conditions). Insights the action writes, in basic HTML without scripts. Its actions, which an analyst runs from Quick Actions, the Manual Action dialog, or a Pending Action (the playbook pauses and asks). Plus a Case Wall entry and the action’s result, which always exist |
The constraint that shaped the card most: the HTML widget displays, it does not write. Anything that changes the case has to be a Quick Action button or a Pending Action choice. So “accept or override” is not a button a designer may simply draw — it is a documented action type or it does not exist. The one documented exception is an approval link, which can sit inside an HTML widget to approve or decline a playbook step that is waiting. Option 0, one of the six designs in How it was made, drew the buttons anyway, and failed a gate for it. So did this card’s own first version, until 27 September; what changed.
And because the admin owns the grid, the card cannot be the only place the verdict lives: whatever the integration writes to the Case Wall has to carry it alone, for every tenant that never installed the widget.
Some things already cross between the two products, where an admin runs the integration’s sync job. It raises an alert’s priority in SecOps when Wiz rates the threat higher, and never lowers it. Once every alert that carries a threat is closed, it updates the threat in Wiz from the close reason. Comments go both ways. No field carries whether the analyst agreed with the agent’s verdict.
The eight rules aren’t invented. The two consoles checked already do much of this for the AI they build themselves, Google’s more fully than Microsoft’s. What they don’t do is give the same standing to an AI from another product — in Google’s case, even one it now owns.
| SecOps’ own agent | Microsoft’s own AI | Wiz’s verdict in Google’s console (Google-owned since March 2026) | |
|---|---|---|---|
| Where it shows | A banner in the case summary | The incident page, as it opens | A ready-made widget, if an admin added it; otherwise raw data |
| When it ran | Completion time on every entry | Not stated on the card | A raw timestamp, with no age |
| What it used | Its reasoning and supporting data | Its alert limit, stated | Not carried |
| When the case changes | Each re-run kept as its own entry | Reused only if the incident “didn’t change significantly” | Nothing. A snapshot |
Sources: Google’s agent documentation (the case-summary banner is on Enterprise tiers) · Microsoft’s incident-summary documentation. Splunk, Palo Alto and CrowdStrike weren’t checked; their AI documentation is mostly behind logins.
SecOps’ own agent gets a date. Wiz’s verdict gets a raw timestamp. Microsoft redisplays a cached summary only if the incident “didn’t change significantly”: a test like this card’s Outdated state, used there to decide whether to reuse a summary. A date is parity. Saying Outdated on screen is new.
And it points at what comes next. SecOps’ own agent auto-investigates cloud audit-log alerts, which is the kind of alert that made the bucket public. So in that case, it could well reach its own verdict on the new alert — true positive, in its vocabulary — while Wiz’s earlier benign sits in its widget or the raw data, in a different vocabulary, with nothing to reconcile them. Two AIs, one case is the problem this card doesn’t solve yet.
The published screenshots show the legacy case view, and that is the view the audit counted on 17 September. Google’s revamped Investigation Management view had been in public preview since 26 July, with side-drawer previews. On 18 September its side panels became resizable. Nothing affecting the count changed after the audit (what changed).
The layout will date. By the revamped view’s documentation, all eight rules still apply, and two of them gain a case.
Rule 1 gains a second width: the revamped view has a side-drawer preview beside the queue, resizable since 18 September, so “the view the case opens to” means two densities. Rule 7 gains the migration case: the revamped view’s new default views don’t include custom widgets from the legacy views on their own, so an admin adds them back. Until then its widgets are missing from those views, and its Case Wall entry and insights are what still arrive.
The count was not re-pointed at the new view. It publishes no screenshots, and no verdict from another product has been shown inside it, so a count there would be assertion rather than evidence. What changed is recorded instead, and the audit says at the top which experience it covers.