| name | rl-soc |
| description | Full SOC threat-analysis pipeline. Give it a file, hash, URL, IP, or domain and it runs all phases in sequence: triage → FP validation → investigation → adjudication → remediation (if TP) → reporting. Triggers on "analyze this hash", "investigate this URL", "is this malware", "run threat analysis on", "I got a suspicious file", or any submission of an indicator for end-to-end SOC workflow.
|
rl-soc
Full multi-phase SOC threat-analysis pipeline backed by ReversingLabs Spectra
Intelligence. Runs all phases in sequence, with parallel sub-agents within
triage and investigation for speed.
All Spectra Intelligence calls are made via the rl-spectra-intel CLI using the
Bash tool — no MCP server required.
CRITICAL CONSTRAINTS
- Do NOT perform any manual analysis of files. Never run
xxd, strings,
file, hexdump, cat, or any tool to inspect file contents. Pass file
paths as plain strings to sub-agents. All analysis goes through Spectra.
- Use the
rl-spectra-intel CLI via Bash for all Spectra calls.
Do NOT use MCP tools. Do NOT call the Spectra API directly.
Pattern: rl-spectra-intel <tool_name> --args '<json>' — single-line Bash,
exit codes: 0 success / 1 API error / 2 bad args.
- Use Spectra Intelligence tools exclusively. Do NOT query VirusTotal,
URLhaus, AbuseIPDB, Shodan, AlienVault OTX, MalwareBazaar, or any other
external platform.
- Do NOT use any
rl-protect skills or tools.
- Do NOT check for credentials,
.env files, config files, or the venv.
You are the orchestrator
You manage the pipeline. Run phases in order using the Task tool to spawn
sub-agents. Write handoff files after each phase. Route conditionally based
on FP validation and adjudication results.
Pre-Step — Determine pipeline scope
Before doing anything else, determine how much of the pipeline the analyst wants.
Infer from the request:
| If the request says… | Scope |
|---|
| "analyze", "full analysis", "is this malware", "threat analysis", "run the pipeline", "SOC workflow" | FULL — all 6 phases |
| "triage only", "classify", "quick check", "just triage" | TRIAGE_ONLY — phase 1 only |
| "investigate only", "triage and investigate", "investigate but skip report" | INVESTIGATE — phases 1–3 |
| "is this a FP", "is this a TP", "evaluate this detection", "verdict only", "just tell me if it's malicious", "FP/TP check" | VERDICT_ONLY — phases 1–4, no remediation or report |
| Unclear — none of the above clearly match | Ask |
If unclear, ask before starting:
"Should I run the full pipeline including remediation playbook and incident report?
Those phases take longer and consume significantly more tokens. Or would you prefer:
- Full pipeline — all 6 phases including remediation and incident report
- Verdict only — triage + investigation + FP/TP verdict (no remediation or report)
- Triage only — quick classification and sandbox kickoff only"
Store the scope as PIPELINE_SCOPE before proceeding.
Step 0 — Generate investigation ID and artifact slug
Before starting any phase, generate a unique investigation ID:
date +%Y%m%d-%H%M%S
Store this as INVESTIGATION_ID.
Also derive ARTIFACT_SLUG from the artifact to make all handoff files self-describing:
| Artifact type | ARTIFACT_SLUG |
|---|
| SHA256 hash | First 12 characters of the hash (e.g. a3f8e91b2c04) |
| SHA1 or MD5 hash | First 12 characters of the hash |
| File upload | upload for now; replace with first 12 chars of SHA256 after Phase 1 returns |
| URL | Hostname with . replaced by -, truncated to 20 chars (e.g. evil-example-com) |
| IP address | Dots replaced with hyphens (e.g. 192-168-1-1) |
| Domain | Dots replaced with hyphens, truncated to 20 chars (e.g. malware-example-com) |
All handoff files are written to a subdirectory named <ARTIFACT_SLUG>/ in the
current working directory. For hash and network artifacts, create the directory
immediately after deriving the slug:
mkdir -p <ARTIFACT_SLUG>
For file uploads, create the directory after Phase 1 returns the SHA256 and
ARTIFACT_SLUG is finalized (see Phase 1).
Files follow the pattern <ARTIFACT_SLUG>/<name>-<ARTIFACT_SLUG>-<INVESTIGATION_ID>.md.
Pre-lookup for hash artifacts
For hash artifacts (SHA256, SHA1, MD5), call get_sample_overview now —
before spawning any sub-agents — to determine the file type and size:
rl-spectra-intel get_sample_overview --args '{"hash_value": "<hash>"}'
Store the result as SAMPLE_OVERVIEW. Extract:
SAMPLE_FILE_TYPE — the Spectra file type (e.g. Text/PowerShell, PE/Exe)SAMPLE_SIZE — file size in bytes
If the call fails or the sample is unknown, store SAMPLE_FILE_TYPE = unknown
and SAMPLE_SIZE = unknown. This is non-fatal — triage will proceed and
rl-triage-inspect will handle the unknown case itself.
Skip this pre-lookup for file uploads (SHA256 not yet known) and network
indicators (no file to inspect).
Tell the analyst:
"Starting investigation <INVESTIGATION_ID> for <artifact>."
Phase 1 — Triage + Content Inspection
Hash artifacts
Spawn ALL THREE sub-agents simultaneously in a single Task turn:
rl-triage-classify — artifact identification, classification, indicators, TTPs,
detection rules. Pass the full SAMPLE_OVERVIEW JSON from the pre-lookup so the
agent does not repeat the get_sample_overview call.
rl-triage-sandbox — dynamic/auxiliary analysis status check and kickoff.
rl-triage-inspect — pass the SHA256, SAMPLE_FILE_TYPE, and SAMPLE_SIZE
(from the pre-lookup above). The agent will use these directly and skip
get_sample_overview. If SAMPLE_FILE_TYPE is not Text/* or SAMPLE_SIZE
exceeds 722KB, the agent will skip immediately without making any API calls.
File upload artifacts
Spawn only rl-triage-classify and rl-triage-sandbox simultaneously.
After rl-triage-classify returns the SHA256, file type, and file size, check
whether rl-triage-inspect is applicable:
- If file type starts with
Text/ AND size ≤ 739,328 bytes → spawn
rl-triage-inspect, passing the SHA256, file type, and size.
- Otherwise → skip rl-triage-inspect.
Wait for rl-triage-inspect to complete before proceeding.
Update ARTIFACT_SLUG using the first 12 characters of the SHA256, then create
the directory:
mkdir -p <ARTIFACT_SLUG>
Network indicators (URL, IP, domain)
Spawn only rl-triage-classify and rl-triage-sandbox — do not spawn
rl-triage-inspect (no file content to analyze).
After all applicable sub-agents return, synthesize their outputs.
Write the triage handoff to <ARTIFACT_SLUG>/rl-triage-handoff-<ARTIFACT_SLUG>-<INVESTIGATION_ID>.md.
If rl-triage-inspect ran and produced output, write
<ARTIFACT_SLUG>/rl-triage-inspect-findings-<ARTIFACT_SLUG>-<INVESTIGATION_ID>.md.
Check the rl-triage-inspect verdict (if it ran):
-
CONCLUSIVE BENIGN → Skip Phases 2, 3, and 4. Skip Phase 5.
Tell the analyst:
"Triage complete. Content inspection: CONCLUSIVE BENIGN — [key signals].
Skipping FP validation, investigation, and remediation. Generating report."
Go directly to Phase 6 (reporting).
-
CONCLUSIVE MALICIOUS → Skip Phase 2 only. Go directly to Phase 3.
Tell the analyst:
"Triage complete. Content inspection: CONCLUSIVE MALICIOUS — [key signals].
Skipping FP validation. Proceeding to investigation."
-
INCONCLUSIVE, SKIPPED, or did not run → Continue to Phase 2.
Give the analyst a status update:
"Triage complete — [verdict]. Proceeding to FP validation."
Phase 2 — FP Validation
(Skip if rl-triage-inspect returned CONCLUSIVE BENIGN or CONCLUSIVE MALICIOUS)
Spawn: rl-fp-validate — pass full <ARTIFACT_SLUG>/rl-triage-handoff-<ARTIFACT_SLUG>-<INVESTIGATION_ID>.md contents.
Also pass <ARTIFACT_SLUG>/rl-triage-inspect-findings-<ARTIFACT_SLUG>-<INVESTIGATION_ID>.md
if it exists — content analysis signals are relevant FP evidence.
After it returns, write <ARTIFACT_SLUG>/rl-fp-validate-findings-<ARTIFACT_SLUG>-<INVESTIGATION_ID>.md.
Check the recommendation:
-
CONCLUSIVE FP → Skip Phases 3 and 4. Skip Phase 5. Go directly to Phase 6.
Tell the analyst:
"FP validation returned CONCLUSIVE FP — [key signals]. Skipping investigation
and remediation. Generating report."
-
POSSIBLE FP / LIKELY TP / INSUFFICIENT DATA → Continue to Phase 3.
Tell the analyst the FP confidence level and proceed.
Phase 3 — Investigation
(Skip if Phase 1.5 returned CONCLUSIVE BENIGN)
(Skip if Phase 2 returned CONCLUSIVE FP)
Spawn ALL THREE sub-agents simultaneously in a single Task turn:
rl-investigate-enrich — bulk IOC enrichment.
rl-investigate-pivot — advanced search pivots + certificate analytics.
rl-investigate-hunt — YARA retrohunt + sandbox polling.
After all three return, synthesize and write
<ARTIFACT_SLUG>/rl-investigate-findings-<ARTIFACT_SLUG>-<INVESTIGATION_ID>.md.
Give the analyst a status update:
"Investigation complete. Starting adjudication."
Phase 4 — Adjudication
(Skip if Phase 2 returned CONCLUSIVE FP)
Spawn: rl-adjudicate — pass triage handoff + FP findings + investigation findings.
After it returns, write <ARTIFACT_SLUG>/rl-adjudication-verdict-<ARTIFACT_SLUG>-<INVESTIGATION_ID>.md.
Check the routing decision:
Phase 5 — Remediation
(Only runs if PIPELINE_SCOPE is FULL AND adjudication verdict is CONFIRMED TP or UNCERTAIN)
(Skip entirely if PIPELINE_SCOPE is VERDICT_ONLY, INVESTIGATE, or TRIAGE_ONLY)
Spawn: rl-remediate — pass triage handoff + investigation findings + adjudication verdict.
After it returns, write <ARTIFACT_SLUG>/rl-remediate-playbook-<ARTIFACT_SLUG>-<INVESTIGATION_ID>.md.
Phase 6 — Reporting
(Always runs when the pipeline short-circuited via CONCLUSIVE BENIGN or CONCLUSIVE FP)
(Otherwise only runs if PIPELINE_SCOPE is FULL; skip if VERDICT_ONLY, INVESTIGATE, or TRIAGE_ONLY)
Spawn: rl-report — pass all available phase outputs (triage, content
inspection if ran, FP validation if ran, investigation if ran, adjudication,
remediation if ran).
After it returns, confirm both output files exist.
Abort if blocked
If any phase fails (API error, agent returns nothing useful, file write fails),
surface the error to the analyst and ask how to proceed. Do not silently skip
a phase with missing data.
Final summary
After all phases complete, tell the analyst:
-
Final verdict and threat name (from adjudication, if adjudication ran)
-
FP critique assessment (from adjudication, if adjudication ran)
-
IOC count (if investigation ran)
-
Which phases ran and which were skipped (including any skipped due to PIPELINE_SCOPE)
-
Investigation ID (<INVESTIGATION_ID>)
-
If Phase 6 ran: paths to both output files (<ARTIFACT_SLUG>/incident-<INVESTIGATION_ID>-<ARTIFACT_SLUG>-report.md and <ARTIFACT_SLUG>/incident-<INVESTIGATION_ID>-<ARTIFACT_SLUG>-iocs.json)
-
If Phase 6 did not run: remind the analyst they can run rl-report or rl-remediate standalone if they want those outputs later
-
Any UNCERTAIN verdict open questions for human review
-
Token usage summary table collected from all agent ## Usage Estimate sections:
| Agent | Model | Input tokens | Output tokens |
|---|
| rl-triage-classify | sonnet/high | N | N |
| rl-triage-sandbox | haiku/low | N | N |
| rl-triage-inspect (if ran) | opus/high | N | N |
| ... | | | |
| Total | | N | N |
Note: full breakdown is also embedded in the incident report.
