@query-ai/digital-workers 1.0.0

package/skills/hunt-quality-checker/SKILL.md

@@ -0,0 +1,105 @@
+---
+name: hunt-quality-checker
+description: Use at Phase 2 exit to verify hunt process compliance — catches skipped data sources, missing artifacts, untracked confidence, and process shortcuts before they degrade hunt quality
+---
+
+# Hunt Quality Checker
+
+## Iron Law
+
+**CHECK THE PROCESS BEFORE ADVANCING THE HUNT.**
+
+Process shortcuts compound. A missing data-map in Phase 1 becomes blind queries in Phase 2 and false confidence in the report. A skipped specialist means domain-specific logic was never applied. These checks exist to catch shortcuts before they degrade hunt quality.
+
+## When to Invoke
+
+- **Phase 2 exit**: Invoked by `threat-hunt` after investigation queries complete, before transitioning to Phase 3 (Pattern & Attack Discovery)
+
+## Reasoning Principles
+
+Three principles anchor all checks.
+
+### 1. Artifacts are gates, not paperwork
+
+`hypothesis.md` and `data-map.md` are not documentation — they are planning artifacts that shape what gets queried and how gaps are measured. Writing them after the queries defeats their purpose.
+
+### 2. Coverage is measurable
+
+The data availability map defines what "complete" means. Without it, confidence is a guess. With it, every unqueried connector and untested TTP is visible.
+
+### 3. Specialists exist for a reason
+
+The orchestrator coordinates. Specialists apply domain-specific logic, query patterns, and quality checks. When the orchestrator does specialist work itself, those quality checks are skipped.
+
+---
+
+## Phase 2 Exit Checkpoint — Hunt Process Compliance
+
+Run at Phase 2 exit, before transitioning to Phase 3. Nine binary checks, designed for <90 seconds.
+
+Review the hunt's hypothesis, data map, queries, and findings, then evaluate each check:
+
+| # | Check | If No |
+|---|-------|-------|
+| 1 | Does `hypothesis.md` exist in the hunt directory AND was it written before any investigation queries? | FAIL — write it now; if queries already ran, document that hypothesis was retroactive |
+| 2 | Does `data-map.md` exist in the hunt directory AND was it written before investigation queries? | FAIL — write it now; document any data sources that were queried without being in the map |
+| 3 | For every TTP in `hypothesis.md`: was at least one query executed that specifically tests it? | FAIL — identify untested TTPs and execute queries before proceeding |
+| 4 | For every connector in `data-map.md` marked as relevant: was it queried, or was a gap documented explaining why not? | FAIL — query the missing connector or document why it was skipped |
+| 5 | Were confidence dimensions tracked during Phase 2 (Data Coverage %, TTP Coverage %, Enrichment Depth %)? | FAIL — calculate and report current confidence now |
+| 6 | Is every executed query logged in `queries.md` with query text, result count, and summary? | FAIL — backfill missing entries before proceeding |
+| 7 | If any finding was classified as Active Threat: was the hunt stopped and escalation initiated? | FAIL — stop now and escalate; do NOT proceed to Phase 3 |
+| 8 | For dynamic schema connectors that returned empty results: is an assumptions caveat documented (data absent vs. mapping gap vs. filter issue)? | FAIL — add caveats before proceeding |
+| 9 | Were specialist skills invoked when their trigger conditions were met? (identity findings → identity-investigator, network findings → network-investigator, IOCs → threat-intel-enricher) | FAIL — invoke the relevant specialist now before proceeding; the orchestrator must not replicate specialist work |
+
+---
+
+## Output Format
+
+After running the checkpoint, output:
+
+```
+HUNT QUALITY CHECK — Phase 2 Exit
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+[1] hypothesis.md exists and pre-dates investigation: PASS | FAIL
+    [If FAIL: what was found and what action to take]
+
+[2] data-map.md exists and pre-dates investigation: PASS | FAIL
+    [If FAIL: what was found and what action to take]
+
+[3] All TTPs tested with at least one query: PASS | FAIL
+    [If FAIL: list untested TTPs]
+
+[4] All relevant connectors queried or gap-documented: PASS | FAIL
+    [If FAIL: list unqueried connectors]
+
+[5] Confidence dimensions tracked: PASS | FAIL
+    [If FAIL: current confidence = Data X% | TTP X% | Enrichment X%]
+
+[6] All queries logged in queries.md: PASS | FAIL
+    [If FAIL: number of unlogged queries]
+
+[7] Active threats escalated (or none found): PASS | FAIL
+    [If FAIL: STOP — escalate now]
+
+[8] Dynamic connector empty results have assumptions caveats: PASS | FAIL
+    [If FAIL: list connectors missing caveats]
+
+[9] Specialist skills invoked when triggered: PASS | FAIL
+    [If FAIL: list which specialists should have been invoked and why]
+
+Result: ALL PASS | [N] FAILURES — fix before proceeding
+```
+
+If any check FAILs, fix the issue before proceeding to Phase 3. Do not defer fixes to the report.
+
+**After the check completes — whether all checks pass or after failures are fixed — immediately continue to Phase 3 without pausing.** This is an inline quality gate, not a stopping point. Do not wait for user input. Print the results and keep going.
+
+## Red Flags
+
+| Red Flag | Correct Action |
+|----------|---------------|
+| "All checks passed" in under 10 seconds | STOP. You didn't actually check. Review each item against the hunt artifacts. |
+| "This check doesn't apply to this hunt" | It might not. But state WHY it doesn't apply — don't just skip. |
+| "I'll fix this in the report" | STOP. Fix it now. The point is to catch shortcuts before Phase 3, not annotate them after. |
+| "The orchestrator already did this work" | STOP. That's the problem. Specialist skills apply domain-specific checks. Invoke them. |

package/skills/hypothesis-builder/SKILL.md

@@ -0,0 +1,303 @@
+---
+name: hypothesis-builder
+description: Use when raw intel, MITRE technique IDs, or analyst hunches need to be transformed into structured, testable hypotheses scoped to available data
+---
+
+# Hypothesis Builder
+
+## Iron Law
+
+**A HYPOTHESIS MUST BE FALSIFIABLE. IF THE DATA CANNOT DISPROVE IT, REFRAME IT.**
+
+## When to Invoke
+
+Called by `threat-hunt` orchestrator when a hunt needs a structured hypothesis:
+- Raw threat intel (articles, advisories, PDFs)
+- MITRE ATT&CK technique or tactic IDs
+- Analyst observations or gut feelings
+- Threat actor or campaign names
+- Specific IOCs or described anomalies
+- "What should I hunt next?" requests (suggest mode)
+
+## Process
+
+### Step 0: Qualification Gate
+
+Before building a hypothesis, verify the input is specific enough. If too vague (e.g., "hunt for bad stuff"), present structured options:
+
+```
+I need a bit more to build a testable hypothesis. Which fits your intent?
+
+  1. "I have a specific threat or technique in mind"
+     -> Tell me the TTP, technique ID, or behavior you're looking for
+
+  2. "I saw something suspicious and want to dig deeper"
+     -> Describe what you observed -- alert, anomaly, user report, gut feeling
+
+  3. "I read an article about a threat and want to check our environment"
+     -> Share the link, paste the text, or upload the PDF
+
+  4. "I want to test our visibility against a threat actor's playbook"
+     -> Name the actor, campaign, or advisory (e.g., APT28, Volt Typhoon, CISA AA24-xxx)
+```
+
+Qualification criteria -- input must contain at least ONE of:
+- A named MITRE ATT&CK technique or tactic
+- A specific observable behavior
+- A threat actor, campaign name, or advisory reference
+- A specific IOC or set of IOCs
+- A described anomaly with enough detail to query
+
+### Step 1: Intel Intake -- Multi-Modal Input Handling
+
+Handle multiple input formats with graceful degradation:
+
+| Input Type | How to Handle | Available In |
+|------------|--------------|-------------|
+| URL to article/advisory | Fetch via WebFetch, extract TTPs, IOCs, actor info | Claude Desktop, Claude Code |
+| Pasted text | Parse directly | All environments |
+| Uploaded PDF | Read via PDF tool | Claude Desktop, Claude Code |
+| MITRE technique ID | Look up technique details, data sources | All environments |
+| Threat actor / campaign name | Use knowledge + TI connectors | All environments |
+| Described anomaly | Structure into testable hypothesis | All environments |
+
+When URL fetch fails:
+
+```
+I couldn't access that URL. To build the hypothesis, I need a few key details:
+
+  1. What threat actor or campaign is described?
+  2. What TTPs or attack techniques are mentioned?
+  3. What IOCs are listed? (IPs, hashes, domains)
+  4. What targets or industries are affected?
+  5. What's the attack timeline or recency?
+
+Even partial answers help -- I can fill gaps from threat intel connectors and MITRE data.
+```
+
+If analyst can't provide details either (e.g., "I just saw a headline about Volt Typhoon"):
+- Use the actor/campaign name to build hypothesis from known MITRE ATT&CK mappings
+- Query any available TI connectors (discovered via `FSQL_Connectors`)
+- Note: "Built from public ATT&CK profile, not from the specific article"
+
+### Step 2: Extract TTPs from Input
+
+Parse the qualified input to identify all referenced TTPs. Map each to its MITRE ATT&CK technique ID, tactic, and associated data sources.
+
+### Step 3: Map TTPs to Data Sources
+
+Use `FSQL_Connectors` + `Search_FSQL_SCHEMA` + the environment profile to determine:
+- Which data sources are available for each TTP
+- Which field paths exist in those connectors (verify -- do not assume standard OCSF paths for dynamic connectors)
+- Where coverage gaps exist (TTPs with no available data source)
+
+### Step 4: Formulate the Hypothesis
+
+Structure as: "We believe [threat/behavior] is occurring in [scope] because [reasoning]. We test by querying [data sources] for [observable patterns]."
+
+Define hunt parameters:
+- Query patterns for each data source
+- Time range for the hunt
+- Baseline vs. suspicious thresholds
+- Success criteria (what proves the hypothesis)
+- Null criteria (what disproves the hypothesis)
+
+### Step 5: Determine Hunt Tier
+
+Derived from the hypothesis structure, not guessed from the prompt:
+
+| Signal | Tier | Rationale |
+|--------|------|-----------|
+| 1-2 TTPs AND 1-3 relevant connectors AND scoped to specific hosts/users/segment | Focused | Narrow hypothesis, limited data surface -- 25 min circuit breaker |
+| 3+ TTPs OR 4+ relevant connectors OR environment-wide scope | Broad | Complex hypothesis, large data surface -- 45 min circuit breaker |
+
+Examples (illustrative -- actual connector names discovered at runtime):
+- "Hunt for RDP lateral movement (T1021.001) from service accounts on finance subnet via [auth connector]" -- 1 TTP, 1 connector -- **Focused**
+- "Hunt for APT28 TTPs: spearphishing, credential dumping, lateral movement, exfil across all connectors" -- 4 TTPs, all connectors -- **Broad**
+- "Hunt for PowerShell fileless execution (T1059.001) across all endpoints" -- 1 TTP, but environment-wide -- **Broad**
+
+The analyst can always override: "Just do a focused pass first" downgrades. "Go broad" upgrades. Default comes from hypothesis structure, not vibes.
+
+### Step 6: Note HMM Level
+
+Document which Hunt Maturity Model level this hunt represents.
+
+## Hunt History Detection — Three-Tier Model
+
+Before generating recommendations, detect what hunt history is available. The maturity of hunt history storage varies by customer — degrade gracefully.
+
+### Detection Sequence
+
+Run these checks in order. Use the FIRST tier that returns data:
+
+**Tier 3: Integrated History (Linear, Notion, JIRA via MCP)**
+Check for project management MCP connectors. Search for hunt-related projects/issues:
+- Linear: Use `list_projects` / `list_issues` to find a "Threat Hunting" project
+- Notion: Use `notion-search` to find hunt databases or pages
+- If found: extract past hypotheses, TTPs tested, gaps identified, detection coverage
+
+**Tier 2: Local History (`docs/hunts/`)**
+Check if `docs/hunts/` directory exists with past hunt artifacts:
+- Read `gaps.md` files from previous hunts for known coverage gaps
+- Read `findings.md` files for previously tested TTPs and results
+- Read `detections.md` for existing detection coverage
+
+**Tier 1: Zero History (First Hunt)**
+No hunt history available — this is the first hunt or history isn't stored.
+- Rely entirely on: available connectors, MITRE ATT&CK coverage analysis, TI signals, environment profile
+- Explicitly note: "No hunt history detected. Recommendations based on data availability and threat landscape."
+
+### Tier Detection Output
+
+```
+HUNT HISTORY: Tier [1/2/3] — [Zero History / Local History / Integrated (Linear)]
+  Source: [what was found]
+  Past hunts: [count or "none"]
+  Known gaps: [count or "none"]
+  TTPs previously tested: [count or "none"]
+```
+
+**This detection feeds directly into suggest mode and influences recommendation ranking.**
+
+---
+
+## Suggest Mode — Default Entry Point (HMM3 Capability)
+
+Suggest mode is the **default** when the analyst does not provide a specific hypothesis, technique, or intel. This includes:
+- "What should I hunt?"
+- "Suggest hunts"
+- "What's worth looking at?"
+- "Let's go hunting" (no specific target)
+- "Start a hunt" (no hypothesis attached)
+- Any prompt that invokes `threat-hunt` without qualifying input
+
+### Recommendation Ranking Criteria
+
+Score each candidate hunt on five weighted dimensions:
+
+| Dimension | Weight | What It Measures |
+|-----------|--------|------------------|
+| **Data Availability** | 30% | Do we have connectors and verified field paths for this TTP? Hunts with data rank higher than hunts against gaps. |
+| **TTP Risk Impact** | 25% | MITRE ATT&CK prevalence and impact. Techniques used by active threat actors in the current landscape rank higher. |
+| **Never Tested** | 20% | Has this TTP or tactic EVER been hunted? (From hunt history tier). First-time coverage ranks higher than re-tests. |
+| **TI Relevance** | 15% | Are threat intel connectors showing current activity related to this TTP? Recent signals rank higher. |
+| **Environment Change** | 10% | Have new connectors, field mappings, or data sources appeared since the last hunt? New data = new visibility. |
+
+### Recommendation Generation Process
+
+1. **Detect hunt history tier** (see above)
+2. **Discover available connectors** via `FSQL_Connectors`
+3. **Map connector coverage to MITRE ATT&CK** — which tactics/techniques can we actually test?
+4. **Query TI connectors** for recent threat signals (if available)
+5. **Check environment profile** for changes since last hunt
+6. **Score and rank** candidate hunts using the 5-dimension model
+7. **Present Top 10** to the analyst
+
+### Suggest Mode Output Format
+
+```
+HUNT HISTORY: Tier [1/2/3] — [status]
+
+RECOMMENDED HUNTS — Top 10 (ranked by composite score)
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+ 1. [HIGH — 92] Hunt for scheduled task persistence (T1053.005)
+    Why: Zero previous coverage of Persistence tactic. 2 connectors with verified paths.
+    Score: Data 30/30 | Risk 22/25 | Untested 20/20 | TI 10/15 | Env 10/10
+    Source: ATT&CK coverage gap + environment change (new EDR connector)
+    Tier: Focused — 1 TTP, 2 connectors
+
+ 2. [HIGH — 87] Hunt for CVE-2026-XXXXX exploitation (T1190)
+    Why: Actively exploited vulnerability affecting [product] in environment.
+    Score: Data 25/30 | Risk 25/25 | Untested 15/20 | TI 15/15 | Env 7/10
+    Source: Threat intel connector signal (last 72h)
+    Tier: Focused — 1 TTP, 1 connector
+
+ 3. [HIGH — 81] Hunt for PowerShell fileless execution (T1059.001)
+    Why: High-impact execution technique, strong data coverage, never tested.
+    Score: Data 30/30 | Risk 20/25 | Untested 20/20 | TI 5/15 | Env 6/10
+    Source: ATT&CK coverage gap analysis
+    Tier: Broad — 1 TTP, environment-wide
+
+ ...
+
+10. [MEDIUM — 54] Baseline new [connector name] data
+    Why: New dynamic schema connector — field mappings untested.
+    Score: Data 10/30 | Risk 10/25 | Untested 20/20 | TI 4/15 | Env 10/10
+    Source: Environment profile change
+    Tier: Broad — discovery sweep
+
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+Select a number to begin, or describe a different hypothesis.
+```
+
+**Tier 1 (zero history) messaging:**
+
+```
+HUNT HISTORY: Tier 1 — Zero History
+  This appears to be your first structured hunt. Recommendations are based
+  entirely on your current data sources and the threat landscape.
+
+  After this hunt, findings and gaps will be stored locally (docs/hunts/)
+  to improve future recommendations. For persistent tracking, consider
+  creating a Threat Hunting project in Linear, Notion, or JIRA.
+
+RECOMMENDED HUNTS — Top 10 (ranked by composite score)
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+[recommendations as above, but Never Tested dimension scores 20/20 for all]
+```
+
+## Output
+
+```
+HYPOTHESIS:
+  Statement: "We believe [threat/behavior] is occurring in [scope] because
+              [reasoning]. We test by querying [data sources] for
+              [observable patterns]."
+
+  MITRE Mapping:
+    Technique: [ID] -- [Name]
+    Tactic: [Tactic name]
+    Data Sources: [list]
+
+  Data Source Map:
+    Available: [connectors with verified field paths]
+    Gaps: [TTPs with no available data source]
+    Coverage: [percentage of hypothesis TTPs with data]
+
+  Query Strategy:
+    Data Sources: [connector list]
+    Time Range: [start -- end]
+    Baseline: [what normal looks like]
+    Suspicious: [thresholds that indicate the hypothesis may be true]
+
+  Success Criteria: [what confirms the hypothesis]
+  Null Criteria: [what disproves the hypothesis]
+
+  Hunt Tier: [Focused / Broad] -- [rationale]
+  Circuit Breaker: [25 min / 45 min]
+  HMM Level: [level]
+
+  Confidence Dimensions:
+    Data Coverage: [what constitutes 100% for this hunt]
+    TTP Coverage: [what constitutes 100% for this hunt]
+
+  Source Note: [origin of hypothesis -- analyst input, article, suggest mode, etc.]
+```
+
+**Return this structured hypothesis to the calling orchestrator and continue. Do not present to the user or wait for input unless running the qualification gate.**
+
+## Red Flags
+
+| Red Flag | Correct Action |
+|----------|---------------|
+| "Let's just look for anything suspicious" | STOP. That's not a hypothesis. Run the qualification gate. |
+| Accepting a vague hypothesis to avoid friction | STOP. Vague hypotheses produce meaningless results. Guide the analyst. |
+| Hardcoding connector names in the hypothesis | STOP. Use `FSQL_Connectors` for runtime discovery. |
+| Skipping data source mapping | STOP. A hypothesis without a data source map will waste Phase 2 on queries that can't return results. |
+| Determining tier from vibes instead of structure | STOP. Count TTPs, connectors, and scope. The tier is a calculation, not a judgment call. |
+| Assuming standard OCSF paths for dynamic connectors | STOP. Use `Search_FSQL_SCHEMA` to verify field paths. Dynamic connectors have customer-defined mappings. |
+| URL fetch failed, abandoning the hunt | STOP. Degrade gracefully -- use actor name, MITRE mappings, TI connectors. Never let access failure kill the hunt. |
+| Building hypothesis without checking what data actually exists | STOP. Map TTPs to available data BEFORE finalizing. A beautiful hypothesis against data you don't have is useless. |
+| Recommending hunts without checking hunt history | STOP. Run the three-tier history detection. Recommending a TTP you already hunted last week is wasted effort. |
+| Hardcoding hunt history location | STOP. Detect the tier at runtime. Not every customer has Linear or local hunt artifacts. Degrade gracefully. |

package/skills/identity-investigator/SKILL.md

@@ -0,0 +1,172 @@
+---
+name: identity-investigator
+description: Use when investigation involves user accounts, authentication events, privilege changes, or identity-based indicators — deep dive on user behavior and access patterns
+---
+
+# Identity Investigator
+
+## Iron Law
+
+**ESTABLISH BASELINE BEFORE JUDGING ANOMALOUS.**
+
+A failed login is not suspicious without context. 50 failed logins from the same IP in 5 minutes is. Always gather enough data to distinguish normal from abnormal for this specific user/account.
+
+## When to Invoke
+
+Called by `alert-investigation` when the `alert-classifier` identifies:
+- Alert type: Identity/Access
+- IOCs include: usernames, email addresses, service accounts
+- MITRE techniques: T1078 (Valid Accounts), T1110 (Brute Force), T1136 (Create Account), T1098 (Account Manipulation)
+
+## Investigation Process
+
+Use `digital-workers:fsql-expert` for ALL queries below.
+
+### Step 1: Identify the Account
+
+From the alert IOCs, identify:
+- Username(s) involved
+- Account type: human user, service account, admin account, shared account
+- Associated email address(es)
+
+### Step 2: Authentication Pattern Analysis
+
+Query authentication events for this user with specific field selectors:
+
+```
+QUERY authentication.message, authentication.time, authentication.status_id,
+      authentication.src_endpoint.ip, authentication.user.username,
+      authentication.http_request.user_agent
+WITH authentication.user.username = '<username>' AFTER 7d
+```
+
+Look for:
+- **Volume**: How many auth events in the time window? Is this normal?
+- **Failures**: Count and pattern of failures vs. successes
+- **Source IPs**: Are logins coming from expected locations?
+- **Timing**: Are logins happening at expected times?
+- **MFA**: Was MFA used? Was it bypassed?
+- **Methods**: Password, SSO, API key, certificate — is the method expected?
+
+**SUMMARIZE for authentication pattern analysis:**
+
+Use SUMMARIZE to quickly quantify authentication patterns before drilling into individual events:
+
+```
+-- Failure volume and source distribution
+SUMMARIZE COUNT DISTINCT authentication.src_endpoint.ip
+GROUP BY authentication.actor.user.email_addr
+WITH authentication.status_id = FAILURE AFTER 7d
+
+-- Success from unusual locations (impossible travel signal)
+SUMMARIZE COUNT DISTINCT authentication.device.ip
+GROUP BY authentication.actor.user.email_addr
+WITH authentication.status_id = SUCCESS AFTER 24h
+
+-- Auth volume per source IP (which IPs are most active?)
+SUMMARIZE COUNT authentication.user.uid
+GROUP BY authentication.src_endpoint.ip
+WITH authentication.actor.user.email_addr = '<user>' AFTER 7d
+```
+
+Start with SUMMARIZE for the distribution picture, then QUERY for the individual events that look anomalous.
+
+> **Constraints:** SUMMARIZE has known execution limits — `status_id` filtering fails on detection_finding (use GROUP BY instead), `FROM` not supported, high-cardinality GROUP BY can overflow. If SUMMARIZE returns empty, fall back to QUERY. See fsql-expert Layer 1c for workarounds and check `summarize_support` in the environment profile.
+
+### Step 3: Privilege and Account Changes
+
+Query for account modifications:
+
+```
+QUERY account_change.message, account_change.time, account_change.user.username,
+      account_change.type_name
+WITH account_change.user.username = '<username>' AFTER 30d
+```
+
+Look for:
+- Role or group changes
+- Password resets
+- MFA enrollment/removal
+- New API keys or tokens created
+- Permission escalation
+
+### Step 4: Session Activity
+
+If the user authenticated successfully, what did they do?
+
+```
+-- Layer 1a: Discover which event types contain this user's activity
+QUERY *.message, *.time WITH %username = '<username>' AFTER 24h
+
+-- Layer 1b: Query specific event types found in Layer 1a with targeted fields
+-- (adapt based on which __event types appear in Layer 1a results)
+```
+
+This discovery scan reveals all event types across the mesh tied to this identity. Read the `__event` field to see where the user appears, then query those specific event types for detail:
+- Applications accessed
+- Data sources queried
+- Files accessed or modified
+- Cloud resources touched
+
+### Step 5: Cross-Reference Source IPs
+
+For any suspicious source IPs found in auth events:
+
+```
+-- Layer 1a: Discover where this IP appears across the mesh
+QUERY *.message, *.time WITH %ip = '<suspicious_ip>' AFTER 7d
+
+-- Layer 1b: Query specific event types found in Layer 1a
+```
+
+Determine:
+- Is this IP used by other users? (Shared VPN, office IP)
+- Is this IP associated with other suspicious activity?
+- Geo-location and reputation (pass to `threat-intel-enricher`)
+
+### Step 6: Assess and Report
+
+Synthesize findings into:
+- **Account compromise confidence**: Confirmed / Likely / Possible / Unlikely
+- **Timeline**: When did suspicious activity start?
+- **Scope**: What systems/data were accessed?
+- **Lateral movement**: Did the compromised account access other systems?
+- **Persistence**: Were new credentials or access methods created?
+
+## Output
+
+```
+IDENTITY INVESTIGATION:
+  Account: [username] ([account type])
+  Compromise Assessment: [Confirmed/Likely/Possible/Unlikely]
+
+  Authentication Summary:
+    Total events (7d): [count]
+    Failures: [count] from [unique IPs] IPs
+    Successes: [count] from [unique IPs] IPs
+    Unusual: [description of anomalies]
+
+  Account Changes (30d): [list or "None detected"]
+
+  Post-Auth Activity:
+    Systems accessed: [list]
+    Data sources queried: [list]
+    Anomalous actions: [list or "None detected"]
+
+  Suspicious Source IPs: [list with reputation]
+
+  Timeline: [chronological summary]
+
+  IOCs Discovered: [new indicators found during investigation]
+  Recommended Follow-Up: [additional queries or skills to invoke]
+```
+
+**Return this investigation output to the calling orchestrator and continue. Do not present to the user or wait for input — the orchestrator will incorporate findings into the evidence package.**
+
+## Red Flags
+
+| Red Flag | Correct Action |
+|----------|---------------|
+| "Only one failed login, not suspicious" | Complete the investigation. One failed login with a successful login from a new IP seconds later IS suspicious. |
+| "This is a service account, skip user analysis" | STOP. Service account compromise is often MORE severe. Investigate fully. |
+| "I can see the auth logs, that's enough" | STOP. Check account changes and post-auth activity too. Auth is just the entry point. |