AI integration

Overview

DFIRe connects to LLM providers via API, supporting OpenAI, Anthropic, 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.

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
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 and the daily brief follow the same path with the context described in the table under Data Sent to the LLM.

1. Case data collection

   DFIRe assembles a structured JSON snapshot of the case. This includes case metadata, timeline events, evidence items, indicators of compromise, notes, CAN report history, and team information. The same data structure is used regardless of which report type is being generated.

2. Data minification

   The raw case JSON is optimized for token efficiency before being sent to the LLM. This post-processing step removes information that does not contribute to report quality while preserving all analytically relevant content. See Data Sent to the LLM for details.

3. Prompt assembly

   The minified case data is inserted into the prompt template using the {case_data} variable. The prompt is assembled from two parts: a system message (sets the output format and analyst role) and a user message (provides content guidance and the case data). For report sections, the {section_title} and {writing_guide} variables are also replaced.

4. LLM request

   The assembled prompt is sent to the configured LLM provider via LiteLLM. Temperature and max token settings from the configuration are applied.

5. 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.

6. 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, the section's prompt, its title and writing guide, and the content of the other sections. The result is appended to the section you are editing.
CAN report	Generate in the CAN report editor	The case snapshot 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 whole chat transcript up to the question, and the question. Anything anyone pasted into the chat 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, severity, status, phase and lead investigator, plus the timeline activity of the last 24 hours and the open and blocked actions. 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 a minified JSON export of the case. The minification step removes noise and internal metadata while retaining everything needed for coherent writing.

What is included

• Case metadata: Case number, title, status, severity, case mode, creation and closure dates, case type
• Team information: Lead investigator and investigator names
• Timeline events: All visible timeline entries (hidden entries are excluded at the query level). This is typically the most important data source for narrative coherence. The is_manual flag is stripped as it is only relevant to the UI.
• Evidence items: Item names, descriptions, types, statuses, notes, and flags (simplified to names only). Internal UUIDs and parent references are removed. Attachment metadata is simplified to filename, category, and description.
• Indicators of compromise: Value, STIX type, classification (benign/suspicious/malicious), confidence level, TLP designation, tags, public notes, and case context notes. Enrichment data is reduced to provider name and finding severity only. Raw enrichment blobs are stripped.
• Case notes: Note content and authorship. The show_on_timeline display preference is stripped.
• Todo checklist: Only items with status in_progress or done. Items that are not started or skipped are excluded.
• CAN report history: The two most recent CAN report versions (older versions are trimmed).
• Existing report content: When generating a report section, the content of other report sections is included so the LLM can avoid repetition and maintain cross-section consistency.
• Chat scrollback: When the assistant answers in Case Chat, the transcript from the start of the conversation up to the question, with redacted messages carrying no text. The server builds it from the database, and it is labelled as untrusted material that the model must never take instructions from.

What is excluded

• Internal UUIDs and database identifiers
• Encryption keys and security tokens
• File contents and attachment binary data (only metadata is sent)
• Raw enrichment data blobs from threat intelligence providers
• Empty or null fields (stripped to save tokens)
• UI-only flags (is_manual, show_on_timeline)
• Hidden timeline events
• Inactive todo items
• Indicator details beyond what is analytically relevant (e.g., internal timestamps, normalization data)

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 and includes the case data. This is where administrators control what the LLM writes about. The user prompt is fully customizable:

• CAN reports: A single prompt template with a {case_data} variable, 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 {case_data}, {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	Minified case data JSON
{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, 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.

1. Enable the provider

   In Settings → AI / LLM, turn on Gemini Enterprise Agent Platform.

2. 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.
3. 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.

4. 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.

5. 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.

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

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.