Findings & Telemetry

Ask about your own findings and telemetry in conversation and your agent queries AlphaSOC directly, with no console to open and no query language to learn. It covers the questions that start with "we" or "our": what fired overnight, which hosts are involved, whether an address has been seen before.

That is the counterpart to Threat Intelligence, which answers what the wider internet knows about an indicator. This page answers what your environment recorded.

Requires an active AE license and the Guest role or above, the same access the console applies to reading findings, so you see the same findings through either surface.

How it works

You ask a question in plain language and the agent picks the tool that answers it. Four tools read your own data; the agent starts with the fastest one that can answer and escalates only when it has to:

Tool	Answers
findings_summary	What AlphaSOC detected, and whether an entity or indicator such as host, user or hash appears in any finding at all, with rankings by detection, MITRE technique, data origin or OCSF observables. The starting point for any findings question.
lake_search	Which raw records carry an exact value, and the whole record around it, from the fastest dataset that holds it.
wisdom_lookup	What the wider internet knows about a domain or IP. See Threat Intelligence.
kql_search	Everything the first three cannot: finding-level fields such as titles, evidences and statuses, and any filter, projection or aggregation of the agent's own devising. One dataset per query, and the slowest tool here.

There are also kql_datasets and kql_guide tools to help agents understand and make better use of kql_search.

So "have we seen 203.0.113.10?" is one quick summary call, not a query, and only a follow-up that needs the finding itself (its title, its evidences) goes as far as kql_search. You never see a query unless you ask for one; if an answer looks like it took the long way round, ask which tool was used.

Four datasets back the answers, and each tool reads the ones it is fastest over:

Dataset	Answers	Read by
Findings	What did AlphaSOC detect: severity, MITRE ATT&CK	findings_summary, kql_search
Evidences	Was this indicator ever seen: the quickest existence check	lake_search, kql_search
Activity	Who looked something up, and from where	lake_search, kql_search
Events	What exactly did a device, user or indicator do, raw log included	lake_search, kql_search

A few things shape the answers you get:

• Time range: Specify it; otherwise the agent may choose a range that is too broad or too narrow. Searches span up to 90 days per call.
• Results are capped: Broad searches may be truncated; use precise queries. You can also request a summary or top results.
• Text only: Counts, rankings, and breakdowns are supported; use the console for charts and graphs.

Presence checks and rankings

findings_summary is the tool behind most findings questions. It summarizes them by one of these kinds, letting you narrow results to the findings carrying specific values.

You do not have to know any of the names below to ask. "Which detections fired on WS-4821 last week" or "has this hash shown up anywhere" are both questions the agent should be capable of mapping onto them.

What you can summarize by

Kind	What its values look like
Detection	The detection that fired: a name such as rare_domain, or a bare UUID for one of your own Sigma detections
MITRE Technique	The ATT&CK technique, such as T1059
Data Origin	The log source behind the events a finding aggregated, spelled as the ingestion names such as aws_cloudtrail or okta
An OCSF observable type	Hostname, IP Address, User Name, Hash, File Name, Process Name, URL String, Email Address, Port, Country, Command Line, and the rest of the OCSF set

Narrowing and reading the result

Values can be matched exactly or by partial text, a severity floor keeps only the findings at or above it ("only severity 4 and above"), and results can be ordered by event volume, by severity, or by when a value was first or last seen. Each row of the answer says how many events the matching findings covered, how severe they got, and when the value was first and last seen.

This tool only ever sees findings; whether a host appears in your logs at all is a question for the raw records. Asking past the window findings are kept for is refused rather than answered empty.

Raw records

lake_search answers what was observed, not what was detected. It reads whole records straight out of the archive index, from one of three datasets:

Dataset	What one record is
Evidences	One observation AlphaSOC saw and scored: the quickest existence check
Activity	The same observation plus the device, user and log source behind it
Events	The whole normalized event, including the original raw log line

Each is slower than the one before, so a question stops at the first one that answers it: whether an indicator was ever seen at all is an Evidences read, who was behind it is Activity, and the raw log line is Events.

Matching is by exact value on an indexed field, not free text: the queried hostname, source and destination addresses and ports, URL parts, HTTP method and user agent, process file names and hashes, TLS certificate attributes and fingerprints. Activity and Events also index the device and user behind the observation. Values can be ORed together, and separate groups AND together, so one call covers "this hash or that hash, on this device". A read can also be narrowed to one kind of observation, such as DNS or TLS, or to a single log source. Anything outside the indexed set is refused, never quietly ignored.

Three limits shape what you get back:

• Whole records, at most 10,000 of them. Reading more means a narrower filter or a shorter window.
• No aggregation. It returns records; counting or grouping them is a job for kql_search.
• Every query needs a filter. An unfiltered lake read is refused outright, so "show me everything from yesterday" is not a question this tool takes.

One caveat before you read a timeline off it: Evidences timestamps are approximations of the ingestion time, not of when the event occurred. Use Activity when the exact time is needed; its timestamps come from the source.

The KQL tools

kql_search is slower but more flexible: it reads whole raw data rows and supports queries that need complex operations or the full data. It is meant for questions the tools above cannot answer. Each query operates on a single dataset and does not support joins.

Two companion tools help the agent write queries the engine accepts, and it reaches for them on its own:

• kql_datasets lists the dataset schemas, drilling one level at a time instead of dumping a full OCSF tree.
• kql_guide serves the KQL reference documentation: the dialect, query patterns, the data model, and a guide per dataset.

Asking good questions

Instead of	Ask
"Show me our findings"	"Show me high-severity findings from the last 7 days"
"List everything involving that IP"	"Which hosts contacted 203.0.113.10 last week?"
"How bad is it?"	"Group last night's findings by detection, worst first"

These habits make a noticeable difference:

• Give a time range. It is the single biggest factor in getting a precise answer quickly.
• Name the workspace if you belong to more than one ("in Production"). Ask "which workspaces can you see?" if you are not sure what they are called.
• Ask for a summary, not a dump. "Top 20 detections by volume" beats "all findings"; the former is one answer, the latter gets cut short part-way.

If an answer looks surprising, ask the agent which tool it called, with which filters and time range. That is usually enough to spot a misunderstanding. Be especially wary of an unexpected "nothing found" about a user or a host: the data holds the source's exact strings, so jane.doe matches nothing when the logs say jane.doe@example.com or CORP\jdoe. A careful agent resolves the stored form before concluding anything; ask it to search loosely for the name if it has not.

Examples

Triage what fired overnight

What fired overnight in Production? Group it by detection and show me the worst first.

You get a ranked list of detections with severities and how many events each one aggregated. It is the same picture as the console's findings view, read out in a sentence or two instead of a table you have to scan.

Scope an incident to a host or address

Which hosts contacted 203.0.113.10 in the last week, and what fired on them?

Questions pinned to a specific host or address are fast even over a wide window (90 days is the per-call maximum), so do not be shy about it when you are chasing something down. The exception is an indicator half the internet touches, such as a public DNS resolver or a CDN edge: that matches too much to list, so ask for a summary of it instead. Follow up in the same conversation, with "now show me just the workstations" or "what else did that host do that day", and the agent narrows without starting over.

Understand your coverage

Roll up the last 30 days of findings by MITRE ATT&CK technique.

Useful for reporting, and for spotting the tactic you have no coverage on. See MITRE Coverage for the full mapping of detections to techniques.

Find your noisiest detections

Which detections produced the most events last week?

The usual starting point for tuning. Once you know what dominates your volume, adjust it in Detections.

Break a trend down over time

How did high-severity findings break down per day over the last two weeks?

You get the daily counts as numbers. Charts are not produced over MCP; ask for a breakdown and read the figures, or use the console when you want a visualisation.

Ask whether something was seen at all, not just detected

Nothing fired on a1b2c3… in Production. Was that file ever observed at all?

Findings hold only what a detection fired on, so an empty summary means "no finding carried this", not "this never appeared". The observation records answer the second question, and they reach further back than findings do, which is also why an indicator can be absent from findings and still be in the data.

Follow a finding into threat intelligence

This is the workflow the MCP surface exists for, and it reads as one question:

Anything in our findings involving 203.0.113.10 in the last week? If so, look it up in Wisdom and tell me whether the hosts involved need isolating.

Your findings say who and when; Wisdom says what the address actually is. Neither answers the question alone.

When a question cannot be answered

The query engine supports a large but deliberate subset of KQL, and rejects anything outside it instead of guessing. In practice that means an agent occasionally has a query refused and retries with a different shape; you may see it take two attempts.

If it gets stuck, tell it to read the guides behind kql_guide: the dialect and patterns documents describe exactly what the engine accepts, and the per-dataset guides say which fields actually carry data, the usual cause of queries that come back empty instead of rejected.

A few questions simply have no answer in this data: anything about your ingestion configuration or your account, and anything further back than a dataset reaches. The agent knows each dataset's horizon and should say so instead of guessing; if it speculates, ask it which tool it used.