Your AI SOC Agent Is Investigating in an Unbounded Playground

Everyone is building AI SOC workflows these days.

Whether it’s part of an existing SOC platform, a custom automation, or even a standalone AI agent, the common workflow is pretty similar:

1. Ingest an active alert into an AI agent.
2. Investigate the alert: Querying relevant data sources using the available tools.
3. Reach a verdict based on the evidence collected during the investigation.
4. Send the result to an organizational messaging channel.

This is great, and most of the time, it works.

But what happens when you try to go deeper and actually assess how good this workflow is? Did you ever take the time to think about what happens between the alert and the final verdict?

Evaluating Your AI SOC Agent

When evaluating your agents, there are a few questions worth asking:

• Reasoning efficiency:
  • How much of the agent’s work and reasoning was actually needed?
  • How many tool calls and tokens were spent on things that weren’t relevant to the investigation?
• Investigation time:
  • How long did the AI agent take to investigate the alert?
  • How many iterations did it take to reach the final answer?
• Completeness of the investigation:
  • How does the agent know when it has finished investigating?
  • How can it say with high confidence, “I checked all the relevant possibilities in my environment, and this is my final verdict”?
• Reliability and consistency:
  • Will the same alert produce the same investigation path and, eventually, the same verdict?

The agent is discovering where to investigate while it’s already investigating.

The Problem: An Unbounded Investigation Space

Let’s try to understand the problem through a simple use case.

Imagine a typical company environment with multiple cloud providers, an identity provider, several SaaS applications, source control, endpoints, and internal infrastructure.

Now, an alert appears in the SIEM:

{
  "alert": "Suspicious activity detected",
  "entity_type": "identity",
  "entity": "ben@company.com",
  "source": "Identity Provider"
}

Let’s also assume that the AI agent has access to all of these platforms and can query them using its available tools. It even has great custom context about the organization: its projects, cloud accounts, applications, and infrastructure.

The investigation starts.

While querying the SIEM and collecting evidence, the agent also needs to continuously decide what to investigate next as part of its reasoning.

Should it check AWS? What about GCP? Should it query GitHub? Salesforce? The endpoint associated with the identity?

And if it finds that the identity has access to AWS, the decision tree doesn’t stop there. The identity might have access to multiple AWS accounts, with different roles in each account. Those roles might provide access to different resources, and some of those resources might expose additional credentials or paths to other parts of the environment.

At every step, another question appears: where should the investigation go next?

Eventually, the agent also needs to decide when to stop.

You can think of this as the agent operating in an unbounded playground. The spectrum of possibilities available to the agent is much larger than the set of possibilities that are actually relevant to this specific compromised identity.

As mentioned earlier, this has a direct impact on reasoning efficiency. The agent may waste tool calls, tokens, and investigation time querying systems that aren’t relevant at all.

But there is another side to the problem: while exploring all of these possibilities, how do we know that the agent didn’t miss one of the paths that actually matters?

Blast Radius: Defining The Playground

Microsoft describes blast radius as providing a visualization of:

“how the compromise of one asset could affect others.”

In simple terms, think of an entity’s blast radius as the set of systems, identities, applications, and resources that could potentially be reached or affected once that entity is compromised.

The diagram above represents a simplified organization topology. The highlighted nodes and edges in the view with blast radius context represent Ben’s potential blast radius, while the remaining nodes represent systems that aren’t reachable from this identity through the known relationships. In the view without blast-radius context, every system is an investigation candidate; red visits mark detours outside Ben’s known access.

The organization may be huge. The relevant investigation space doesn’t have to be.

Map Before You Investigate

What if we could give the agent a map that tells it where it should investigate, instead of letting it discover that map along the way?

Think of a knowledge graph, or more specifically a security graph, that already contains the relationships between the entities in the organization.

Once an alert arrives, the agent doesn’t have to start from an entirely open investigation space. Along with the alert, it can receive a map of the affected entity’s known relationships to help decide where to look first.

So what actually changed?

Instead of simply telling the agent:

“Here is an alert. Investigate it.”

We can tell it:

“Here is an alert. Investigate it. FYI here is a map to guide your investigation”

The alert is the same. The agent can use the same tools and the same reasoning capabilities. But now it also has a map that shrinks the spectrum of possibilities it needs to consider.

Going back to the questions we asked at the beginning, reducing this investigation space can potentially improve several parts of the investigation:

• Reasoning efficiency: Fewer irrelevant possibilities mean fewer unnecessary decisions and tool calls.
• Investigation time: Knowing where to investigate can reduce the reconnaissance the agent needs to perform before and during the investigation.
• Cost: Fewer unnecessary reasoning steps and tool calls can also mean fewer tokens and less compute.
• Completeness: If the expected blast radius is known, it becomes easier to reason about whether all of the relevant paths were actually investigated. In graph terms, we can potentially traverse the reachable paths and use that coverage as another signal for whether the investigation is complete.
• Consistency: A more clearly defined investigation space can reduce the number of arbitrary paths the agent can take, potentially making investigations more consistent.

Blast Radius Is a Guide, Not a Wall

There is one important caveat.

The blast radius should guide the investigation, not limit it.

Not every relevant security check is represented by the topology of the organization. The graph itself can also be incomplete or outdated, and evidence discovered during an investigation may reveal a path that wasn’t known in advance.

The agent should still be able to reason beyond the known blast radius when the evidence requires it.

The goal isn’t to replace the agent’s reasoning with a predefined path. It’s to give that reasoning a better starting point.

Conclusion

AI security agents operate in a partially unknown environment every time a new investigation begins. They need to understand what happened, but at the same time, they also need to figure out where to look.

By using the known blast radius, we can potentially provide the agent with a smaller and more relevant map of the environment before the investigation even begins.

The agent still reasons. It still follows the evidence. It can still go beyond the map when needed.

But instead of starting every investigation by discovering the world around it, we can give it a map first.