Investigations Were Just the Beginning
When we started Embed Security, we believed AI could fundamentally change how security investigations were performed.
At that point, we’d spent decades working in security operations, and we saw an opportunity to take the expertise of security practitioners and make it available at a scale; asymmetrically changing what was possible with people alone.
We knew something transformative was on the horizon, but we didn’t start out calling it a decision layer. What we did know was that investigations were the foundation. As we started building, something became increasingly clear: investigations were the process, but decisions were the outcome.
Today, we’re taking a significant step beyond investigations. We’re introducing new capabilities that let security teams teach Embed their own expertise, apply organizational knowledge to security decisions, and use investigation outcomes to improve the detections that generated them.
These capabilities reflect the broader vision we had from the beginning: investigations were where we needed to start, but they were never where we intended to stop.
Why We Started with Investigations
Throughout my career at the NSA, Mandiant, Awake Security, and Meta, I’ve seen firsthand how much expertise goes into making a good security decision.
An alert tells you something might be wrong. Understanding what actually happened, whether it matters, and what to do about it requires evidence, context, experience, and judgment. Two analysts can look at the same alert and reach different conclusions. The same activity can be perfectly normal in one organization and a serious concern in another. The same detection can be extremely dependable in one organization and fill a queue with False Positives in another.
Security teams have spent years collecting more telemetry, building better detections, and automating responses. But the work between detection and response remained heavily dependent on people. Leaving investigation and decisions to human effort.
We asked ourselves,
“What if we could take the investigative expertise of security practitioners, make it available to AI, and apply it consistently across every alert?”
Initially, our focus was on making investigations better, faster, cheaper and more consistent.
But as we built the system, we began to see we were really providing a decision analysts could trust. It was always our intent, but maybe not explicitly front and center.
Investigations became the foundation, but trusted decisions became the objective.
There Were No Shortcuts to Quality
It’s tempting, especially with how quickly AI technology is evolving, to build something, test a few examples, make some adjustments, and hope the next version performs better. But guess, check, and hope isn’t a strategy for building a system that security teams can depend on.
We knew building trust would require three things: accuracy, consistency, and transparency.
Can the system reach the right conclusion? Will it reach that conclusion consistently? And can an analyst understand the evidence and reasoning behind the decision? We invested in the underlying investigative architecture, evaluation infrastructure, monitoring, and human-labeled datasets necessary to understand how the system was performing and where it needed to improve. This is not a system where we built and moved on — it’s a continuous system, always evaluating and improving.
We needed to know (and so do analysts) not just whether an investigation reached the correct conclusion, but why. We needed to understand when changes improved performance, when they introduced regressions, and when the system didn’t have enough evidence to reach a confident decision.
That work isn’t always the most visible or exciting part of building an AI product. But it’s essential.
By investing in the foundation, we’ve been able to build confidence in the system and increase the speed at which we can develop and deliver new capabilities. This distinction becomes increasingly important as Embed expands beyond investigations.
When investigative outcomes begin informing other security decisions, the quality of those original decisions matters even more.
Security Teams Should Teach AI, Not Build It
One of the interesting developments we’ve watched over the past year is the growing expectation that security teams should be building their own AI agents. We understand the appeal. LLMs have made it dramatically easier for people to create software and automate tasks that previously required dedicated engineering resources.But there’s an important distinction between being able to build an agent and wanting to own everything required to operate one reliably. Security teams already have the expertise. They know how to investigate threats, how their organizations operate, and what constitutes suspicious behavior in their environments. We don’t believe they should have to build and maintain an AI investigative platform to put it to work.
Security teams should be teaching AI what they know, not building the infrastructure required to make AI work.
That’s a big part of what we’re announcing this week.
With customer-built iSteps(™), analysts can describe how they would investigate a particular security question, and Embed can turn that knowledge into an investigative (iStep) agent that becomes part of our broader system.
These aren’t isolated scripts or standalone agents that customers have to orchestrate themselves. They build on top of the investigative architecture we’ve spent the last three years building.
Embed can then select and execute that expertise when it’s relevant to an investigation, alongside the investigative capabilities already built into the platform. This allows customers to extend Embed with their own investigative practices without having to recreate everything we’ve already built.
This enables something I think is particularly powerful: Embed’s expertise and our customers’ expertise working together in the same investigative system.
That’s a much more interesting future than asking every security team to build and maintain its own collection of AI agents — or limiting customers to ours.
Every Investigation Should Make the Next One Better
We recently noticed something interesting with one of our customers.
Their analysts were repeatedly reviewing and dispositioning the same type of alert. They knew how they wanted those cases handled, but they were still spending time making the same decision over and over.
We pointed out that they could simply tell Embed whether they agreed or disagreed with its conclusion, and more importantly, why. That feedback becomes part of Embed’s understanding of their environment, allowing the system to apply that knowledge to future investigations without requiring an analyst to repeatedly intervene.
It’s a relatively simple example, but it illustrates something important. The value of an investigation shouldn’t end when the case is closed. Every investigation gives us an opportunity to learn something about the environment, the investigative process, or the detection that generated the alert.
This brings us to another major capability we’re announcing: Detection Engineering. For years, security teams have invested heavily in building detections. But we’ve been much less effective at systematically using the outcomes of investigations to improve those detections.
An analyst triages an alert, quickly reaches a conclusion, and moves on. The detection that generated it continues producing the same results. People just get faster at dispositioning that alert over time.
Security teams are pretty good at generating alerts. Although, usually teams aren’t nearly as good at closing the loop between what we detect and what we learn from investigating it.
What if every investigation helped improve the detection that triggered it?
Because Embed is already investigating these alerts, we have an opportunity to understand how detections are performing in practice. Which detections are consistently producing benign results? Which are generating meaningful findings? Where could changes to detection logic reduce unnecessary work without sacrificing security coverage?
Our new Detection Engineering capabilities are closing that loop.
By connecting investigative outcomes to detection performance, we can help teams identify where to focus their efforts and recommend improvements to customer-authored detections.
The goal isn’t to remove detection engineers from the process. It’s to give them better information and more time to focus on improving coverage, identifying gaps, and building the detections that matter.
Investigations shouldn’t just resolve alerts. They should help improve the security systems that generated them.
Building Toward a Different SOC
Security operations is ultimately a series of decisions:
- What should we investigate?
- Is this activity malicious?
- Does it matter in this environment?
- Should we respond?
- Is this detection effective?
- Where should we focus our efforts next?
Today, many of those decisions are made independently, across different tools, teams, and processes. Embed is the ability to connect them through a trusted decision layer that brings together security expertise, organizational context, and the evidence necessary to make informed decisions.
Customer-built iSteps allow organizations to bring their own expertise into the system.
Detection Engineering takes what we learn from investigations and uses it to improve the systems upstream.
Together they make steps toward our broader vision where security operations is more connected and adaptable. As attackers increasingly use AI to accelerate their operations, defenders need to do more than investigate alerts faster. They need to improve how their entire security operation learns, adapts, and makes decisions.
We knew that investigations were just the beginning. The real opportunity is what we can do with the decisions they produce.
