AI incident response course: a practical guide to investigating and responding with AI

Start with a story and a decision, not an empty prompt

It is Monday, 09:20. An accounts-payable employee at the fictional company Riverton receives a request to change a supplier’s bank details. The message belongs to a familiar conversation. A few minutes later, the supplier calls to dispute it. A security alert also identifies an unfamiliar mailbox rule. Finance wants to know whether to stop the payment. The identity team wants to know whether to disable the account. Your assistant has not seen any of those facts yet.

This is where an investigation begins: a person, a service, an observed event and a decision with consequences. “Analyze this breach” gives an AI model too little context. “Determine whether the disputed payment request is connected to unauthorized mailbox access, using these records, and identify the next evidence needed” gives it a bounded task. For guided practice, explore the AI-Assisted Incident Response & Investigation course, which connects evidence analysis with containment and recovery exercises.

Write the opening brief before collecting a mountain of data. Identify the affected business process, observed account, relevant systems, alert identifier, time window and immediate risk. Name the people authorized to hold the payment or change access. Keep the allegation separate from the observation: an unfamiliar rule is a finding to investigate, not proof that an attacker read every message.

The examples in this article are fictional teaching situations. They show how to reason about evidence, not complete reports from real customer incidents. The method is deliberately portable: use your chosen assistant to organize the investigation, then use sources and observable results to decide what you actually know.

Recognize the incident before choosing the evidence

Companies do not experience one generic category called “a cyberattack.” A stolen session, an exposed application endpoint, an encrypted file server and a compromised build pipeline create different investigative questions. Start with the business outcome at risk. Confidentiality concerns what became accessible or left the organization. Integrity concerns unauthorized changes to data, payments, software or configuration. Availability concerns whether the service can still perform its job. A single intrusion can affect all three.

Then identify plausible mechanisms. Email fraud may involve spoofing, a legitimate supplier’s compromised mailbox or an employee’s stolen session. Identity compromise may persist through an application grant after a password reset. Ransomware may include data theft before encryption. A Linux incident may involve a web application, a service account and scheduled persistence. Cloud and container incidents require attention to control-plane actions, workload identities and the resources those identities reached.

Distinguish attacks assisted by AI from attacks against AI systems. An attacker can use AI to draft convincing messages or automate routine tasks without leaving a unique “AI signature” in the victim’s logs. Conversely, an application agent can be manipulated through untrusted documents, poisoned retrieval content or excessive tool permissions. Investigate the observable behavior and the boundary that failed; avoid asserting which model an attacker used without evidence.

Ask your assistant for a small hypothesis table: possible incident type, supporting observation, competing explanation, decisive next source and immediate protective action. Reject a list that simply repeats every known attack technique. The value lies in choosing what to check next and explaining how each result would change the response.

Choose Claude, Codex/OpenAI or a local model: one route is enough

The investigative method should not depend on owning several AI subscriptions. Claude, Codex/OpenAI and an approved local or company-hosted model can all participate in the same workflow: receive a bounded question, inspect permitted evidence, propose a next step and produce a result that you verify. Their capabilities and interfaces differ. Their outputs still need the same standard of proof.

A browser-based assistant is a valid starting point. Give it selected synthetic records or approved extracts, ask for a read plan, run the proposed query yourself and return the actual result. A command-line agent can help inspect files and write small parsers, but it also introduces execution permissions. Review those permissions, connected services and writable locations before opening the case. Follow the current Codex security guidance or Claude Code permission documentation for the client you use. A sentence saying “read only” is not an operating-system sandbox.

Local models are an option, not a prerequisite. A model such as Qwen3-14B needs evaluation on the actual work: field extraction, timestamp interpretation, contradictory evidence and refusal to invent missing facts. Parameter count alone does not establish investigation quality. Company-hosted services also need authentication, case isolation, retention controls and capacity testing. A local network address does not prove that every processing step stays local.

Choose the route your organization approves. Record the provider, model identifier, date, relevant settings and connected tools. Do not move a sensitive case to another service merely because the first answer was disappointing. Improve the question and test the result before changing the data boundary.

Build a case workspace the assistant cannot quietly rewrite

Preserve originals separately from working material. A useful case folder distinguishes acquisition records, original evidence, derived tables, queries, model conversations and response records. The distinction matters when an assistant produces a helpful-looking CSV: that CSV is a derived artifact, not a replacement for the source that generated it. Retain the query and any transformation rules alongside it.

Create a short evidence register. For each item, record a stable identifier, source system, collection method, collection time, event-time range, timezone, filters and known gaps. A checksum helps detect changed bytes, but it does not prove that the collection was complete or that the source system was trustworthy. Explain both the value and the limit whenever a hash is used to support a finding.

Scope the assistant to a working copy. Exclude unrelated customer folders, production credentials, browser profiles and incident-response secrets. Treat log messages, document text and filenames as untrusted input: a record can contain instructions written by an attacker. The model may read those instructions as evidence, but they must not gain authority over tools or data access.

Give each output a useful name and provenance. For example, a process timeline should identify its input file, parser version, query, timezone assumption and excluded records. Save the original model answer before editing it. Otherwise the next reviewer cannot tell whether a confident claim came from a source, an analyst or a model. Clear case notes are a practical control: they let another responder continue the work without reconstructing your entire conversation.

Use a repeatable AI investigation loop

Start with a plan request, not a request for a final verdict. Ask the assistant for a small number of read-only checks, the source needed for each and the alternative explanation each check would discriminate. A good plan has stopping conditions. It does not demand every tenant log, every endpoint and unrestricted access before answering a narrow question.

Analyze only this case’s supplied records. First propose up to six read-only checks. For each, name the source, relevant fields, time window and competing explanation. Do not execute response actions or invent missing records. After I return the results, separate observations, inferences and unknowns. Cite each material claim to an exact record and field. Finish with the next question most likely to change the response.

Review the plan, execute a permitted check and inspect the actual output. Confirm that a query uses the intended time range, identity field and dataset. Then return that output to the assistant. Ask it to explain what the result supports and what remains unresolved. Keep the query and returned records, rather than saving only the conversational summary.

The second pass should challenge the first. Ask what benign explanation still fits, what evidence contradicts the leading hypothesis and what collection gap could reverse the conclusion. Another model can help, but it is optional; a second answer that relies on the same unsupported assumption is not independent verification. Reproduce the critical join yourself.

Finish each loop with a decision: collect another source, take an authorized protective action, narrow the scope or report a specific uncertainty. This turns prompting into investigative work. Without that decision, even a beautifully formatted answer can become another document nobody uses during the incident.

Investigate email fraud, stolen sessions and application access

Return to Riverton’s disputed payment. Collect the message identifiers, routing and authentication results, mailbox-rule configuration, relevant audit events and the supplier’s account of events. A message passing SPF, DKIM or DMARC answers questions about mail authentication; it does not establish that the business instruction is legitimate. The sender’s real account may be compromised, or a genuine conversation may have been abused.

Ask the assistant to correlate the rule operation with the relevant account, application or session. Check which source identifies the actor and whether that source represents a human sign-in, an administrator action or application access. Compare timestamps carefully. A shared IP address or a familiar device claim may provide context without proving which person operated the session.

Separate access paths before responding. Changing a password, invalidating sessions, removing a forwarding rule and revoking an application grant address different mechanisms. Do not report “account secured” merely because one command succeeded. Preserve the relevant rule and audit evidence, establish who can approve each change, then verify whether the suspect path still works. In a training environment, the failed control should be observable rather than hidden in the instructor’s answer.

For Microsoft 365, Google Workspace or another identity platform, ask the same fundamental questions using the appropriate logs: what identity acted, through which session or application, against which resource, with what permission, and what effect? The interfaces differ; the reasoning transfers. Keep the payment hold and supplier verification in the response plan too. A technically successful account action does not recover money or validate altered bank details.

Analyze suspected malware without letting the model invent execution

A suspicious executable gives you several different kinds of evidence. Static inspection describes the file’s structure, imports, sections, strings and signature information. Endpoint records describe activity observed on a particular host. A sandbox describes a run under its own conditions. Reputation services provide additional observations collected elsewhere. None should silently stand in for the others.

Suppose a file imports a networking function and an endpoint record shows a PowerShell child process. That does not prove that the file stole credentials, encrypted documents or contacted every domain appearing in its strings. Ask the assistant to separate capabilities, observed behavior and hypotheses. Require the exact process relationship and collection source for claims about execution. Missing command-line data should remain missing, not be filled with a familiar attack example.

Use approved analysis tools to generate bounded outputs that the assistant can explain. A static tool such as PEStudio, a capability analysis tool or a disassembler may help answer different questions. Preserve the original output and version. If the model proposes decoding a string, inspect the decoding operation and keep the result as data. Do not execute extracted commands or unknown binaries on an ordinary analyst workstation.

Practical exercises can use inert artifacts, authored sandbox summaries and carefully selected public evidence with clear provenance. A useful task asks the learner to compute the actual sample hash, distinguish it from an illustrative identifier and name the additional evidence needed. Detection suggestions also need testing: a YARA rule matching a common API name may produce many false positives. Ask for positive and benign test samples, then review the results before considering operational use.

Connect logs, MFT records and process identities correctly

AI is useful for explaining a log schema, drafting a parser or finding a candidate sequence. It is less useful when asked to reconstruct an entire intrusion from unlabeled exports. Begin with the source format and collection coverage. A normalized table is easier to read, but may omit fields needed to distinguish two events. Keep a route back to the original records.

For Windows investigations, distinguish a process identifier from a durable process-instance identifier and include the host and time window in joins. Process IDs can be reused. A parent-process relationship needs the appropriate source fields; similar names and nearby timestamps do not establish ancestry. For filesystem analysis, understand the record reference and sequence number before merging apparent matches. A reused MFT entry is not automatically the same file.

Timestamp interpretation deserves its own check. Event time, collection time, filesystem times and displayed local time can answer different questions. Ask the assistant to state which timestamp it used and how it handled timezone offsets, precision and clock differences. Preserve the original value beside the normalized one. Avoid ordering events more precisely than the data allows.

Give the model a concrete task: identify candidate records, show the exact join keys, list unmatched rows and explain a counterexample. Then test the query on a known positive case and a deliberately absent value. A zero result only means the query found nothing in that collected dataset. It cannot establish that an event never occurred on an unmonitored endpoint. The investigation becomes stronger when its boundaries are visible.

Use network evidence to test data-loss hypotheses

An outbound connection is a lead, not a complete exfiltration finding. Establish the source, destination, protocol, timing, owning process where available and the observation point. A firewall log, proxy record and packet capture may each describe different aspects of the same activity. Explain what each source measures before combining their numbers.

Byte accounting is a common trap. A packet capture can include retransmitted payload, while a proxy may report an application-level count. TLS can hide content even when connection metadata is visible. A response body size is not necessarily a count of unique customer records. Ask the assistant to label every quantity with its unit, direction, source and aggregation method.

For a stronger data-loss case, join the application query, generated export, file identifier or hash, delivery record and network observation. If an archive hash appears in a data-loss alert, verify that it identifies the same artifact rather than a similarly named file. State which part of the chain is supported and which part remains hypothetical. An upload request does not always prove that the remote party retained or read the contents.

A useful prompt asks: “Show the supported path from source data to outbound transfer. For every edge, cite the original record and state the missing test.” Follow with a challenge: “What alternative explanation fits the same traffic?” The response may include blocking a destination, suspending an export path or changing application access, but each choice needs an owner and an effect check. Blocking an IP without understanding shared infrastructure can interrupt legitimate traffic while leaving another transfer route open.

Map ATT&CK to evidence rather than decorating the report

MITRE ATT&CK provides a vocabulary for adversary behavior. Use it to organize observations, identify collection needs and communicate scope. It should not turn a vendor alert label into a confirmed sequence of techniques. The model must explain the behavior behind each proposed mapping and cite the source that supports it.

Consider a network logon, a granted administrative-share access check, a newly installed service and a process launched by the service manager. Those observations can support a lateral-movement investigation. They do not by themselves prove credential dumping or how the account’s secret was acquired. Ask for a table containing technique, observed behavior, source IDs, confidence and a next test. Mark unsupported candidates as hypotheses.

Use the current Enterprise ATT&CK technique definitions when checking mappings. Technique names and the framework evolve. For AI-system investigations, current entries such as Indirect Prompt Injection can provide context, alongside MITRE ATLAS. A model’s remembered identifier is not an authoritative reference.

The practical payoff is a better collection and response plan. If the hypothesis involves remote service execution, ask which host and service records would distinguish it from approved administration. If the hypothesis involves application access, inspect the grant and resource operations. A coverage diagram should reveal evidence gaps and questions. Coloring more technique boxes does not make a case more complete, and it should not become a substitute for explaining what happened to the business.

Investigate Linux servers and application authorization failures

A web-server incident crosses several layers. The reverse proxy records the request, the application interprets it, the operating system records execution and a network source may show outbound activity. Correlate request identifiers, worker relationships, paths and process ancestry where they exist. A shell appearing shortly after an upload deserves investigation, but a nearby timestamp alone is not a proven request-to-process link.

Ask the assistant to inspect the application and host evidence together. Did the upload path permit a file type it should reject? Was the file stored where execution was possible? What identity ran the worker? Are related scheduled tasks, service changes or outbound connections present? Group split Linux audit records using their shared event identifiers and preserve the relevant fields. A root-owned file does not identify the person who created it.

API incidents often require a different response from host compromise. A valid user may request another company’s object because the server fails to enforce ownership. Compare the authenticated identity, server-resolved tenant, requested object and authorization decision. Do not accept the tenant value supplied by the client or model as trusted authority.

Use AI to identify related routes and propose negative tests: synchronous exports, background jobs, downloads, cached results and bulk endpoints. Review the code path and execute representative tests in an authorized environment. A search result showing one patched function does not prove every path is fixed. Scope historical exposure using retained request and delivery evidence, and state the gaps. Recovery requires both a corrected boundary and proof that legitimate access still works.

Follow identities and controllers through cloud and container incidents

Cloud investigations should distinguish management actions from access to the underlying data. A permission change, key creation or logging change may explain how access became possible. Resource-level events are needed to establish what was actually read or changed, where that logging exists. Verify collection configuration before interpreting an empty export. The CloudTrail data-event documentation is one example of why source coverage matters.

Think in access paths. If an exposed credential creates another credential, disabling only the original may leave a route open. Ask the assistant to build a graph of principals, credentials, grants, resource operations and subsequent changes. Every edge needs evidence or an explicit hypothesis. Preserve identifiers, issue times and affected resources so that a reviewer can distinguish an executed operation from a denied attempt.

For containers, include the workload controller and node context. Deleting a suspicious pod may simply cause a controller to recreate it. Inspect the service account, admission decision, image digest, security context, host mounts and relevant node observations. A successful API request to list secrets should be interpreted according to the recorded response detail; an audit entry may not include the returned secret values.

Use the assistant to draft a containment plan covering the responsible identity, controller, workload and exposed credentials. Keep destructive actions outside the analysis tool boundary. Test the effect in staging or an approved incident workflow, including whether the workload reappears and whether legitimate service functions survive. Company-hosted AI is subject to these same infrastructure risks; its physical location does not remove the need to investigate identities and configuration.

Separate ransomware response from ordinary service failure

Encryption and destructive activity create urgent decisions, but urgency does not make every symptom diagnostic. Establish which systems show abnormal changes, what process or identity is involved, whether the changes continue and which business services depend on those systems. Preserve volatile or short-lived evidence when it is feasible without allowing preventable harm to continue. The incident commander should make that tradeoff explicit.

Ask the assistant to compare suspicious activity with approved maintenance. An account used by deployment tooling may be legitimate while its use on an unrelated file server is not. A backup dashboard showing green does not prove a successful restore. A command reporting success does not establish that the intended recovery objective was achieved. Include a restore test that measures the actual service outcome.

Availability incidents also arise from broken releases, exhausted connection pools and configuration errors. High request volume may be part of an attack, a legitimate spike or a secondary effect. Compare resource metrics, change history, application errors and network observations. If rollback fixes the service, document that result without automatically claiming malicious intent was disproved.

The response plan needs containment scope, continuity arrangements, evidence preservation, a trusted restoration source, acceptance tests and a rollback threshold. Ask what would happen if the first restore fails or reconnecting the host exposes the same weakness. A useful exercise makes the learner handle that failure. “Backups exist” is a planning statement; “the tested restore meets these security and business checks” is a recovery finding.

Investigate supply-chain compromise and attacks on AI applications

Supply-chain investigations connect software provenance with credential exposure. Compare the approved source, dependency resolution, build environment, generated artifact and deployed digest. A familiar release tag or valid signature does not by itself prove that the artifact contains the intended code. Ask what the signature or attestation actually binds, who controlled that identity and whether the recorded inputs match the release.

Give the assistant lockfile changes, build logs and deployment inventories for a bounded comparison. Do not rerun an unknown build on a privileged workstation merely to reproduce the event. Identify credentials available to the runner and the operations actually performed with them. Track the affected artifact by digest through deployment and distribution. A clean rebuild can produce a different digest; reproducibility depends on the specific build design and evidence.

AI-application incidents add another chain: untrusted input, model proposal, tool authorization and external effect. A malicious instruction inside a retrieved ticket can influence a model without directly changing the trusted user identity. Inspect whether the tool dispatcher enforces that identity independently. Separate an attempted cross-company read that was denied from an outbound action that was allowed.

Analyze the suspicious content in a separate context without the original privileged tools. Review retrieval provenance, tool arguments, authorization logs, destination restrictions and the actual returned or transmitted data. Test a negative case: the malicious text remains visible as data, but cannot authorize an unrelated read or outbound transfer. Fix the boundary that failed, then verify it. Telling the model to ignore bad instructions is not sufficient evidence that the application is secure.

Connect VirusTotal without uploading the incident to the internet

Reputation enrichment can help prioritize investigation, but it is not a verdict on the whole incident. Begin with a known file hash and an approved disclosure policy. An exact-hash lookup is different from uploading the file: it requests an existing report. It still sends information about what you are investigating to another service, so do not treat it as invisible or automatically acceptable.

The VirusTotal file-report endpoint retrieves information for an identifier. A narrowly designed adapter can accept only a validated SHA-256 value, use a fixed destination, read its API key from a protected environment variable, reject redirects and enforce a timeout. Do not let evidence text supply the request URL or put the key in the model’s prompt. Check the organization’s entitlement under VirusTotal’s API use terms before commercial use.

Have the assistant interpret a saved response containing the collection time, report date and relevant results. A missing report is not a clean verdict. Rate limiting should stop or defer the lookup, not cause the agent to rotate keys or retry indefinitely. Several vendor detections are observations to assess; dividing them by the number of engines does not produce a calibrated probability that the incident is malicious.

Do not upload confidential documents, memory dumps, mailbox exports or customer files through an ordinary public workflow to “see what happens.” Those artifacts can contain personal data, secrets and proprietary material. Use an approved private analysis arrangement when necessary. A course can teach the integration with replay fixtures for success, not-found and rate-limit cases, then offer an optional live lookup with the learner’s authorized account.

Make the assistant help you respond, then verify the effect

An investigation that ends with a polished report can still leave the harmful access active. Every important finding should lead to a response question: what should change, who can authorize it, what evidence must be preserved, what business function might be affected and how will we know whether the intervention worked? The assistant can help structure that reasoning without becoming the authority that approves the change.

Keep three states separate: proposed, executed and verified. “Disable the key” is a proposal. An audit record of the disable operation is execution evidence. A controlled test showing the old key rejected, together with a search for replacement credentials, contributes to verification. Do not collapse those states into a single green checkbox. The same distinction applies to mailbox rules, application grants, host isolation and deployment rollback.

Use a response journal with action ID, target, evidence basis, owner, approver, expected effect, execution reference, verification result and rollback condition. Include timing and dependencies. If isolating a host would interrupt a critical payment process, record the continuity arrangement and decision owner. If delay creates greater harm, document why urgent action was authorized and what evidence may be lost.

Recovery needs independent acceptance criteria. Test the original unauthorized path, persistence or alternate access, the repaired control and the business service. Define a limited return-to-service stage and a condition that stops or reverses it. A failed test should produce a clear no-go decision, not a request for the assistant to rewrite the report more confidently.

NIST SP 800-61 Rev. 3 places incident response within broader cybersecurity risk management. In practical terms, feed the incident’s lessons into preparation: logging gaps, unclear ownership, weak recovery tests and excessive agent permissions should become assigned improvements. The case is not finished simply because the visible alert stopped firing.

Write reports with AI and proofread the evidence, not just the prose

Ask for different outputs for different readers. The technical handover needs identifiers, queries, source relationships, uncertainty, actions and remaining checks. The executive update needs business effect, what is controlled, what remains uncertain, the decision required and the next update time. Both must describe the same state of the incident. A short executive summary must not become more certain than its supporting technical record.

Review each material sentence against its evidence. Can you open the cited record? Does the field contain the claimed value? Does that value support the interpretation? Was the source copied from another case? Is a proposed action described as completed? Did the assistant turn “no events in this export” into “no compromise”? These are substantive checks, not proofreading for grammar.

Use a claim ledger: claim, observation or inference, source ID, exact field, limitation and next check. An automated verifier can reject missing identifiers or invented values. It cannot decide every question of meaning. A perfectly valid citation to a sign-in event does not establish that the account owner was the person signing in. Human review remains necessary where the conclusion goes beyond the observed field.

Save the initial answer and the corrected report. Record why a conclusion changed when new evidence arrived. Ask a colleague to reproduce the most consequential finding without reading the whole AI conversation. If they cannot find the query, source or assumption, improve the case notes. A useful report is an operational handover: another responder can see what to do next, what not to assume and which result would change the decision.

What to look for in an AI incident response course

Choose training that makes the learner investigate and respond, rather than collect a library of attractive prompts. The first screen should explain the situation, alert, systems, identities and decision. Downloadable evidence should have provenance and limitations. Exercises should provide runnable steps, a way to inspect actual results and checks that can fail when the analysis or response is wrong.

Look for coverage beyond one vendor. A useful course connects identity, endpoint, filesystem, network, application, cloud and AI-system investigations. It teaches how to ask the next question, not only which menu to open. Provider choice should be explicit: Claude, Codex/OpenAI OR an approved local model, with equivalent evidence and acceptance criteria. Local infrastructure can be an optional workshop, not an obstacle to participating.

The BlueTeam Academy AI incident response course contains 49 English lessons across 16 chapters and 331 narrated slides, with about four hours and 27 minutes of narration plus practical work. It includes thirteen additional synthetic incident cases alongside the Aster/Birch investigation and public evidence workshops. Learners work through source-linked findings, controlled enrichment, response rehearsals and recovery decisions. The course explains where simulations end and production validation would begin.

Teams can use the exercises to review work together: compare two interpretations, reproduce a critical query, challenge a proposed containment action and explain a failed recovery test. A completion certificate records the course’s completion requirements; it is not a guarantee of operational competence or a substitute for supervised practice. Review the full curriculum and practical exercises, then choose a starting point based on your team’s responsibilities and evidence-handling rules.