AI integration - DFIRe documentation

Overview

DFIRe connects to LLM providers via API, supporting OpenAI, Anthropic, Amazon Bedrock, Google Gemini, Gemini Enterprise Agent Platform, Azure OpenAI, and GitHub Models. The same configuration workflow applies regardless of which provider you use.

Key design principles:

On-demand only: AI generation is always triggered by an explicit user action. Nothing reaches the LLM automatically.
Context is rebuilt every time: DFIRe holds no session at the provider. Each request carries the context it needs and nothing is kept between requests. Where a feature has a conversation, DFIRe rebuilds it from its own records and sends it again.
Transparent prompts: Administrators can view and customize every prompt sent to the LLM, including the built-in system instructions.
Output is always a draft: Generated content is presented for review and never skips the workflow that finalizes a record. A generated report section is autosaved into the draft report, like anything else you type there. A CAN report and a codename list wait in the editor until you save them, and the daily brief is never written to a case. An assistant answer is posted into the case chat transcript, where it is marked as the assistant's and stays part of the record.

Optional feature: AI integration requires configuration. If no LLM provider is configured, all AI-related controls are hidden from the interface. DFIRe is fully functional without AI features.

Supported Providers

DFIRe supports the following LLM providers via API:

Provider	Model Format	Notes
OpenAI	`gpt-4o`, `gpt-4`, `o3-mini`	Direct OpenAI API
Anthropic	`anthropic/claude-sonnet-4-20250514`	Claude models via Anthropic API
Amazon Bedrock	`eu.anthropic.claude-sonnet-4-5-20250929-v1:0`	Claude and other models in your own AWS account, authenticated with a Bedrock API key. Requires an AWS region. See Amazon Bedrock
Google Gemini	`gemini/gemini-2.5-pro`	Gemini models via Google AI
Gemini Enterprise Agent Platform	`vertex_ai/gemini-2.5-pro`	Google's Gemini models in your own Google Cloud project, authenticated with a service account instead of an API key. Formerly Vertex AI
Azure OpenAI	`azure/<deployment-name>`	Requires base URL pointing to your Azure endpoint
GitHub Models	`github/<model-name>`	Models available via GitHub Models marketplace

How It Works

When a user asks for a generated report section or CAN report, DFIRe performs the following steps. The assistants follow the same path; the daily brief sends the digest described in the table under Data Sent to the LLM.

Case data collection
DFIRe builds one JSON document from the case: the case fields, team, phases, actions, timeline, notes, evidence items, indicators, reports and compliance timers. Every AI feature reads the same document, and you can fetch it yourself, see Use the snapshot with another assistant.
Data minification
The document is reduced before it is sent, and the rule is that facts stay and copies go. A timeline event that records a note, an item or an action points at that record instead of repeating its text. People are written once, as name and username. Internal bookkeeping is left out. See Data Sent to the LLM for the full list.
Prompt assembly
The prompt has two parts. The system message carries the analyst role, the output format, a legend that says how to read the case document, a warning that the data is untrusted, and the case document itself. The user message carries the content guidance from your prompt template. The case document sits in the system message so the provider can cache it between calls. For report sections, the {section_title} and {writing_guide} variables are replaced in the template; a {case_data} placeholder from an older template is removed.
LLM request
The assembled prompt is sent to the configured LLM provider via LiteLLM. Temperature and max token settings from the configuration are applied.
Output sanitization
The LLM response is sanitized to remove any potentially harmful content (script injection, etc.) before being presented to the user. For CAN reports, the response must also parse as JSON.
User review
The sanitized output is displayed to the user as a draft. The user can accept, edit, or discard the generated content.

Data Sent to the LLM

Understanding what data leaves your environment is critical for security and compliance. Six features call the provider, and they do not all send the same thing.

Feature	Started by	Sent to the provider
Report section	Generate in the report editor	The case snapshot without the investigation report, the section's prompt, its title and writing guide. The report is left out so that the cached snapshot is the same for every section generated in a row. The result is appended to the section you are editing.
CAN report	Generate in the CAN report editor	The case snapshot without earlier CAN reports, and any instructions you typed for that generation. The result fills the three fields in the editor for review.
Case chat assistant	A question in Case Chat	The case snapshot, the last 20 chat messages before the question, and the question. Anything anyone pasted into those messages goes with it.
Slack assistant	`/dfire assistant` in a case channel	The case snapshot, the last 20 messages of the assistant thread, and the question. DFIRe reads the thread back from Slack on every turn.
Daily brief	Generate on the daily dashboard	A digest of the cases you can see. Each entry carries the case number, title, case mode, priority or severity, status, phase and lead investigator, plus its project, its state (new, in progress or resolved), its SLA standing, the timeline activity of the last 24 hours and the open and blocked actions. The digest also counts the open cases by priority or severity, and lists the cases nobody has acknowledged and the incidents with an SLA target at risk or breached. No evidence, indicators or notes.
Case codenames	Generate in Settings → Case Codenames	Only the naming style you wrote. No case data.

The case snapshot is the case export, reduced for a model. Facts stay; what goes is text the document already carries elsewhere, template scaffolding, and timestamps that change on every save. A fact the snapshot lacks is a question the assistant cannot answer, so the list of what is included is long on purpose.

What is included

Case: Number, title, description, status, mode, severity, incident category, outcome, case type, project, external ID, custom attributes, the case notes field, the creation, closure, reopening, phase change and incident timestamps, who created the case, who acknowledged it and when, and the SLA severity, pauses and breach time.
Team: Lead investigator, investigators and viewers, each as name and username.
Phases: The phase sequence, listed once, and the current phase.
Actions: Every action in every status, grouped by phase: description, details, status, assignee, what blocks it, who started and completed it and when, the action note, runbook progress step by step, and the decisions taken in a workflow.
Timeline: Every visible event with its time, type, actor and phase. An event that records a note, an evidence item, a file, the start or completion of an action, a timer or an indicator points at that record by reference instead of repeating its text. Events that hold history the record does not, such as an action being blocked and unblocked, an earlier action note or a workflow's questions and answers, keep their full text. So do manual events, adversary activity events and events whose record was deleted.
Notes: Case notes and evidence notes with their text, author and time, and who last edited them.
Evidence items: Name, type, status, location, owner, primary user, collector, parent item, flags, custom attributes, runbook progress, and the chain of custody as who handed the item to whom, where, why and when.
Attachments: Metadata only: id, filename, MIME type, size, category, description, uploader and upload time. The SHA-256 hash is included for the assistants and left out when generating a report, where the renderer resolves hash macros itself. The item UUIDs and attachment ids stay in the snapshot so that a generated section can insert reference macros.
Indicators: Value, STIX type, classification, confidence, TLP, tags, public notes, case context, source, first and last seen, validity, whether the indicator is published or revoked, who added it, and each enrichment's provider and finding.
CAN reports: The latest version, for the assistants and for report sections. None when generating a CAN report.
Investigation report: The editable sections' titles, text, QA status, who marked each ready and signed it off, and who last edited it, for the assistants and for CAN reports. Left out when generating a section.
Chain of custody verification: For each evidence item with a custody record, whether the hash chain still verifies, and where it breaks if not.
Integrations: The linked Jira issues (key, URL, type, status, assignee, sync state) and the case's chat channel.
Compliance timers: Name, framework, duration, start and completion, who started and completed them, and whether they breached.
Chat scrollback: When the assistant answers in Case Chat, the last 20 messages before the question, with redacted messages carrying no text. The block says how many earlier messages it left out. The server builds it from the database, and it is labelled as untrusted material that the model must never take instructions from. Chat is conversation rather than record, so it is not part of the case snapshot: report generation never sees it, and the assistant sees only this window.

What is excluded

File contents, thumbnails, storage locations and encryption material
Raw enrichment data from threat intelligence providers
Report templates and generated sections such as the title page and the table of contents
Chain of custody hashes and the frozen party records that reproduce them
Timestamps that move on every save, such as a case's last update and an open case's running duration
CAN report timeline events; the CAN reports section carries the same facts
Hidden timeline events
Empty fields

Data sensitivity: The case data snapshot includes case content, investigator names, IOC values, and notes. Make sure your LLM provider's data handling terms are compatible with the sensitivity level of your investigation data. TLP designations on indicators are preserved in the data sent to the LLM.

Use the snapshot with another assistant

The snapshot the built-in assistant reads is available to you as plain text. Open the case and select Copy for AI on the Case tab, beside the Case Overview heading. The document lands on the clipboard, ready to paste into an assistant of your own.

The text opens with a short legend that tells the model what the document is and how to read it, followed by the warning that the data is untrusted, then the JSON. The built-in assistant receives the same legend and warning in its system message.

The same document is served at GET /api/cases/{id}/export/assistant/ as text/plain, so a script can fetch it with a user API key. Add ?legend=0 to receive the JSON alone. Both need the permission to export cases. The chat is not in the document; the JSON export carries it for a reader who may see it. Each fetch is recorded in the audit log as an export. The MCP tool get_case_full_dump returns the same text, with the legend and the warning.

The document contains everything listed under What is included. Check the data handling terms of the assistant you paste it into.

Prompt Architecture

DFIRe uses a two-part prompt structure for all AI generation requests. Administrators have full visibility into both parts.

System message

The system message is a built-in instruction that sets the LLM's role and output format. It is read-only and cannot be modified by users. Its purpose is to make sure the LLM responds in the expected format (e.g., valid JSON for CAN reports, Markdown for report sections) and behaves as a forensic analyst.

The system message can be viewed in the Settings UI by expanding the "Built-in System Instructions" panel under the CAN Report AI Prompt section.

User prompt

The user prompt provides content guidance. This is where administrators control what the LLM writes about. The case data is not part of it; it travels in the system message. The user prompt is fully customizable:

CAN reports: A single prompt template, configured under Settings → Reporting → CAN Report AI Prompt. Leave empty to use the built-in default.
Report sections: Each section template has its own AI prompt with {section_title} and {writing_guide} variables. A default prompt can be loaded using the "Use Default Prompt" button and then customized per section.

Additional instructions

When generating a CAN report, users can provide free-text additional instructions that are appended to the prompt. This allows per-generation guidance without changing the template (e.g., "Focus on the network intrusion timeline" or "Keep the report concise for executive stakeholders").

Template variables

Variable	Available In	Replaced With
`{case_data}`	CAN prompts, section prompts	Nothing. The placeholder is removed from older templates; the case data is in the system message.
`{section_title}`	Section prompts only	Name of the section being generated (e.g., "Executive Summary")
`{writing_guide}`	Section prompts only	The section's writing guide text, if configured

Configuration

LLM integration is configured in Settings → AI / LLM (requires superuser access).

LLM Provider Settings

Setting	Description
Provider	The provider this configuration calls: OpenAI, Anthropic, Amazon Bedrock, Google Gemini, Gemini Enterprise Agent Platform, Azure OpenAI or GitHub Models
Model	Model identifier string passed to LiteLLM (e.g., `gpt-4o`, `azure/my-deployment`)
API Key	Authentication credential for the provider. Stored encrypted, never displayed after saving.
Base URL	Optional custom API endpoint for Azure deployments or self-hosted models
Temperature	Controls response randomness, from 0.0 (deterministic) to 2.0 (creative). Leave it empty to use the model's own default.
Max Tokens	A ceiling on the length of each response. Leave it empty to use the model's own default.

After entering your credentials, use the Test Connection button to verify the configuration. A successful test confirms that DFIRe can reach the provider and authenticate.

Gemini Enterprise Agent Platform

Agent Platform runs Gemini models inside your own Google Cloud project, so it authenticates with a Google service account rather than an API key. Google renamed this product from Vertex AI in 2026; the console, the IAM roles and the documentation are still catching up, so both names are in circulation. Before configuring it in DFIRe, do three things in the Google Cloud project you want the models billed to:

Enable the API. Search the API library for aiplatform.googleapis.com. Google enables a group of supporting APIs alongside it, which is expected.
Create a service account and grant it roles/aiplatform.user, or an equivalent custom role. Search the role picker by that identifier rather than by name. Google renamed Vertex AI to Gemini Enterprise Agent Platform in 2026, so the same role now appears as Agent Platform user in the console and as Vertex AI User in older documentation. Avoid the administrator role, which can also create and delete resources, and the viewer role, which cannot call a model at all.
Create a JSON key on that service account and download it.

Billing must be enabled on the project. Give the project a few minutes to settle before configuring DFIRe. A newly enabled API and a newly granted role both take time to propagate. Until they do, Google answers with a permission error that looks like a misconfiguration rather than a delay.

Enable the provider
In Settings → AI / LLM, turn on Gemini Enterprise Agent Platform.
Enter the model and location
Set Model to the model ID exactly as Agent Platform lists it, for example gemini-2.5-pro. Set Location to the location your models are served from, such as global or europe-north1.

Take the model ID from the Available models link beside the field, which points at the Agent Platform model list. Do not take it from Google's consumer Gemini site: the two catalogues differ, and a model announced there may not be offered on Agent Platform at all.

Choose a Gemini model. DFIRe supports Google's Gemini models on Agent Platform, and any current Gemini model is suitable for the work DFIRe asks of it.
If a model is refused, suspect timing before configuration. Google reports several unrelated conditions as the same permission error, naming aiplatform.endpoints.predict and the full model path and ending with or it may not exist. It reads like a broken service account even when the service account is fine. Work through it in this order:
1. Wait and retry. If you enabled the API or granted the role in the last few minutes, that is the most likely cause, and nothing needs changing. Features can also start working one at a time as the change propagates, so a connection test that succeeds while another feature still fails is consistent with this rather than evidence against it.
2. Check the model against the Agent Platform catalogue, not Google's consumer Gemini site. The two differ.
3. Try a specific location such as us-central1 or europe-north1. A model can be offered on Agent Platform without being served at every location, including global.
4. Then revisit the role and the project on the service account.
Set the project, or leave it empty
Leave Google Cloud project empty to use the project the key file belongs to. Set it only when the service account is granted access to a different project.
Upload the service account key
Choose the JSON key file you downloaded from Google Cloud. It is checked when you test the connection or save, and anything that is not a Google service-account key is rejected.
Test, then save
Test Connection uses the file you just selected, so you can prove a key works before storing it. A failed test leaves the previously stored key in place.

The test sends a real request to the provider you are configuring, using the model, location and project on screen, and reports the exact model it reached. It is not a reachability check and it never falls back to another provider, so a model that the test accepts is one your AI features can use. Editing any of those fields clears the result, because a verdict only describes the settings it was run against.

Once a key is stored, the card shows the service account's email address and its home project. Choosing another file replaces the stored key on the next save. Remove key deletes DFIRe's copy and turns the provider off. It does not disable or delete the key in Google Cloud, which you do from the Google Cloud console.

Supported models

DFIRe supports Google's Gemini models on Agent Platform. Third-party models offered in Model Garden, including Anthropic Claude, Mistral and Meta Llama, cannot be used through this provider, and support for them is not currently planned.

This is not a practical limitation for how DFIRe uses a language model. AI features take structured case data and express it as readable prose: report drafts, case summaries, and answers about the case in front of you. DFIRe does not use the model for research or for anything outside the scope of the case. Every current Gemini model does this well, and an account with access to Agent Platform has access to them.

Google Gemini and Gemini Enterprise Agent Platform are separate providers with separate configuration. Adding one does not change the other, and the Active LLM API setting decides which one DFIRe uses.

The service account is shared by the whole installation: every DFIRe user's AI request reaches Google as that one identity, so Google Cloud's own audit log attributes all of them to it. DFIRe's own audit log records the user who started each AI request on a case. Use a service account created for DFIRe alone rather than one shared with other systems. Keep its access to the project you intend and rotate its key on your own schedule. DFIRe does not create, rotate or expire keys in Google Cloud.

Amazon Bedrock

Amazon Bedrock runs Claude and other models in your own AWS account. DFIRe connects to it with a Bedrock API key. Ask your AWS administrator for the following:

A long-term Bedrock API key. The administrator generates it in the Amazon Bedrock console under API keys. AWS binds the key to an IAM user, and the administrator can set an expiry for it. Choose an expiry that matches your rotation policy.
Permission to call the model. The IAM user of the key needs bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream. Grant both on the models or inference profiles that DFIRe calls. The case chat assistant streams its answers, so it needs the second permission.
The region and the model ID. The administrator must enable the model in that region.

Enable the provider
In Settings → AI / LLM, turn on Amazon Bedrock.
Enter the model
Set Model to the model ID or inference-profile ID exactly as Bedrock lists it. For Claude, use the inference-profile ID, for example eu.anthropic.claude-sonnet-4-5-20250929-v1:0. In regions such as eu-north-1, Bedrock serves Claude through cross-region inference profiles. It refuses the plain foundation-model ID. The Available models link beside the field opens the AWS list of inference profiles.
Set the region
Set Region to the AWS region code that serves your models, for example eu-north-1. The region is required.
Enter the API key
Paste the key into API key. DFIRe stores it encrypted and never shows it again. After you save, the field shows a masked form of the stored key.
Test, then save
Test connection sends a real request with the model, region and key on screen. This includes a key that you typed but did not save yet. If the test fails, the message names the likely cause, for example a rejected key or a missing permission. When the test succeeds, click Save.

To replace the key, type a new one and save. Clear removes the stored key when you save. It does not revoke the key in AWS. Do that in the AWS console.

Anthropic and Amazon Bedrock are separate providers with separate configuration. The Active LLM API setting decides which one DFIRe uses.

The whole installation uses one key. Every AI request from every DFIRe user reaches AWS as the IAM user of the key. DFIRe's own audit log records the user who started each AI request on a case. Use a key made for DFIRe alone. DFIRe does not create, rotate or expire keys in AWS.

Daily token budget

Settings → AI / LLM → Daily token budget limits what AI features can spend in one day. The default is 250,000 tokens. The count covers every provider together, adds up the prompt and the response of each request, and returns to zero at midnight UTC. Beside the field. DFIRe shows the tokens spent today and the time left until the count returns to zero.

When the budget is spent, AI features stop until the next day and say so. A request that started before the limit was reached still finishes, so a busy day can end slightly above the budget.

Two settings decide how far this goes:

Enable budget turns the limit on and off. With it off, AI features spend whatever the work requires. Controlling the cost is then up to you and your provider's own limits.
A budget of zero stops every AI request, including Test Connection, so raise it before you configure a provider.

The budget is separate from the per-provider totals under Token usage. Reset counters clears those totals and does not change the day's spend or the budget.

Prompt Settings

AI prompt templates are configured under Settings → Reporting:

CAN Report AI Prompt: At the bottom of the Reporting settings page. View the built-in system message, edit the user prompt, or reset to the default.
Section AI Prompts: Expand any editable section template card and enable AI generation to configure its prompt. Use the "Use Default Prompt" button to start from the built-in default.

See Reporting configuration for the full list of section template settings.

Security and Privacy

Credential handling

DFIRe stores API keys with Fernet encryption (AES-128-CBC) via EncryptedCharField
Keys are never returned in API responses after being saved (write-only field)
Google service-account key files are encrypted in full with the same key. The API returns only whether a key is stored, the service account's email address, and its project; . The key file itself is never returned, logged or written to disk
The encryption key (CREDENTIAL_ENCRYPTION_KEY) is separate from the Django SECRET_KEY

Access control

LLM configuration requires superuser access
Report generation requires case team membership (same permissions as editing the report)
Reading Case Chat requires the Case Chat view permission and access to the case under the normal visibility rules. Asking the assistant additionally requires permission to write chat and edit access to the case, so a closed or archived case is read-only
AI prompt template management requires superuser access
The LLM status check (used to show/hide AI buttons) is available to all authenticated users

Output safety

All LLM output is sanitized through the same Markdown sanitizer used for user-written content, preventing stored XSS
A CAN report response must parse as JSON, or the generation fails. DFIRe then reads the conditions, actions and needs fields from it, treats a missing field as empty and ignores anything else the model returned
Generated content is presented as a draft for human review before being saved

Audit trail

All generation requests are logged in the audit system with the requesting user and case context
The LLM provider and model used are recorded with each generation event

Important: DFIRe sends case data to an external LLM provider. Your organization's information security policies and any applicable regulations (GDPR, data residency requirements, client confidentiality agreements) should be reviewed before enabling this feature. Consider using a self-hosted model or a provider with appropriate data processing agreements in place.

Limitations

Report generation has no memory: Each report section, CAN report, daily brief and codename request stands alone, and the model is told nothing about earlier ones. The case chat and Slack assistants do follow a conversation, because DFIRe resends it with every question.
Token limits: Very large cases may exceed the LLM's context window. The minification pipeline reduces this risk, but cases with hundreds of evidence items or extensive timelines may need to be summarized manually.
Output quality varies: LLM-generated content should always be reviewed by a qualified analyst. The output may contain inaccuracies, miss important context, or draw incorrect conclusions.
Generated sections cannot use AI: Auto-generated sections (Title Page, Table of Contents, Evidence Inventory, etc.) are populated from structured data and do not support AI generation.
Streaming only in case chat: The case chat assistant streams its answer as the model writes it. Report sections, CAN reports, the daily brief and codenames arrive as one block when the model finishes, which can take several seconds.