Threat Cards: Showing Why the AI Flagged a Threat, Right Where Analysts Decide

Challenge

Approach

—Decision 1, a product debate: should each card show a severity level? Every analyst expects one from other tools. My early research on the domain and on competitors showed severity everywhere, and I proposed it at the start. Product decided against it: they wanted to show what the AI can do, and in our product, where the focus was the size of the attack infrastructure, we couldn't be sure what makes a threat severe. I accepted that and didn't push. So the card leads with the AI's evidence: what it found, what it's based on, and what to do next.

1

2

3

• 1AI icon: summary and why: One click opens a short summary and the reason the AI marked this threat as urgent.
• 2Prevent, or close without fixing: Prevent gives the action steps. The arrow lets the user close a false positive with a reason, so it moves to the Prevented list.
• 3View Insights: the full investigation: Opens a side panel with why the AI prioritized the threat, what it's based on, and the recommended action.

—Decision 2, where the explanation lives. I considered three options: all the information on the card, a general help page, or the key facts on the card with the rest in a panel. I chose the third. The AI icon on the card opens a short summary and the reason the threat is urgent. Prevent gives the action steps, with screenshots. View Insights opens a side panel for a full investigation: why the AI prioritized it, what that's based on, and the recommended action.

—Why: people hesitate right before they click, so that is where they need the answer. Details that help, but aren't needed at first glance, go in the panel. What I gave up: the explanation opens on click, so it is one extra step.

—Not every alert is a real threat. The arrow next to Prevent opens Close without fixing: the user picks a reason (Accept risk, Duplicate, Out of scope), and the alert leaves the list and moves to the Prevented list as closed without a fix. False positives get handled instead of piling up as noise.

—The bigger goal: the product's long-term aim was for the AI to learn from users what to handle and how, and do it automatically. In this first stage, we kept the user in the loop until they could fully trust the system.

—The card's badges and the AI panel come from the component library first set up in Imminent Threats, reused here instead of built from scratch.

Impact

Validation

Two separate sessions, the same trust gap, unprompted

Malanta's analyst base was small, 5-10 active users at any time, too small for a statistical test. I worked with 3 real users in conversations and usability tests. The trust finding is worth citing not for its sample size, but because two of them raised it on their own, in separate sessions, while doing unrelated tasks on the card.

What I'd do differently

Retrospective

• —Severity first, then the AI's evidence. I spoke with 3 users, in conversations and usability tests, and read notes from 5+ potential customers from screening surveys and product market fit work. They look at severity first, and only then read why. We wanted to show what the AI can do, and on the way we lost sight of where the user starts. In the next version I'd put a simple severity signal at the top of the card, with the AI's explanation right below it: severity, short summary, proof, actions. This is a design of what I'd do differently. It was not built.
• —Severity doesn't have to follow the market's definition. It can be our own, based on the signals our product finds. I checked this with our cyber researchers and our data analyst. Looking back, I'd have pushed harder for it at the start.
• —Track both paths from day one: how often the panel opens, and how often people click Prevent without it. We didn't measure at the click level, so I can't show which path each analyst takes or how fast they decide.

1

• 1Severity, defined by our own signals: A signal analysts already know, based on what our product finds, with the AI's explanation right below it.