Executive Overview
Modern security programs sit on oceans of telemetry (SIEM), agent data (EDR/EPP), identity signals (IdP/IAM), and workflow systems (SOAR/ITSM). Prompt engineering turns those feeds into actionable, auditable decisions—classifying alerts, exploring containment options, pulling live evidence, citing control standards, and orchestrating governed incident response. This article shows balanced, production-grade patterns for:
CoT: crisp, low-latency alert triage
ToT: explore containment/remediation branches, then choose
ReAct: query SIEM/EDR tools inside the prompt loop
RAG: ground answers in frameworks (NIST/CIS/ISO) and local policies
GSCP: only when multi-stage, high-risk actions need approvals and audit
Each section includes copy-paste prompts with JSON outputs suitable for SOAR integration.
The Security Data Surface (Model at a Glance)
Facts: alerts, events, process starts, net flows, auths, file writes, ticket states
Metrics: MTTA/MTTR, dwell time, alert fidelity, FPs, coverage by control family
Features: rare process score, beacon interval z-score, lateral-movement heuristics
Narratives: shift handovers, executive updates, post-incident reports with citations
Treat SIEM queries, EDR hunts, CMDB lookups, and ticket updates as tools the model can call; keep lineage and policy (PII, data handling, approvals) explicit.
CoT — Fast, Deterministic Alert Triage
Use when: single best decision with clear policy (classify/route/close).
Tactic: Reason silently; output a compact JSON verdict + rationale.
Prompt: CoT Alert Triage (Email Security Example)
System
You are a SOC triage helper. Think silently; do not reveal internal reasoning. Output JSON only.
User
Classify this alert and decide next step. Prefer precision over recall.
Inputs:
- alert_id: "{{id}}"
- category: "Email"
- signals: {spf: "fail", dkim: "pass", dmarc: "none",
url_count: 3, attachments: ["invoice.zip"], user_reported: true,
vendor_score: 68}
- policy_id: "SOC-Triage-Email-2025"
Output (JSON):
{
"label": "phish|spam|benign|needs_review",
"action": "isolate_msg|quarantine_user|close|manual_review",
"severity": "low|medium|high",
"reason_codes": ["≤5 bullets"],
"citations": ["policy:SOC-Triage-Email-2025","alert:{{id}}"]
}
ToT — Branching Playbooks with Scored Options
Use when: multiple viable paths (e.g., suspected ransomware).
Tactic: Generate 2–4 options → score by criteria (risk, blast radius, SLOs) → select one; keep exploration private.
Prompt: ToT for Containment Strategy (EDR Host)
System
You are an IR containment planner. Explore options privately; output JSON only.
User
Endpoint {{hostname}} shows ransomware indicators. Propose options and pick the best.
Constraints:
- Minimize data loss and lateral movement.
- Respect maintenance window rules MW-2025-Q3.
Inputs:
- edr_signals_id: "edr-indicators-v6" // suspicious procs, file mods, crypto APIs
- business_impact: "HIGH"
- maintenance_policy_id: "MW-2025-Q3"
Output:
{
"chosen": {
"steps": ["isolate_host","kill_process:pid=...","snapshot_volume","acquire_triage"],
"justification": ["≤5 bullets"],
"risk_score": 0.19
},
"alternatives": [
{"steps":["kill_process","monitor_5m"], "risk_score":0.42, "tradeoffs":["residual lateral risk"]},
{"steps":["isolate_host","block_hash","YARA_hunt_org"], "risk_score":0.24}
],
"citations": ["signals:edr-indicators-v6","policy:MW-2025-Q3"]
}
ReAct — Tool-Augmented Evidence Gathering (SIEM/EDR)
Use when: you must look up live evidence before deciding.
Tactic: Define tools in the system message; instruct the model to call them as needed; output only the final JSON.
Prompt: ReAct Hunt (Suspicious Process Across Fleet)
System
You are a hunt assistant. Use tools to gather evidence; then output JSON only.
Tools
- siem_query(q) -> rows[]
- edr_find_process(hash) -> [{host, pid, user, first_seen, last_seen}]
- cmdb_owner(host) -> {owner, dept, criticality}
User
Investigate process hash "{{sha256}}". Report prevalence, affected hosts, and owners.
Output:
{
"prevalence": {"hosts": 7, "first_seen": "2025-09-11T03:20Z"},
"affected_hosts": [{"host":"ws-044","owner":"A. Ruiz","dept":"Finance"}],
"recommended_action": "block_hash|isolate_subset|benign_known|manual_review",
"rationale": ["≤5 bullets"]
}
RAG — Grounded Answers with Control & Policy Citations
Use when: responses must cite controls, standards, and internal policies.
Tactic: Retrieve from vector indexes (NIST/CIS/ISO mappings, local SOPs); forbid uncited claims.
Prompt: RAG for Control Standards Mapping
System
You are a compliance explainer. Cite sources; no claim without a citation.
User
Explain how our EDR containment playbook satisfies CIS Control 10 and NIST 800-53 (SI-4).
Context indexes:
- controls_index_v3 // CIS, NIST, ISO passages
- playbooks_index_v2 // local IR playbooks
Output:
{
"summary": "≤120 words",
"control_links": [
{"framework":"CIS","control":"10.7","evidence":"playbook:EDR-Containment#steps-2-4"},
{"framework":"NIST","control":"SI-4(2)","evidence":"playbook:Monitoring#isolation"}
],
"gaps": ["no documented rollback test schedule"],
"citations": ["cis:10.7#text","nist:SI-4#(2)","playbook:EDR-Containment#steps-2-4"]
}
GSCP — Governed, Multi-Stage Incident Response (Use Sparingly)
Use when: actions change systems or users (quarantine, password reset, firewall changes) and must pass policy gates with audit.
Prompt: GSCP for High-Risk Account Takeover (ATO)
System
Role: Incident Commander for ATO. Follow stages; never reveal internal notes.
Stages
1) Clarify → ensure target is this account only; if ambiguous, ask 1 question.
2) Retrieve → IdP logs (MFA failures, new devices), SIEM auths, HR status, CMDB criticality.
3) Safety & Policy → enforce policy ATO-RESET-2025 and privacy PII-RED-2.
4) Options → propose 2–3 response plans (e.g., force_reset, session_revoke+monitor).
5) Select → choose plan by risk and user impact; require approval if high-risk.
6) Compose → create ITSM ticket body + user comms template.
7) Audit → output artifacts: sources, approvers, rollback.
User
Suspected ATO on user "{{upn}}".
Output (JSON):
{
"plan": {"steps":["revoke_sessions","force_mfa_reset","notify_user"], "risk":"medium"},
"requires_approval": true,
"approval_request": {"group":"SecOps-OnCall","reason":"MFA bypass signals"},
"ticket_markdown": "string",
"user_email_markdown": "string",
"citations": ["idp:events#{{upn}}","siem:query#last24h","policy:ATO-RESET-2025"],
"audit": {"pii_redactions":["ip","device_id"], "rollback":"restore_sessions_if_false_positive"}
}
Evaluation, Guardrails, and Rollout
Golden Tests & Self-Checks
Maintain fixed fixtures for common alerts (phish, beacon, ransomware) and expected JSON decisions.
Add a self-evaluator prompt that re-scores outputs against policy (e.g., “deny if MAP-like rule violated,” “approval required if account is VIP”).
Safety & Privacy
Think silently: never expose step-by-step reasoning.
Enforce data minimization (only fields needed per task).
Redact PII in narratives (IPs, device IDs) unless required for responders.
Observability
Log: input hashes, tool calls with parameters, citations, final JSON.
Dashboards: precision/recall on triage, containment decision latency, false-isolation rate, RAG citation coverage, approval turnaround.
Rollout
Canary new prompts by queue or alert type; compare MTTA/MTTR and FP/FN deltas.
For action-taking flows, run dry-run mode first; require explicit human approval on high-risk resources.
Minimal Output Schemas (For SOAR Wiring)
// Triage decision
{ "label":"phish|spam|benign|needs_review", "action":"...", "severity":"...", "reason_codes":["..."] }
// Hunt summary
{ "prevalence":{"hosts":0,"first_seen":null}, "affected_hosts":[{"host":"..."}], "recommended_action":"..." }
// Containment plan
{ "steps":["isolate_host","kill_process:pid=..."], "risk_score":0.23, "justification":["..."] }
// Compliance mapping
{ "summary":"...", "control_links":[{"framework":"NIST","control":"SI-4","evidence":"..."}], "gaps":["..."] }
Conclusion
Use CoT for quick, consistent classifications; ToT when the SOC must weigh trade-offs; ReAct to fetch the evidence that matters; RAG when auditors and executives need cited answers; and GSCP only for the few workflows that execute system-changing actions under policy. Together, these patterns make cybersecurity prompts operational, auditable, and safe—without over-relying on any single technique.
Join the conversation! Your thoughts help the community grow.