Lookups and watchlists

A lookup is a small, tenant-owned reference table you upload as a CSV: a name, a key column, and whatever other columns you gave it. Two things read a lookup today — a scheduled rule's absence-mode watch list, once the rule editor supports pointing at one, and an automation rule's enrich action, which does today.

Nothing ships pre-populated. There is no starter list of VIP users, terminated employees or known-bad IP addresses waiting for you to enable — every lookup in your organisation is one you built yourself, from a file you uploaded yourself.

Creating a lookup

SIEM → Lookups (/siem/lookups). A create modal asks for a name, a kind, a key column, and a comma-separated list of the other columns the file carries. The key column is what a matching lookup is matched against — an event's field value is compared to the key column's values, and a match is a hit.

Once the lookup exists, upload its rows as a CSV file — a native file picker, and the file's raw text is posted directly as the request body rather than wrapped in a JSON envelope, since the upload endpoint reads the request body as CSV bytes.

Where a lookup is actually used

A scheduled rule's absence-mode watch list

The intended eventual use, and not wired yet. Absence mode needs a universe of entities to watch, and today that list is hand-entered directly on the rule rather than drawn from an uploaded lookup — see Scheduled detection rules and templates for the precise state of that gap.

An automation rule's enrich action

Real today. When an automation rule's enrich action runs, it checks the incident's entities against your lookups by exact key match and stamps a hit onto the incident. This is also how a scheduled rule's own event fetch enriches candidate events as it pulls them — every candidate event's source address, destination address, user, asset or file hash is checked against your tenant's lookups in one batched query per run, not one query per event, and a hit is stamped onto the event's metadata.

What is not built yet

• No seeded starter lists. No VIP-users, terminated-employees or known-bad-IPs template ships with the product. You build every lookup from scratch, by uploading your own CSV.
• No row browser. GET .../siem-lookups/{id} returns a row count for the lookup, not the rows themselves. There is no way in the console or the API today to see what is actually inside an uploaded lookup after the fact — you have to keep your own copy of the source file if you want to check what you uploaded.
• No edit or delete of an existing lookup. Once a lookup exists and has rows, there is no route to change its rows, its columns, or its key, and no route to delete it. If a lookup needs to change, there is no in-place way to do it today.

None of these are deferred console screens sitting on top of a complete API — the row-browser and edit/delete gaps are genuine backend gaps, the same distinction that matters elsewhere in this wave: the console cannot show you what the API itself does not yet expose.

What to read next

1. Scheduled detection rules and templates — absence mode, and exactly what is missing to wire a watchlist into it.
2. Automation rules and proposals — the enrich action that reads a lookup today.
3. External threat-intel enrichment — the other kind of enrichment enrich can also do, against outside reputation data rather than your own uploaded list.