Material's May updates make the detection engine more legible for every analyst, and give technical teams the programmatic access to put that intelligence to work outside the UI.
There's a version of security tooling that works until someone asks why. The detection fired, the email is quarantined, the issue is open, but when the analyst needs to explain the decision to a stakeholder, or an engineer needs to route intelligence into their SOAR, the trail runs cold. "The system flagged it" isn’t analysis: it's a gap.
The most effective security teams close that gap in two directions: down into the detection logic, so analysts can articulate what happened and why; and outward into the rest of the security stack, so Material's signal reaches the systems and workflows where decisions actually get made. This month's updates address both.
We've overhauled the detection explanation experience in the Issue Details page, giving analysts a clearer, more specific picture of what drove a flag. And we're releasing a preview version of API v1, a production-grade, fully documented API that gives technical teams clean programmatic access to Material's detection engine, without needing to touch the UI.
Detection explanations: the full picture, not just the verdict
When an issue lands in the queue, an analyst's first question is always the same: why this message? The analysis has always been there, but it was easier to see that something was flagged than why. The updated Issue Details page closes that gap with three layers of new context.
The About this Issue section now includes an LLM-generated summary that describes the objectives and tactics used in the message — not just the outcome, but the attacker's apparent intent. This is language analysts can actually use: in a post-incident report, in a briefing to leadership, in a conversation with a user who wants to understand why their email was pulled.
The Sender reputation section now surfaces a trusted entity indicator when applicable. If a message arrived from a sender your organization has a legitimate relationship with but showed other signs of compromise or impersonation, that context is now explicit. It changes how you read the detection.
The biggest change is in the Message analysis section. Previously, this section only surfaced matches to the deterministic rules written by our threat research team. It now also shows the specific features that influenced our ML models — King Phisher and California Brown Pelican — to classify the message. You can see what the model saw, not just what it concluded.
On that note: when a model was involved in a detection, we now name it, with a link to documentation where available. Material has been using advanced AI in its detection engine for a long time, but we haven’t always surfaced all of the intelligence from it in a way that’s actionable by analysts: this update fixes that. When the LLM contributes to a flag, you'll see which one and why. If something in the analysis doesn't look right, there's a feedback button in the upper right of the card to flag it directly.
The goal here isn't just better UI — it's accountability. Security programs work better when analysts can defend the decisions their tools make. These updates give them the specific, technical evidence to do that.
API v1: Material, headless
We are releasing a fully documented API, providing clean programmatic access to Material's detection engine.The design principle is straightforward: any time your team needs to analyze, export, or operationalize Material data in an external system, the API makes that easy to set up.
The most common use case is SOAR integration. With the Issues API, your team can list open issues, match them against signals in your existing workflows, and fetch full issue details — including related messages, accounts, and files — to enrich an incident or trigger a response action. You're not working around Material's UI; you're pulling Material's intelligence into the places your team already operates. This is in addition to the “push” model via Events that we’ve had for a long time, so you can get your data into external systems however it best suits you. (And remember our recently-launched MCP server in case you don’t want to deterministically program how this happens at all!)
For high-velocity organizations running a deeply integrated security stack, this furthers Material’s commitment to serving as connective tissue in a system where every tool needs to communicate and every signal needs to flow. These teams want the accuracy, the depth, the coverage across the cloud workspace of Material's detection engine, but they also want to decide where that signal goes and what happens with it. The v1 API is built for exactly that kind of control.
It's also a direct response to what we've heard from existing customers whose needs have outpaced the beta API that’s been in Material for years. Version 1 is a stable, supported foundation — something teams can build on without bracing for breaking changes in the next release. Customers already run Material as part of a larger security system; this release gives that model a proper foundation.
Existing customers using our beta API: don’t worry, we aren’t breaking what you’ve already built. The beta API will remain available for the foreseeable future. Existing customers can read more about the new API on our documentation page.
These two updates point in the same direction: a detection engine you can see into and build on, not a black box you're asked to trust. Analysts get the specific evidence behind a flag. Technical teams get clean programmatic access to act on it. That's what security infrastructure should look like.
Reach out for a demo if you want to walk through the API, or see the updated Issue Details experience live.
