Designing AI-native security investigations

Security teams have plenty of data. What they lack is a fast, reliable way to connect it, understand what it means, and decide what to do next.

Role
Lead designer & product manager
Team
3 engineers, 1 designer
Timeline
3 months
Inputs
Pendo data, NPS, design partners
Ownership
  • Product direction and experience principles.
  • Platform and AI design.
  • Hands-on development.
  • An AI-assisted design system workflow.

I led the design of the AI investigation and mitigation flow. AI now sits inside the workflow. It takes users from a question to verified evidence and a clear next step, and they stay in control the whole way.

app.us.jupiterone.io/assistantLive prototype
Featured prototype: Ask AI investigating vulnerabilities in context.
The challenge

The data was there. The answers were hard to find.

A question like “Which AI agents can access production data?” requires tracing agents to IAM roles, checking permissions, identifying accessible resources and verifying that the data is current.

In JupiterOne, that meant writing J1QL or moving between Search, Graph Canvas and entity pages. The information existed, but connecting it into a reliable answer took too much effort.

A chatbot alone wouldn’t solve this. Security teams need to know where an answer came from, what it covers and whether the evidence is good enough to act on.

The design principle

Make answers inspectable, not just convincing.

Three principles guided the work:

The foundations

Better investigations start before AI.

Before introducing AI across the product, I redesigned two key entry points.

One view of findings

The new Vulnerabilities page brings findings from four sources into a prioritised list, linking each finding to its remediation plan.

app.us.jupiterone.io/vulnerabilities
JupiterOne Vulnerabilities page: findings from four sources, unified and prioritized, with links to remediation plans
The redesigned Vulnerabilities page: findings from four sources unified, prioritized and linked to remediation plans.

Onboarding that starts with goals

Instead of landing on generic counts, new customers select their goals. AI evaluates those goals against their connected data to create a more relevant starting point.

app.us.jupiterone.io/home
After: a homepage generated from the customer's goals, with a score per goal and the work that needs them
Before: a Search page with the same generic counts for every customer
BeforeAfter
Before and after. Drag to compare.
app.us.jupiterone.io/home
Live prototype: pick goals, see what your connected data supports, and get a starting point built from both.
The AI experience

One workflow, from question to action.

Rather than creating a separate destination for AI, I embedded the assistant into the places where investigations already happen.

Step 1

Ask in context

Ask AI opens from the current page or entity, carrying its context into the interaction. Its steps remain visible, and applied filters update the page itself.

Step 2

Put evidence beside the answer

Answers stay concise, with graph evidence, data conflicts, freshness and query access close at hand. Users can inspect the underlying query in Search and flag an answer as helpful or wrong.

The challenge was balancing transparency with scanability: enough evidence to verify an answer without overwhelming the user.

The Ask JupiterAI answer for a remediation plan: a two-sentence answer, a flagged data mismatch, evidence chips from the graph, an Open in Search button, the graph sync time and Helpful or Wrong feedback
From the remediation-plan prototype: J1 AI opened from the plan’s side panel, with the plan already set as context. Open the live prototype ↗
Step 3

Turn questions into queries

In Graph Canvas, the assistant interprets the traversal being built, highlights relevant relationships and explains the path. Users can add that path to their query without starting over.

app.us.jupiterone.io/query-builder
Graph Canvas with Ask AI open beside the query builder: a User to CodeRepo traversal, the assistant's summary of the path to Findings, and actions to highlight it or add it as a step12345
  1. The query being built, step by step
  2. The traversal the assistant reads
  3. A summary of the path worth checking
  4. One click adds it to the query
  5. Open in Search to check it against the data
Graph Canvas with Ask AI, annotated. Try it in the live prototype below.
app.us.jupiterone.io/query-builder
Live prototype: click any node, or highlight the path to Findings and add it as a step.
Step 4

Move from findings to action

When a control fails, Ask AI explains why, identifies affected assets and drafts a Jira ticket for the responsible owner.

app.us.jupiterone.io/controls
Controls with Ask AI drafting a Jira ticket for the failing control CSF-PR-04: tool steps, the ticket with the affected security groups and the steps in AWS, and Create ticket or Cancel1234
  1. The failing control, in the list where it lives
  2. Visible steps while the assistant works
  3. The ticket, with the affected groups and the steps in AWS
  4. Create or cancel. Nothing is created until the user confirms
Controls with Ask AI, annotated. Try it in the live prototype below.
app.us.jupiterone.io/controls
Live prototype: create or cancel the ticket, or hover another row and click the sparkle icon.

The assistant doesn’t change the cloud environment itself. Users confirm ticket creation, and the control remains failing until a later evaluation confirms the fix.

The decision: make the next step actionable without promising more than the product can deliver.

Trust and consistency

Design for uncertainty. Build for scale.

Not every investigation produces a definitive answer. I designed four answer states rather than treating every response as a success.

  • Confident. The graph supports the answer and the evidence is inspectable.
  • Uncertain. The answer is useful, but its limitations are visible.
  • Wrong, corrected. Users can challenge a response and see the correction.
  • No answer. The data isn’t sufficient to support a conclusion.

For example, when asked which AI agents can reach production S3 buckets, the assistant traces the agents through their shared IAM role to accessible buckets. It also exposes the supporting relationships, integration status and last sync time.

Answer statesJ1 assistant

You askedWhich AI agents have access to production S3 buckets?

Confident

3 AI agents can reach production S3 buckets. All three use the same IAM role, ai-pipeline-prod.

Evidence from the graph

  1. 3 AIAgent
  2. ai-pipeline-prod
  3. 2 S3 buckets

The graph shows three AI agents, one shared IAM role and two S3 buckets.

Last synced 12 minutes ago. Every integration along this path is reporting.

Uncertain

At least 2 AI agents can reach production S3 buckets. There may be more.

ConfidenceMedium

What's missing

  • Account prod-eu-2 has no CloudTrail integration, so I can't see which roles its agents assume.
  • The role behind support-triage hasn't synced in 9 days.

Next step

Connect CloudTrail for prod-eu-2Show the 2 I'm sure of

Wrong, corrected

3 AI agents can reach production S3 buckets.

You flaggedsupport-triage was decommissioned last week.

You're right. I re-checked against the current graph: the role on support-triage was detached 6 days ago. 2 AI agents can reach production S3 buckets.

What changed

  • support-triage · role detached 6 days ago
  • claims-summariser, fraud-scorer · unchanged

Why it was wrong: the first answer read a cached snapshot from before the change.

No answer

I can't answer this from your graph. None of your integrations report AI agents, so there are no AIAgent entities to check, and guessing would be worse than saying so.

Try this query once an AI integration is connected

FIND AIAgent THAT ASSIGNED aws_iam_role
  THAT ALLOWS aws_s3_bucket
  WITH tag.Environment = 'production'

Next step

Add an AI integrationCopy query
Interactive prototype: switch between the four states or compare them side by side.

One interaction model across the product

Ask AI spans entity panels, Graph Canvas, Vulnerabilities, Controls and Home. I established a shared model for context, answers, evidence, uncertainty and next steps, adapting the presentation to each surface while keeping behaviour consistent.

I built the assistant using JupiterOne’s existing design system and packaged it as a Claude skill. This guided AI-assisted prototyping to use real components and named colour tokens instead of inventing new ones.

Claude · Skills
The jupiterone-design-system Claude skill, with rules to use kit components and Eclipse colour tokens for interactive states
The design system packaged as a Claude skill: use existing components, never rebuild them, and use named colour tokens for interactive states. How the design system was rebuilt →
The impact

Faster investigations. Evidence users can verify.

Evaluation sessions tested whether users could find answers faster, verify supporting evidence and understand when a response was reliable enough to act on.

Investigation efficiency
−35%
Time to a verified answer
Compared with the existing Search and Graph workflow.
Answer verification
88%
Evidence verified
Share of tested AI responses where users correctly found and checked the supporting graph evidence.
User confidence
+24 pts
Confidence
Increase in users who understood why an answer was reliable.
Design system adoption
5 surfaces
One interaction model
Entity panels, Graph Canvas, Vulnerabilities, Controls and Home.

These results come from evaluation sessions, not production-wide measurements.

The takeaway

I stopped treating AI as a chat interface to fit into a security platform. I designed an investigation workflow in which AI helps users connect evidence, understand uncertainty and decide what to do next.

Generating an answer is the easy part. The real design work is helping people know when to trust it.

Go to next →