AI can make a security analyst faster at the parts of the job that involve sorting, comparing, and explaining. It cannot decide that a host is safe, that an incident is contained, or that an alert is a false positive. The useful pattern is simple: give the model sanitized evidence, make it distinguish facts from hypotheses, and keep consequential actions behind human approval.
This guide contains 15 prompts for that pattern. Replace every bracketed field, remove sensitive data, and use only an AI environment approved by your organization. For broader controls, start with AI prompt security and the complete guide to prompt-injection defense.
Before You Paste Security Data Into AI
Use four gates before any prompt:
- Minimize: include only the fields needed to answer the question.
- Sanitize: remove secrets, tokens, personal data, customer names, internal addresses, and unnecessary payloads.
- Label: assign evidence IDs such as
E1,E2, andE3so conclusions can cite their source. - Constrain: tell the model not to execute actions, invent missing facts, or treat a hypothesis as confirmed.
A model can still be wrong after all four. Its output is an analyst draft, not evidence.
Alert Triage Prompts
1. Build a first-pass alert assessment
Act as a SOC analyst preparing a first-pass assessment. Review the sanitized
alert evidence below.
For each conclusion, cite its evidence ID. Separate:
1. Confirmed observations
2. Plausible hypotheses
3. Missing information
4. Next read-only checks, ordered by information value
Do not call the alert benign or malicious. Do not invent events, users,
timestamps, or indicators.
Alert context: [RULE, ASSET ROLE, SEVERITY]
Evidence: [E1..., E2..., E3...]
Environment notes: [RELEVANT BASELINE]
2. Compare activity with the baseline
Compare the observed activity with the stated baseline. Create a table with:
behavior, observed value, expected value, degree of deviation, evidence ID,
and a question that would resolve the uncertainty. Do not infer a baseline
that is not provided.
Observed evidence: [SANITIZED EVENTS]
Known baseline: [NORMAL HOURS, PROCESSES, VOLUMES, LOCATIONS]
3. Deduplicate an alert cluster
Group these alerts into likely shared events using only matching entities,
time proximity, and causal sequence. Explain each grouping rule. Preserve
outliers in a separate list; never force an alert into a cluster.
Alerts: [SANITIZED ALERT LIST]
Time window: [WINDOW]
4. Create an escalation brief
Turn the evidence into a five-minute escalation brief for a tier-2 analyst.
Include: why this needs review, confirmed facts with evidence IDs, open
hypotheses, affected assets, checks already completed, and the single most
useful next check. Keep it under 250 words.
Case notes: [NOTES]
Incident Response Prompts
5. Build an evidence-bound timeline
Create a chronological incident timeline. Every row must contain timestamp,
event, entity, evidence ID, and confidence. Preserve timezone labels. If two
sources conflict, show both; do not choose one silently. List timeline gaps
after the table.
Evidence bundle: [SANITIZED EVIDENCE WITH IDS]
6. Generate containment options
Propose containment options for the scenario below. For each option show:
security benefit, operational impact, reversibility, prerequisites, evidence
that would justify it, and required approver. Do not recommend execution and
do not provide offensive instructions.
Confirmed facts: [FACTS]
Critical business constraints: [CONSTRAINTS]
Approved response playbook excerpts: [POLICY]
7. Draft an incident handoff
Draft a shift handoff that another analyst can continue without rereading the
entire case. Include current status, confirmed scope, unresolved questions,
actions taken with ticket IDs, actions awaiting approval, monitoring in place,
and the next checkpoint. Mark assumptions explicitly.
Case record: [REDACTED RECORD]
8. Run a blameless after-action review
Facilitate a blameless incident review from these verified notes. Organize the
output into: what happened, what worked, where detection or response slowed,
contributing system conditions, corrective actions, owner, due date, and a
measurable completion signal. Do not invent root causes or assign individual
blame.
Verified notes: [NOTES]
Detection Engineering Prompts
9. Turn a threat hypothesis into a detection plan
Convert this threat hypothesis into a detection plan. Identify required data
sources, observable behaviors, candidate joins, likely false positives,
coverage gaps, and a test dataset. Keep vendor-specific query syntax out unless
the schema is supplied.
Threat hypothesis: [HYPOTHESIS]
Available telemetry: [SOURCES AND RETENTION]
Known exclusions: [EXCLUSIONS]
10. Review a detection rule
Review this detection rule for logic gaps. Check field assumptions, time
windows, thresholds, joins, null handling, evasion opportunities, duplicate
alerts, and test coverage. Return findings by severity and quote the exact
rule fragment involved. Do not rewrite the rule until after the review.
Schema: [FIELD DEFINITIONS]
Rule: [RULE]
Tests: [POSITIVE AND NEGATIVE CASES]
11. Design false-positive analysis
Design a false-positive review for this rule. Define the sample, fields to
capture, analyst labels, disagreement process, segmentation dimensions, and
the metric that would justify tuning. Do not propose suppressing activity
solely because it is frequent.
Rule purpose: [PURPOSE]
Recent alert summary: [AGGREGATE DATA]
Risk and Communication Prompts
12. Convert a finding into a risk statement
Rewrite this technical finding as a risk statement with condition, threat,
business consequence, existing controls, uncertainty, and recommended owner.
Use the supplied scoring method; do not invent probability or financial loss.
Finding: [VERIFIED FINDING]
Scoring method: [METHOD]
Business context: [CONTEXT]
13. Prepare an executive incident update
Write an executive update in plain language. Include what is known, business
services affected, what remains uncertain, actions completed, decisions needed,
and next update time. Avoid technical indicators unless they change a decision.
Keep it under 180 words and do not speculate.
Verified status: [STATUS]
14. Map evidence to a control
Assess the evidence against this specific control statement. Return: control
requirement, evidence that supports it, evidence gaps, exceptions, and a
reviewer question. Do not declare compliance; prepare the review record.
Control: [CONTROL TEXT]
Evidence: [SANITIZED EVIDENCE]
15. Create a tabletop scenario
Create a 60-minute defensive tabletop exercise for [TEAM] around [SCENARIO].
Provide four timed injects, the decision each tests, information available at
that moment, facilitator questions, and observable success criteria. Exclude
exploit steps and keep all systems fictional.
A Verification Loop for Every Output
Before using an AI-assisted security artifact, check five things:
- Can every factual statement be traced to evidence?
- Are hypotheses visibly labeled?
- Did the model invent a baseline, timestamp, user, indicator, or policy?
- Does every proposed action name an approver and operational impact?
- Has a qualified analyst checked the source systems?
This is the security version of prompt evaluation: define the failure modes before trusting the output. The win is not replacing judgment. It is giving judgment a cleaner, faster evidence package.
