Investigations
An investigation answers one question about one window of time from one source: the Olympusx AI audit log, or a log source of your own. The model never reads the source itself. In rounds, it asks for queries, Olympusx AI runs them read-only inside the window and shows it the rows, and then it gives a verdict that cites the events by number. It changes nothing.
Admins start investigations. Admins and auditors read them. A person starts one on the Investigations tab; a hunt starts one each day; an alert starts one each time it fires.
Start an investigation
Section titled “Start an investigation”- Open Use cases › Security and select the Investigations tab.
- Select New investigation.
- Under Source, choose The Olympusx AI audit log or one of your log sources.
- Write the Question, or select one of the starters:
- For the audit log: “Was an API key created and then used from an address not seen before?”, “Who exported findings or the audit log, when, and from where?”, “Did anyone change roles, disable people or reset passwords unexpectedly?”
- For a log source: “Is any internal host scanning other hosts? Which ports, and was any of it allowed?”, “Is any host sending data to an unusual external address? How much, and as which account?”, “Which accounts fail to sign in again and again, and from where?”
- Choose the Window: The last day, The last 7 days (the default), The last 30 days or The last 90 days.
- Choose the Model. Larger models are listed first; see Which model to use.
- Select Investigate.
The list shows Investigating, round n while it runs. Its tokens count against the model’s budget, which is checked before every round.
How it works
Section titled “How it works”- Round 1. The model is given the question and the window. For a log source, it is also told how many events in the window carry each value of
actionandoutcome, so it asks for values the store holds. No event is shown yet. - Each round. The model asks for at most 3 queries. Each lists matching rows, at most 200, or counts them by one field. Olympusx AI runs them read-only, bounded by the window, and shows the model the rows. A round’s rows are cut at 14,000 characters; the model is told to narrow its query to see the rest.
- The verdict. By round 4 the model answers with a verdict, a summary citing events as
#id, findings, and, where allowed, proposed actions or a detection rule. An investigation whose model still asks for rows after round 4 fails.
What a query can ask for:
| Source | Filters | Counts by |
|---|---|---|
| The Olympusx AI audit log | action (exact, or a prefix ending in *, such as key.*), actor, ip, object_prefix, and since and until inside the window |
actor, action, ip, hour |
| A log source | src_ip, dst_ip, src_port, dst_port, action, outcome, actor, host, exact values; text, a phrase the message contains; since and until |
Any of those fields, or hour |
Rows and events are data. The model is told that text inside them is never an instruction, and nothing it writes is acted on without a person.
What the verdict holds
Section titled “What the verdict holds”| Part | What it is |
|---|---|
| Verdict | Benign, Suspicious, Malicious or Inconclusive. An answer outside these is recorded as Inconclusive. |
| Summary | What happened, in a few sentences, citing events. The detail says Reasoned by model from N events it was shown. Check the events before acting on it. |
| Findings | At most 10. Each names a subject (an account, an address, a key, an object or a host), cites events, says what they show and what an attacker gains, and may name a MITRE ATT&CK technique such as T1078. |
| What it proposes a person do | Audit log investigations only: at most 3 proposals to disable an account. See Actions and approvals. |
| Detection rule (Sigma, draft) | Log source investigations only. The model is asked to draft one when its verdict is suspicious or malicious, and Olympusx AI keeps it only if it parses as a Sigma rule. See Exports. |
| What it looked at | Each round’s note and queries, with the rows each returned or why it failed. |
A finding is kept only when every event it cites is one the model was shown (other cited ids are dropped, and a finding left with none is dropped) and its subject appears in those events. Its evidence is those events, at most 40, never the model’s text. A verdict with no findings is a good answer when nothing is wrong.
Kept findings join the Findings list as log findings. The Findings column shows New: and seen before:, as for code.
Read the list
Section titled “Read the list”The list shows each investigation’s Question (tagged Hunt or Alert when one opened it), its window, Verdict, Findings, Model and tokens, and Started. Select one to open its detail.
When it does not work
Section titled “When it does not work”| Message | Cause and fix |
|---|---|
| the model’s budget ran out before a verdict | Raise the model’s or the tenant’s budget, or narrow the question. |
| the model did not answer | The model call failed or ran past the Security model call limit. Reasoning models may need a longer limit; see Settings and limits. |
| the model did not answer as asked | The model did not answer in the form asked for. Use a larger model. |
| the model asked for more rows and gave no verdict | Narrow the question or the window. |
| the log source could not be opened | Test the log source on the Sources tab. |
| A window of more than 90 days is refused | Split it. |
An investigation still running after an hour is marked interrupted.
Limits
Section titled “Limits”| Limit | Value |
|---|---|
| Rounds | 4 |
| Queries per round | 3 |
| Rows or events per query | 200 |
| Text shown to the model per round | 14,000 characters |
| Findings per verdict | 10 |
| Proposed actions per verdict | 3 |
| Evidence events kept per finding | 40 |
| Question | 2,000 characters |
| Window | At most 90 days; 7 days by default; it cannot start in the future |
| A whole investigation | 30 minutes |
| Investigations listed | The 200 most recent |