AI Assistant
A Colleague, Not a Query Box
Most AI for security is query acceleration. You type a filter in English, get a table back, and do the synthesis yourself. BlendScope's AI assistant was built for a different job: investigation reasoning. It knows what incident you're working, not just what logs you have.
The experience goal: the AI should feel like a knowledgeable colleague who has been watching the same dashboards all day, not a database that speaks English.
The Problem
Existing AI tools are query accelerators. They stop at the result set.
Elastic's AI assistant lets you type "show me failed logins from the last hour" and returns a table. Splunk's AI does the same. Microsoft Copilot for Security knows Azure AD and Defender deeply, but its context ends at Microsoft's own data boundaries. These are useful: they lower the bar to writing a filter expression. But they all stop at the same place.
- They do not reason about the investigation you are currently running. A real SOC analyst mid-incident is not asking general questions: they are working a specific thread. They know IRIS-2847 is active, a Cobalt Strike beacon hit fin-ws-047, and lateral movement to three hosts has been confirmed. They want the AI to walk in with that same situational awareness.
- Existing tools have no concept of investigation state. They can answer questions about their own logs in isolation. They cannot cross-reference an open IRIS case against a Velociraptor hunt result and connect it to a risky Entra user.
- The result: the analyst briefs the AI on what they're investigating, gets a result, briefs the AI again in the next message, gets another result. The AI is stateless. The analyst carries all the context, in addition to carrying the investigation itself.
The Solution
Live context injection. The AI knows what you're working before you ask.
The system prompt is not a static persona description. It is a live snapshot built at request time from the current investigation state: active incidents with affected hosts and MITRE tactics, open case task completion rates, current IOCs marked malicious, risky users with risk levels, Velociraptor hunt state, Sigma hits by severity, Wazuh critical alerts.
- Every message the analyst sends is answered against this live state, not against a general log database and not against training data alone. The AI already knows IRIS-2847 is open and maps to the CobaltStrike campaign hitting three hosts.
- A hypothesis like "Phishing → PowerShell loader → Cobalt Strike beacon (Confidence: 81%)" requires reasoning across incident timelines, host activity, and MITRE tactic chains. None of that is possible if the AI only sees a table of log results from one tool.
- The analyst does not brief the AI. The AI is already briefed. The first message can be a question about the incident, not an explanation of the incident, because the context is injected before the conversation begins.
Core UX Hypothesis
A colleague thinks aloud. A colleague cites sources. A colleague points you somewhere. The AI assistant should do all three: investigation reasoning, not query acceleration.
SSE Streaming: Thought, Not Retrieval
A response that appears word by word signals processing, not retrieval. Instant full-text responses feel like lookups: the AI checked a database and returned a result. Streamed text feels like thought: the AI is working through the problem. In a conversational assistant context, the distinction matters for analyst trust: they experience the AI as reasoning rather than recalling, which is the correct mental model for how the system actually works.
The streaming cursor is a blinking block at the end of the text, deliberately mimicking a text cursor rather than a spinner. This keeps the visual language in the domain of writing and conversation, not computation. The analyst is reading a colleague composing a thought. They are not watching a progress bar. The difference in psychological register is real: a progress bar signals waiting, a blinking cursor signals reading.
The thinking indicator (three bouncing dots plus pulsing source chips) is deliberately non-urgent. No spinner, no progress percentage, no flashing. The motion is slow enough to sit at the edge of attention rather than demand it. A security dashboard that creates anxiety during AI thinking time is a poor colleague. The indicator signals "working" without signaling "urgent."
Implementation Notes
Responses stream over SSE. The cursor is a 2x13px blinking block appended to the response text. The thinking indicator is built from an AnalyzingRow component whose bouncing dots and the sourceChipPulse keyframe animation both run on a 1.6 second ease-in-out loop, tuned specifically to read as ambient rather than urgent.
Source Chips: Two States, Two Meanings
Source chips serve a communication purpose that changes across two distinct states, and that state transition is as important as either state individually.
During the "Analyzing..." phase, the chips are animated and pulsing. Their message is: "these are the tools I'm drawing from right now, before the answer arrives." This is a preview of the reasoning process: it tells the analyst where the AI is looking before they see what it found. This matters because it sets expectations: if the analyst sees the Velociraptor chip pulsing but knows Velociraptor isn't configured in their environment, they can already anticipate a potential misalignment before reading the response.
When the response finalizes, the chips settle static and become clickable. Their message shifts: "these are the sources that support what I just said." The analyst can click any chip to navigate directly to that tool section and verify the claim independently. The answer and its provenance are co-located, so the analyst does not need to open a separate attribution view or ask "where did you get that?"
This is analyst trust design at the component level. If the AI claims a Wazuh rule fired on fin-ws-047 but the Wazuh chip links to a section showing that machine has no Wazuh coverage, the chip is a falsifiability mechanism. The design makes the AI's reasoning not just transparent but checkable in one click.
Implementation Notes
Chips are a single component that swaps between two visual states via a class toggle: a pulsing "analyzing" state driven by the same tool list the AI is querying, and a static "cited" state once the response finalizes. In the static state each chip is a link that scrolls or routes to the relevant dashboard section, so verifying a claim is a single click rather than a separate lookup.
Nav Tags: The AI as Navigation Layer
The first version of the AI assistant returned text answers. That was useful: analysts could ask about an incident and get a hypothesis. But it had a structural problem that became apparent quickly: an AI that says "you should check the Timeline for lateral movement events" without taking the analyst there is only halfway useful. The analyst still has to switch sections manually, potentially losing their current investigation context mid-thought.
The fix makes the AI a first-class actor in the application's navigation layer: it can embed a direct link to the relevant section at the end of its own answer, whenever navigation would actually help. The placement at the end matters: the analyst reads the reasoning first, then sees the navigation action. The AI completes its reasoning with a direction, not just a recommendation.
The button label is the AI's own choice of words, not a hardcoded system label. This means it can be contextually descriptive: "Check Timeline for CORP-WIN-003 lateral movement" instead of just "Timeline." The AI writes the button for the specific situation, which makes the button read as a conclusion rather than a generic link.
The behavior is deliberately forgiving of mistakes: if the AI ever points to a section that doesn't exist, the navigation option just quietly doesn't appear, rather than breaking the response. The analyst still gets a complete, readable answer. A hallucinated navigation suggestion costs nothing, rather than producing a visible error that undermines trust in the entire response.
Implementation Notes
Navigation is implemented as an inline {{nav:section:Label}} tag pattern. The system prompt's behavioral rules instruct the LLM to append these tags at the end of a response when navigation would serve the analyst, with the label text generated by the model itself rather than pulled from a fixed string table. Parsing is deliberately resilient: unknown section keys are silently dropped without breaking the response, so a hallucinated section name simply fails to render a button instead of throwing a visible error.
temperature: 0.25 + max_tokens: 512: Trust as a Technical Decision
Model settings are conventionally treated as quality tuning parameters. In BlendScope's AI assistant, they are trust architecture decisions: each one chosen based on what happens when it goes wrong in a SOC context.
The model was tuned toward literalness because hallucination in a security environment is categorically worse than in almost any other context. An AI that invents a host name, fabricates an IOC, or confidently describes a lateral movement path that didn't happen will erode analyst trust faster than any UI bug, and trust, once broken in a high-stakes tool, is very slow to rebuild. Keeping the model factually tight means it reasons about what is in its given context, reports it accurately, and does not elaborate creatively beyond the evidence. The tradeoff, slightly more formulaic language, is entirely acceptable. SOC analysts want accurate, not eloquent.
Response length is deliberately capped, targeting roughly 150 to 300 words. This is not an arbitrary limit. It reflects how analysts consume information during an active incident: they need the hypothesis and the top two or three supporting data points. A long essay about every related IOC is slower to read than a targeted summary, and during active triage, slower is worse than incomplete. Concision is treated as a first-class behavioral goal, not just a constraint imposed after the fact.
Implementation Notes
The model is called with temperature: 0.25 to minimize creative elaboration beyond the injected context. Response length is bounded by the system prompt's instruction to target 150 to 300 words, backed by a max_tokens: 512 hard cap at the API level as a reliability backstop.
The Warm Redesign: Visual Continuity as Cognitive Load Decision
The original AI assistant panel used a dark, glassy aesthetic with white text: visually distinctive and immediately recognizable as "the AI part." It looked different from the rest of the dashboard. That was the problem.
An analyst who has been working in the warm cream dashboard environment for 45 minutes, building a mental model of an investigation across the Overview, Live Map, and Timeline, experiences a real cognitive context switch when they open a panel that looks like a different product. The aesthetic discontinuity signals "you are now in a different place," which is precisely the wrong signal for a tool that is supposed to feel like a colleague sitting next to you at the same dashboard.
The redesign brings the AI panel into the same warm visual environment as every other section, matching the palette and typography used across the rest of the dashboard. The AI looks like a panel you consult while staying in the dashboard, not an external tool you navigate away to. Visual continuity is not an aesthetic preference. It is a cognitive load decision. The analyst's working context should not change when they ask the AI a question.
Implementation Notes
The original panel used dark rgba backgrounds and the Space Grotesk font: a glassmorphism treatment distinct from the rest of the app. The redesign replaced it with warm palette card backgrounds, palette.accentBlue accents, and the DM Sans/DM Mono font pairing already used elsewhere in the dashboard.
Mock Fallback: A UX Feature, Not a Technical Compromise
The mock fallback was a deliberate design choice, not a development convenience or a placeholder waiting to be replaced. The decision stems from a simple product question: what should happen when the API is unavailable?
The wrong answer is "display an error message." An AI assistant that returns "I'm unavailable" during a demo, an API outage, or an unconfigured API key is functionally broken: the feature simply doesn't exist at that moment, and that absence is visible and disruptive. In a portfolio context, a broken feature during a demo is worse than no feature at all. In a production context, an AI assistant that goes silent during a high-activity period, exactly when it's most needed, is a liability.
The fallback engine returns contextually relevant responses matched to the analyst's question, so the experience holds together even without a live model behind it. The only tell is the absence of the small label that marks a response as coming from real AI inference. That distinction is kept honest on purpose: the system never pretends the fallback is real AI, it simply doesn't announce the failure mode in a way that interrupts the analyst's workflow.
The mock is not a fallback that apologizes for failing. It is a fallback that maintains the product experience. An analyst with a properly configured API key will see the label on every real response. If they ever see a response without it, they know they're reading the local fallback. Transparency without interruption: the difference between an informative status indicator and a workflow-breaking error state.
Implementation Notes
The fallback is a keyword-matching mock engine that returns contextually relevant canned responses based on query pattern matching. Real inference responses carry a via Groq · label driven by a fromAI flag; the mock simply omits it rather than displaying an error state.
No Action Execution: Observation Without Risk
The AI explicitly does not execute actions. When it suggests "isolate this host," it embeds a nav tag to the relevant authorization page, and the analyst makes the call. This is architecturally consistent with the broader BlendScope philosophy: observation is free, execution is deliberate. The Gravity Well is consequence-free by design. The AI assistant extends that principle into the conversational layer.
This is not a limitation: it is the design. An AI that can isolate a host without confirmation is a liability in a SOC environment where a false positive isolation takes a production system offline. An AI that tells the analyst which host warrants isolation and navigates them to the right page is a force multiplier that keeps a human in the authorization loop. The tradeoff is explicit and intentional.
The nav tag buttons communicate this implicitly through visual weight. They are styled as secondary suggestions: understated, without the visual prominence of a primary action button. The analyst sees a recommendation and a way to act on it, not a command and an execute button. The visual grammar of "suggestion" versus "action" maps to the actual authority relationship: the AI recommends, the analyst decides.
This also connects to the approval structure that governs the rest of the dashboard. Actions requiring approval (isolate, block, remediate) require a human in the loop. The AI can reason about which actions are appropriate and provide the evidence for them. It cannot initiate them. The observation/execution boundary is consistent across every surface in BlendScope, including the conversational one.
Implementation Notes
Nav tag buttons that point to authorization-gated actions are styled as secondary suggestions, visually lighter than the dashboard's primary action buttons, so the AI's recommendation never carries the same visual weight as an execute control. Isolate, block, and remediate actions all route through the same approval-tier gating used elsewhere in the app; the AI has no code path that bypasses it.
Design Philosophy
UX Principles Applied
Choosing accuracy over eloquence is a trust decision. Source chips are a trust decision. No action execution is a trust decision. Visual continuity is a trust decision. In a SOC context, every choice that makes the AI's reasoning transparent, bounded, and checkable is a trust investment, and that investment compounds over every shift.
Navigation suggestions carry the "canvas is center of gravity" principle into the conversational layer. AI responses drive the analyst toward the Timeline, the Forensic Canvas, specific tool pages, not to a text answer that leaves them at the same screen, needing to navigate manually.
Source chips placed immediately below AI responses make the reasoning visible at the point of consumption. The analyst does not need to open a separate attribution view. The answer and its provenance are co-located, which is what "cite sources" means in a product, not just in a document.
A short response target and a hard length cap enforce high-signal defaults. Suggestion chips surface the highest-value follow-up queries. Depth is available: the analyst can drill into any point with a follow-up. But the first response is a hypothesis, not an encyclopedia entry.
The thinking indicator is deliberately non-urgent: slow, gentle bouncing dots. No spinner, no progress bar, no flashing. A security dashboard that creates anxiety during AI thinking time is a poor colleague. The indicator signals "working" without signaling "something is happening that demands your attention."
The warm redesign replaced a darker, more distinctive look because aesthetic discontinuity between the AI panel and the rest of the dashboard breaks analyst flow mid-investigation. Visual continuity is not an aesthetic preference: it is a decision about how much cognitive overhead the interface imposes on the analyst when they switch between surfaces.