Investigation Playbooks

Operating posture

Telltale investigations should be evidence-minimal by default. Use redacted events, hashes, rule IDs, and response fields first. Open local session stores only when the event cannot answer scope, timing, or intent questions.

• Start with event_type, severity, risk_score, client, session_id, tool_name, categories, and rule_ids.
• Review response.recommended_action, response.response_playbook, response.escalation, and response.investigation_summary before opening raw stores.
• Use triage.timeline_anchors when present to decide which raw records need authorized review.
• Do not copy raw transcript bodies, credentials, or local session files back into Splunk or shared reports.
• If scanner_error or health events exist for a client, treat a quiet detection feed cautiously.

Playbook: MCP prompt injection with egress

Use this when categories include mcp_prompt_injection, approval_bypass, secret_access, or exfiltration; or when rule_ids include mcp.tool_metadata.prompt_injection, network.controlled_test_domain.darkroast, or chain.mcp_injection_then_egress.

• Confirm the client, session_id, tool_name, categories, rule_ids, severity, risk_score, and response fields.
• Identify whether evidence came from MCP metadata, server instructions, tool result content, arguments, or assistant context.
• Check whether egress evidence is a controlled validation domain, a real external destination, or only quoted text in documentation.
• Use timeline anchors or source provenance to locate the minimum local raw record needed for authorized review.
• Record whether the injection text was followed by a tool call, secret read, outbound request, or only appeared as inert context.

event_type=detection
categories includes mcp_prompt_injection, approval_bypass, and secret_access or exfiltration
rule_ids includes mcp.tool_metadata.prompt_injection and network.controlled_test_domain.darkroast
response.response_playbook should identify the strongest matched rule family

Playbook: credential harvesting before package publish

Use this when rule_ids include credential.cloud_harvest, supply_chain.publish, or chain.credential_then_publish; or when categories combine credential_harvesting and supply_chain.

• Confirm whether credential evidence is a path match, command argument, file_path, or tool result excerpt.
• Confirm whether publishing evidence is npm, pnpm, yarn, bun, twine, cargo, gem, NuGet, or Maven activity.
• Look for explicit release intent in user context when the source preserves it. Do not assume Copilot process logs preserve user intent.
• Check repository state separately: package name, changed files, release workflow, package destination, and actor authorization.
• Escalate when credential access and publish commands appear in the same session without clear authorized release intent.

event_type=detection
severity=critical when the chain is present
categories includes credential_harvesting and supply_chain
rule_ids includes credential.cloud_harvest, supply_chain.publish, and chain.credential_then_publish

Playbook: encoded DNS or HTTP exfiltration

Use this when rule_ids include exfil.dns_encoding, exfil.encoded_http, execution.encoded_payload, chain.shell_encoded_payload, or chain.harvest_then_exfil.

• Decide whether encoded text was only mentioned, decoded for inspection, transmitted, or executed.
• Review tool_name and command/arguments evidence for nslookup, dig, host, curl, wget, fetch, Invoke-WebRequest, base64, certutil, openssl, or shell piping.
• Prefer redacted evidence hashes for correlation. Do not paste full encoded payloads into case notes unless policy allows it.
• Check nearby categories for secret_access or credential_harvesting before assigning impact.
• Treat shell decode followed by execution as stronger evidence than encoding or DNS tooling alone.

event_type=detection
severity=high or critical when the chain is present
categories includes execution and exfiltration
rule_ids includes execution.encoded_payload, exfil.dns_encoding, and chain.shell_encoded_payload

Playbook: scanner health before conclusions

Use this when an expected client is quiet or when detections look incomplete. Scanner health and parser errors are investigation evidence too.

• Review scanner_error events for malformed, unreadable, or partially parsed sources.
• Review health, scanner_error, and operational_alert events by component, check_name, and status.
• Confirm source validation status before declaring a client clean. Fixture-backed support is not the same as complete live validation.
• Run bounded parser health checks with --dry-run, --client, and --max-sources before scanning broad real stores.

telltale scan --once --dry-run --root "$HOME" --client opencode --max-sources 5

Splunk triage pivots

The Telltale repository includes starter Splunk content that assumes Telltale JSONL is ingested as sourcetype=adr:json and index=adr. Saved searches are disabled by default so operators can tune schedule, suppression, ownership, and action policy before enabling alerts.

• Telltale - Critical or High Detections: alert candidate for event_type=detection with high or critical severity.
• Telltale - MCP Prompt Injection Review: focuses on categories=mcp_prompt_injection and includes rule and tool pivots.
• Telltale - Response Playbook Summary: groups detections by response playbook, recommended action, and escalation.
• Telltale - Scanner Parse Errors: operational health panel before assuming a quiet feed is clean.
• Telltale - Cross Session Correlations: reviews telltale export --correlate output for repeated high-risk behavior.

Evidence handling notes

• Preserve raw local session stores separately from SIEM events when authorized.
• Hash important raw artifacts and record source path, collection time, collector, and transformation steps.
• Report observed facts separately from inferred intent.
• Use source capability profiles before interpreting missing user prompts, call IDs, workspace fields, or error state.
• Keep simulate-block language conservative: current docs describe it as approximated by strict alert policy, not a distinct shipped CLI mode.