SOC work is a constant triage exercise.
For SOC analysts, this means moving through alerts from SIEM, EDR, email security tools, identity systems, network logs and user reports, then deciding what needs action and what can be closed as a false positive. For MSSP teams, on top of that, it means working across multiple customer environments, each with its own tools, baselines, noise level, escalation rules and expectations.
But alerts rarely come with enough information to make a decision on the spot.
A SIEM alert, an EDR event, a user-reported phishing link, a suspicious IOC may be important… or it may be yet another false positive. And if, like us, you occasionally fall into r/cybersecurity threads at night “just to check one thing”, you quickly find SOC analysts casually mentioning false positive rates at 90% and even higher.
Before an analyst can close the ticket, escalate to L2, notify a customer or recommend containment, they have to understand what happened, what matters, what is missing and what evidence supports the decision. That is where time gets lost.
Not in one big task, but in the repeated work of checking indicators, reading logs, switching between tools, rebuilding timelines, comparing sources, documenting findings and making sure the conclusion is solid enough to be trusted.
Askeal 2.2 was built for that part of the job.
With this release, we are introducing our new SOC Agent that turns Askeal into an investigation assistant designed to help analysts move from alerts to a structured investigation view.
Askeal does not assume the analyst already knows exactly what to ask. It helps guide the investigation from the first input. When context is missing, it asks the right follow-up questions. When the input is raw, it extracts the indicators that matter. When those indicators need more information, it enriches them with intelligence from Askeal contributors. Ultimately, it organizes sources, timeline, risk signals and recommended actions into a clear investigation path.
The benefit is simple: less time rebuilding context manually, and more time deciding what to do next.
Roxane Suau, CEO & Cofounder
Analysts can bring into Askeal the investigation data they need to make sense of: a SIEM alert export or JSON event (.json, .csv, .xml), a raw log file (.log, .txt), a Windows event log (.evtx), a packet capture (.pcap, .pcapng, .cap), a configuration file (.yaml, .yml, .conf, .ini, .toml), a YARA rule (.yar, .yara), an Nmap output (.nmap), or a script (.ps1, .py, .sh, .js and more).
From there, Askeal reads the input, identifies the type of investigation, and extracts the relevant entities and indicators: IP addresses, domains, URLs, hashes, users, hosts, processes, timestamps, commands, ports, rules, configurations and other useful elements.
At this stage, Askeal helps answer: what are we looking at, and which elements matter?
The same indicator can mean different things depending on the environment. A login pattern may be normal for one user and suspicious for another. An IP address may look risky in isolation but irrelevant in context. A process may be expected on one asset and abnormal on another.
When important context is missing, Askeal guides the analyst with follow-up questions instead of forcing a premature conclusion. It can help clarify the affected asset, user, timeframe, environment, observed behavior or business context.
At this stage, Askeal helps answer: what may have triggered this alert, and could there be a legitimate explanation?
Many alerts only make sense once the sequence of events is clear.
Askeal can reconstruct a timeline from logs, alerts or technical files, making it easier to understand what happened first, what followed, and whether the activity looks benign, suspicious or part of a wider attack path.
At this stage, Askeal helps answer: what happened, and in what order?
An IOC alone is rarely enough to decide. Several weak signals may become meaningful when they are connected.
Askeal enriches the investigation using private sources, crowdsourced intelligence and OSINT from Askeal’s contributor network. It then helps correlate extracted indicators, timeline elements, source intelligence and observed behavior to surface relevant links between assets, users, IOCs and events.
At this stage, Askeal helps answer: what do reliable sources say, and do these signals point to the same story?
A large part of SOC work is deciding whether an alert is worth escalating or can be safely closed.
Askeal supports true positive / false positive qualification by summarizing the evidence, highlighting uncertainty, explaining what supports or weakens the suspicion, and suggesting what still needs to be checked.
From there, Askeal can recommend practical next actions depending on the case: verify a user or asset, check additional logs, block an indicator, isolate a machine, reset credentials, escalate to L2, notify a customer, or close the alert with supporting evidence.
It can also help prepare the output that follows the investigation: an operational summary, handoff notes, escalation context, closure justification, playbook or rule-engineering redaction and export.
At this stage, Askeal helps answer: is this a true positive, a false positive or still inconclusive, and what should you do next?
Askeal 2.2 changes the way answers are delivered.
Instead of producing a typical LLM response, Askeal defines what an assistant built for cybersecurity should deliver: clear structure, trusted reasoning and validated sources. Depending on the question, the response can include:
The purpose is simple: make the output easier to read, challenge, share and act on.
Askeal SOC agent is available on askeal.ai
If you are part of a SOC team or work for an MSSP, we’d love for you to try the new capabilities and tell us what you think directly in the product. Your feedback is where this release started, and it is what will keep shaping what comes next.