AI SOC agents are only as good as the context they can see

An alert fires because a workstation has contacted an IP address associated with malicious activity. The detection gives the security operations center a useful starting point: an affected host, a network connection and a reason to pay attention.

Now imagine asking an AI agent to investigate that alert while giving it nothing else.

The agent can describe what the rule detected and explain why the IP address looks suspicious. What it cannot do is determine whether the connection is part of a genuine compromise, an isolated event or legitimate activity that happens to resemble one.

To make that judgment, it needs to look beyond the alert. It needs to understand what happened before and after the connection, which process initiated it, who was using the device and whether similar activity appeared elsewhere. It also needs to know what the outside world says about the infrastructure involved.

An analyst would expect access to that evidence before reaching a conclusion. An AI agent should be held to the same standard.

The quality of an agent’s investigation depends on the context it can reach. In a SOC, that context comes from internal telemetry, assets, identities, detection knowledge and external threat intelligence. Connecting those sources is what allows an agent to move from describing an alert to investigating it.

An alert is a starting point

A security alert is already a form of interpretation. A detection rule has examined one or more events and decided that a pattern deserves attention.

That is valuable, but it is not the same as understanding what happened.

A suspicious PowerShell command may be the beginning of an intrusion, part of an administrator’s routine work or the result of an automated deployment. A sign-in from an unusual country could indicate account compromise, but it could also be explained by travel or a corporate VPN. A connection to a suspicious domain may be malicious, or it may come from a security tool testing access to known threats.

The alert identifies the question. The surrounding context helps answer it.

If an agent can only see the information contained in the alert, its investigation will remain close to the detection that generated it. It can rephrase the signal and apply general security knowledge, but it cannot test possible explanations against the organization’s actual environment.

That is the difference between commenting on an alert and investigating one.

Context is more than a larger prompt

When people discuss context for AI agents, the conversation often turns to how much information can fit inside a model’s context window. In security operations, that is only part of the problem.

A useful investigation does not begin by placing every available event into a prompt. Most of those events will have nothing to do with the alert, and including them without structure can make the relevant evidence harder to identify.

What matters is whether the agent can reach the right evidence as the investigation develops.

It may begin with a suspicious process, then look at the parent process and command line. That could lead to the user who launched it, other activity associated with the same account and connections made by the device. An IP address found in those connections may then lead to threat intelligence about known infrastructure, related malware or a wider campaign.

Each finding creates another question. The investigation grows by following the evidence rather than examining a fixed bundle of information provided at the beginning.

The goal is not to show the agent everything at once. It is to ensure that relevant evidence is within reach when the investigation requires it.

Internal telemetry tells the story

The first layer of context comes from the organization’s own telemetry.

Logs from identity providers, endpoints, cloud services, firewalls, applications and security tools describe activity across the environment. Seen individually, each event may say very little. Seen together, they can reveal the sequence behind an alert.

Suppose a detection identifies a suspicious process on a workstation. Endpoint telemetry may show how the process started and which command-line arguments it used. Authentication events can identify the user active at the time. Network logs may reveal connections to external infrastructure. Other events might show that a file was downloaded shortly before execution or that persistence was established afterwards.

Asset and identity information then helps explain the significance of those events.

A failed sign-in against a test account does not carry the same weight as a successful sign-in to a privileged administrator account. The same process can be routine on a developer workstation and unexpected on a domain controller. A connection from an internet-facing server may have a different explanation from the same connection originating on a finance employee’s laptop.

Information about a device’s role, exposure and criticality can change the priority of a finding. Understanding who owns an account, which privileges it has and how it normally behaves can change the direction of the investigation.

Without this context, the agent has to reason from generic assumptions. It may recognize activity outside normal business hours without knowing that a service account runs a scheduled task every night. It may identify behavior commonly associated with lateral movement without knowing that the account involved routinely administers several systems.

The telemetry has not changed. The context around it has changed what it means.

Threat intelligence provides the outside view

Internal telemetry shows what is happening inside the organization. External threat intelligence helps explain how that activity relates to the wider threat landscape.

An IP address observed in a network event may be associated with known command-and-control infrastructure, linked to a malware family or connected to a campaign targeting the organization’s industry. A domain may share infrastructure with other malicious domains or form part of a pattern already studied by threat researchers.

This knowledge can strengthen an investigation, but it can also prevent the agent from drawing a conclusion too quickly. Indicators can become outdated. Infrastructure may be reassigned or used for both legitimate and malicious purposes. The value of threat intelligence lies in the context surrounding an indicator, not simply in labelling it as good or bad.

Research and intelligence produced by Sekoia’s Threat Detection and Research team can be considered alongside the organization’s own security data. This allows agents in the Sekoia autonomous SOC platform to ask not only what happened on a particular system, but whether the observables involved connect to known threats elsewhere.

A local event can then be understood as part of a broader adversary behavior rather than treated as an isolated technical signal.

Following the evidence

Security investigations rarely proceed in a straight line. Analysts follow leads, rule out explanations and change direction as new information appears. AI agents need to be able to do the same.

An alert may begin with a suspicious IP address, but the most useful finding could come from a process tree on the endpoint. That process may lead to a downloaded file, which leads to another host, which reveals that the same account was used elsewhere. Threat intelligence may then connect the activity to infrastructure associated with a known threat.

These investigative paths are often how a collection of weak signals becomes a coherent incident.

An effective agent should be able to decide which paths are worth following and use the available data to answer the questions that emerge. It should also be able to stop when a path produces no useful evidence rather than forcing every investigation through the same sequence.

[This is where context and runbooks complement one another](LINK TO RUNBOOK POST). A runbook gives the agent a structured method for investigating a particular detection. Access to telemetry, assets and intelligence gives it the evidence required to work through that method.

The runbook shapes the investigation. Context allows the agent to carry it out.

Context makes verdicts explainable

A verdict is useful only when an analyst can understand how it was reached.

If an agent classifies an alert as a true positive, the analyst should be able to see which evidence supported that decision. If it considers the activity benign, the legitimate explanation should be clear. The investigation should show which questions were explored, what the agent found and where that information came from.

Agents in the Sekoia autonomous SOC platform gather findings as verifiable observations. Analysts can review the queries and actions behind those findings rather than being presented with an unexplained answer.

The context available to the agent determines the quality of that explanation. A verdict based only on the original alert has little to show beyond the detection itself. A verdict supported by authentication history, endpoint activity, asset information and threat intelligence can provide a much clearer account of what happened.

This is particularly important when no single event settles the investigation. More often, the conclusion comes from several observations that become meaningful when considered together.

Context allows the agent to make those connections. Traceability allows the analyst to verify them.

Bringing the evidence together

Many security teams already collect the telemetry and subscribe to the intelligence needed for effective investigations. The difficulty is that the information often remains divided between products, interfaces and data models.

Analysts compensate by moving between tools and assembling the story themselves. An agent operating in the same fragmented environment will face many of the same limitations unless it can access and correlate those sources.

The Sekoia Autonomous SOC Platform brings detection, telemetry, asset information and threat intelligence together so that its agents can investigate alerts across those different sources. Internal activity can be compared with external intelligence. Events can be interpreted in relation to the assets and identities involved. Detection logic can be combined with evidence gathered after the alert.

The benefit is not simply a faster investigation. It is a broader and more coherent view of the incident.

The standard for security agents

The conversation about AI in the SOC often focuses on the model: how well it reasons, which tasks it can automate and how independently it can operate.

Those questions matter, but they do not determine the quality of an investigation on their own.

Even a capable agent will struggle if it can see only a narrow part of the environment. It cannot recover telemetry that was never collected, understand an asset it knows nothing about or connect an observable to intelligence it cannot access.

The platform surrounding the agent is part of its capability.

A security agent should be judged not only by the model behind it, but by the evidence it can reach, the relationships it can uncover and the reasoning it can show to the analyst.

An alert gives the agent somewhere to begin. Telemetry shows what happened. Asset and identity information explain who and what were involved. Threat intelligence connects the activity to the world outside the organization.

Together, they provide the context required to investigate.

AI SOC agents are only as good as the context they can see.