Jarvis: a personal security advisor for every role on the SOC floor
Why one chatbot doesn't fit a SOC analyst, threat hunter, security engineer, architect, and CISO. Five personas, one product — and the prompts and memory model behind each.
"We need an AI assistant for the SOC." Five people in the room. Five completely different mental images of what that means. The analyst wants alert triage. The hunter wants IOC pivots. The engineer wants Sigma rules. The architect wants threat models. The CISO wants a board narrative.
The first version of Jarvis tried to be one thing for all of them. It was mediocre at everything. The version we ship today is five personas with shared infrastructure. This post documents why we split, and how.
The five personas
Each persona has its own prompt, its own tool allowlist, its own memory shape, and its own UI surface. The model underneath is the same.
SOC Analyst
Triage. The analyst is in a Tier 1 queue, has 90 seconds per alert, and needs three things: a one-paragraph summary of what fired, the recommended next action from the runbook, and a clear escalate-or-close call. Jarvis-SOC is tuned to land those three things in the first response. It refuses to philosophise.
Threat Hunter
Pivots. The hunter is exploring. They have an IOC, a hypothesis, and a question: where else does this lead? Jarvis-Hunter is tuned to expand — given an IP, surface related domains, related campaigns, mapped TTPs, ATT&CK techniques, threat-actor associations. It's verbose by design.
Security Engineer
Rules. The engineer wants Sigma. They want SIEM query optimisation. They want detection coverage gaps. Jarvis-SecEng outputs runnable artefacts — rules, queries, integration snippets — with provenance for where each lookup came from. It refuses to output rules without test cases.
Security Architect
Models. The architect is sketching a system and asking, "how does this break?" Jarvis-Architect runs STRIDE on the described system, maps the threats to NIST AI RMF controls, drafts the ADR. It's tuned long-form because the artefact has to survive being read by people who weren't in the meeting.
CISO
Narrative. The CISO needs a board-readable answer in three bullets. They need regulatory exposure framed in pounds and minutes, not in CVEs. Jarvis-CISO is the only persona that summarises up — it's tuned to compress, not expand. It refuses to use jargon the board hasn't seen.
Why one product can't be all five
The temptation is to write one prompt that "adapts to who you are." It doesn't work. Three reasons:
- Output shape diverges. A SOC analyst's good answer is 3 lines. A CISO's good answer is 3 bullets. An architect's good answer is 3 pages. The model can produce all three, but you can't reliably get the right one without telling it which one.
- Tool allowlist diverges. The analyst should be able to query the SIEM. The CISO shouldn't. The engineer should be able to draft rules; the analyst shouldn't be able to deploy them. Persona is the cleanest place to draw these lines.
- Memory diverges. The hunter wants long-running session memory across a multi-day investigation. The analyst wants a clean slate every alert. Same memory model breaks both.
The shared infrastructure
Three things are shared, deliberately:
- Retrieval index. All personas read from the same knowledge base — MITRE ATT&CK, NIST mappings, the customer's runbooks, the customer's incident history. Differentiation happens at the prompt level, not the data level.
- Tool registry. All tools are defined once. Personas get a subset. New tools appear in the registry and a persona picks them up by adding them to its allowlist.
- Eval pipeline. Each persona has its own golden set, but they all run through the same eval infrastructure (see the guardrails post).
Differentiate at the prompt and the allowlist. Share at the data and the eval. The opposite — shared prompt with differentiated data — converges back to "one chatbot for everyone" and reproduces the original problem.
What we learned the hard way
Two things, in case they save someone the rediscovery.
1. Persona switching has to be explicit
The first version inferred the persona from the question. It guessed wrong often enough to be annoying and silently — the analyst would ask a triage question and get an architect-shaped answer because the question happened to mention "system." We made persona an explicit, sticky choice. The cost is one extra click. The benefit is consistent output shape.
2. The CISO persona is the hardest
Counterintuitive. The CISO persona has the least technical content. It has, by far, the most evaluator disagreement. Two CISOs reading the same response will judge it differently — and they're both right, because what counts as "board-ready" is genuinely a function of who's on the board. We addressed this by letting each customer customise the CISO persona with a one-paragraph "board style" prompt. The lift on perceived quality was large.
Where it goes next
Two extensions on the roadmap:
- A sixth persona — Compliance Officer. Distinct from the CISO. DPDP-first. Built around the audit trail post we published earlier this month.
- Cross-persona handoff. The analyst's escalation should be readable by the engineer who picks it up. We're standardising the handoff payload so context survives across roles.
Jarvis is live in the playground at /jarvis. Each persona has its own entry. If you run a SOC and want a pilot, drop a line.