iSteps™: Lifting the Veil on AI-powered Investigations
In Part 1 of this series, we covered the investigation gaps in the SOC: SOAR playbooks are too rigid and unconstrained LLM agents too unreliable, and why the industry needs a new path.
In Part 2, we go in-depth on iSteps, Embed’s fundamentally different approach to security investigation: designed from the ground up to produce conclusions analysts can actually trust. Read on to see how.
What is an iStep?
An iStep represents a single investigative question: the kind a skilled analyst naturally asks when triaging an alert:
- “Has this user behaved like this in the past?”
- “Is this endpoint process suspicious?”
- “Are there signs of impersonation in this email?”
- “Does this device’s activity indicate anomalous behavior?”
Each iStep is scoped to answer one broad, analyst-relevant question. Not a micro-task (like “parse this JSON field”), and not the entire investigation. A typical Embed investigation involves multiple iSteps, selected and sequenced by the broader system based on what the alert requires. This scoping is a deliberate design choice. It directly addresses the reliability problem with unconstrained agents. When an AI system plans an investigation in terms of iSteps, it’s sequencing 5-15 meaningful investigative questions—not 50–100 low-level API calls. Each iStep handles the complexity of evidence gathering, sub-questions, and reasoning internally. From a planning perspective, you don’t need to think about which API endpoint to call or how to parse a JSON response; it thinks about what investigative questions need answering and in what order.
Let’s make this concrete. Say Embed receives an Okta alert: “User account locked out after multiple failed MFA attempts from a new device.” One of the iSteps the system would run for this alert is:
Was this activity performed by the legitimate user?
This is exactly the question a human analyst would ask. Let’s walk through how the iStep answers it.
How an iStep Works Under the Hood
Every iStep follows a three-phase process:
1. Evidence Gathering
The iStep collects the data it needs to answer its question. For our Okta lockout example, this means pulling:
- The Okta system log events for the user over the relevant time window
- Device and session context (IP address, geolocation, user agent, device fingerprint)
- The user’s historical login patterns from Okta
- Previous similar alerts for this user
Here’s a simplified version of what the Okta event log data looks like for this case (trimmed for readability… real Okta system log events contain significantly more fields):
Event: user.authentication.auth_via_mfa
Timestamp: 2025-06-28T14:32:07Z
User: jsmith@acme.com
Result: FAILURE
Reason: INVALID_CREDENTIALS
Client IP: 198.51.100.47
Geolocation: Kyiv, Ukraine
User Agent: Mozilla/5.0 (Windows NT 10.0) Chrome/126.0
Device: Unknown (not registered)
Event: user.authentication.auth_via_mfa
Timestamp: 2025-06-28T14:32:41Z
User: jsmith@acme.com
Result: FAILURE
Reason: INVALID_CREDENTIALS
Client IP: 198.51.100.47
Event: user.authentication.auth_via_mfa
Timestamp: 2025-06-28T14:33:15Z
User: jsmith@acme.com
Result: FAILURE
Reason: INVALID_CREDENTIALS
Client IP: 198.51.100.47
Event: user.account.lock
Timestamp: 2025-06-28T14:33:22Z
User: jsmith@acme.com
Reason: MAX_FAILED_ATTEMPTS
The iStep also retrieves the user’s historical login data, which shows that jsmith@acme.com has exclusively authenticated from IP ranges geolocated to Chicago, IL over the past 90 days, always from a registered MacOS device.
2. Sub-Questions and Answers
To answer the overarching question (“Was this activity performed by the legitimate user?”), the iStep breaks it into focused sub-questions and answers each one using the gathered evidence:
Q: Is the source device consistent with the user’s known devices? A: No. The authentication attempts originated from an unregistered Windows device. The user’s historical logins over the past 90 days are exclusively from a registered MacOS device (device ID: mac-8f3a2b). (Evidence: Okta device context, historical login records)
Q: Is the source location consistent with the user’s normal login pattern? A: No. All failed attempts originated from 198.51.100.47, geolocated to Kyiv, Ukraine. The user’s login history over the past 90 days shows authentication exclusively from IP ranges geolocated to Chicago, IL. (Evidence: Okta system log geolocation fields, 90-day login history)
Q: Does the timing and pattern of attempts suggest automated or manual behavior? A: The pattern suggests automated behavior. Three MFA failures occurred within 68 seconds at near-regular intervals (~34 seconds apart), consistent with scripted password guessing rather than a human manually entering incorrect codes. (Evidence: Okta system log timestamps)
Q: Has the user reported travel or a device change? A: No relevant tickets or communications were found for this user in the past 7 days. (Evidence: IT ticketing system query, communication logs)
3. Reasoning and Conclusion
The iStep synthesizes the sub-question answers into a conclusion for its overarching question:
Conclusion: This activity was very likely NOT performed by the legitimate user.
The authentication attempts came from an unregistered Windows device in Kyiv, Ukraine, while the user’s established pattern over 90 days is exclusively MacOS from Chicago, IL. The timing of the failed attempts (68 seconds, near-regular intervals) suggests automated rather than human activity. No travel or device change was reported. The combination of unfamiliar device, anomalous geolocation, automated timing pattern, and absence of reported changes strongly indicates this was not the legitimate user.
The Chain of Evidence
You’ve just seen what an iStep produces. Now let’s talk about why it’s structured this way.
The iStep didn’t produce a paragraph of plausible-sounding analysis. It produced a structured chain of evidence: conclusion → sub-question answers → specific evidence from specific sources.
Every claim links to a Q&A. Every answer links to the evidence that supports it. You can trace the conclusion (“this was not the legitimate user”) back through each sub-question to the exact Okta log entries, the historical login records, and the ticketing system query that produced no results.
This is a key design property of iSteps. Here’s why this matters.
Why Analysts Should Care
When an analyst reviews this iStep, they don’t have to re-investigate from scratch. They can see the reasoning in seconds. Maybe they agree with the conclusion immediately and move on. Maybe they notice something the iStep didn’t account for: perhaps this user recently mentioned a Ukraine trip in Slack, and the iStep’s communication log query didn’t cover that channel. Either way, the analyst has the full context to make that judgment quickly.
Compare this to an opaque system that says “Verdict: True Positive, Confidence: 84%.” What do you do with that? If you don’t trust it, you’re back to investigating manually. If you sort of trust it, then you’re left wondering whether you should spend the time digging in. Either way, that’s not what we need from AI SOC agents.
Even When the Conclusion Is Wrong
No system, human or AI, gets every investigation right. The question is what happens when it’s wrong.
Imagine the iStep above reached the wrong conclusion. Maybe jsmith actually is traveling in Ukraine and switched to a borrowed Windows laptop. With the chain of evidence exposed, an analyst can see exactly where the reasoning diverged from reality. The sub-question “Has the user reported travel or a device change?” returned no results, but the analyst knows from a Slack message that travel was mentioned. The iStep’s logic was sound given its evidence; it was the evidence that was incomplete. The analyst can identify this in seconds and correct the finding.
A wrong answer with a transparent chain of evidence is vastly more useful than a correct answer you can’t verify. It’s also vastly more useful than a wrong answer from a closed system, where you have no idea what went sideways and have to start the investigation from scratch.
This is what we mean at Embed when we talk about trust through transparency. We don’t just tell you an alert is a true positive. We show you the receipts.
How iSteps Fit Into the Bigger Picture
iSteps don’t operate in isolation. They’re part of a multi-agent architecture that follows an orchestrator-worker pattern. That’s similar to what teams like DeepMind and Anthropic have described for their multi-agent research systems, but purpose-built for security investigation.
A lead agent takes in an alert, determines what needs to be investigated, and orchestrates the investigation by selecting and sequencing iSteps. Because this orchestrator is itself an intelligent agent, the system isn’t limited to investigating only patterns we’ve seen before. It can adapt its plan based on what it finds along the way.
Each iStep agent then executes independently: gathering evidence, performing its sub-question Q&A, and producing a reasoned conclusion as described above.
This is why the level of abstraction matters. The orchestrator doesn’t need to think about API calls, data parsing, or low-level logic. It reasons about the state of the investigation and what investigative questions would move it toward a conclusion.
Embed maintains a curated library of iSteps, each designed for a specific class of investigative question. This library is what gives the system broad coverage across alert types (identity, endpoint, SIEM, cloud, email, network and more), as well as across data sources and attack techniques.
Embed’s iStep-powered investigations are running in SOCs today. If you want to see what trustworthy autonomous investigation looks like in practice: Request a demo.
