AI features

All AI features need Enable AI investigation turned on and a saved key for the selected provider (see AI overview). There are two exceptions:

• You can reopen saved alert explanations with AI switched off.
• Manual web research from a case needs only Enable public web research. It does not need an AI key.

Feature	Where	Trigger	Model requests	Can change state?
Case investigation	Case → AI tab	Automatic (Medium+) or manual	Multi-round tool loop	Yes: case verdict, containment, pending exclusions
Explain this alert	Alert detail	Manual	1	No
Ask AI to draft (exclusion)	False-positive / Tune this rule dialog	Manual	1	No (you preview and save)
Describe what to find (Hunt)	Hunt	Manual	1	No (you run it)
Draft as rule	Hunt	Manual	1	No (you test and save)
Public web research	Case → AI tab, and investigator tools	Manual, or by the investigator	0 (no model)	No

The deterministic case summary is not AI. Neither are reputation enrichment (External enrichment) and the host-prevalence tags. AI features read them as input, and the investigator can request enrichment itself with its enrich tool.

---

Case investigation

The investigator reviews one case and gives a verdict on its alerts. It runs as a bounded conversation: the model calls FreeDR tools, reads their results and finally calls finish.

When it runs

Automatic investigations start only for cases that meet all of these:

• the case is open (status open or in progress);
• the case has at least one alert;
• the case severity is Medium, High or Critical;
• no run is active on the case;
• no run has already been attempted on the current evidence. The evidence is identified by the case's alerts, their trigger events and the attached events.

Cases are picked in this order:

1. Cases never investigated before. These go ahead of re-runs, so busy severe cases cannot starve the queue.
2. Then by severity.
3. Then by most recently updated.

Up to 3 runs go at once.

• Re-runs. When a case's evidence materially changes (new alerts or attached events), it qualifies again. The AI's own findings and ordinary note or title edits do not trigger a new paid run.
• Low and Informational cases are never investigated automatically. Start them by hand.
• Manual start. On the case's AI tab, enter an Investigation question and choose Start investigation. Manual starts work for any case and severity. The default question is "Investigate this case, explain the evidence and gaps, and draft justified remediation." The question can be up to 2,048 bytes.
• Follow-ups. Choose Continue this session to ask a follow-up. The new run shares the session and can read the earlier run's sources with read_observation. Choose New investigation session to start fresh.
• Stop. Stop investigation cancels the run. Completed observations stay visible. A stopped or interrupted run stays incomplete or cancelled. It is never replayed automatically.

What the model receives

The model starts with the case summary. This is FreeDR's deterministic summary, the same one shown in the case view. It contains:

• the case's alerts, grouped by rule and triggering command;
• for each group:
  • the trigger event with all named fields;
  • the acting process and how it was identified;
  • the process chain (process, parent, grandparent) and children;
  • the files, registry values, script blocks and network/DNS records near the trigger;
  • decoded -EncodedCommand text;
  • related and rare nearby events;
  • file history, signer and host-prevalence flags;
• each rule's verdict questions (investigation_playbook);
• enrichment, responses and related cases.

The system prompt includes an evidence manual. It lists the sources, columns and Event Log types. The prompt also tells the model to:

• answer each rule's verdict questions;
• scope every query to the alert's own process, file, key or destination, 15 minutes either side of the trigger by default;
• treat FreeDR's own process and its connections to the AI and research hosts as self, not evidence.

Investigator tools

The model can call only these tools. FreeDR checks every argument and caps it at 16 KiB.

Tool	What it does	Limits
case_context	Reads paginated case material: case, alerts (with the exclusion builder's trigger_clauses), events, findings, notes, enrichment, responses.	1–20 items per page; 10 s read
query	Runs one read-only DuckDB SELECT over events or event_log. FreeDR checks it with the same validator as the Hunt direct SQL.	200 rows by default, or the query's own outer LIMIT; long text cells are cut; 30 s
investigate_step	Inspects the alert's current live state: current_process, current_file or acquire_artifact. Read-only.	10 s to resolve
enrich	Requests case enrichment for the case's alert-trigger or attached events. Kinds: file_hash, file_signature, hash_reputation, ip_reputation, domain_reputation. Results appear in case_context enrichment.	Uses your configured reputation providers and their quotas (External enrichment)
inspect_response	Checks exact response targets from one retained citation (alert, event or enrichment). Returns numbered candidates. It never runs anything.	Candidates from enrichment citations always stay a draft
propose_exclusion	Files a pending exclusion for an alert of this case (see below).	At most 16 pending per rule
read_observation	Pages a saved tool result, the prior report or the prior context from this investigation session.	3,000 bytes per page
finish	Submits the assessment (unknown, suspicious, malicious, benign), reason, confidence basis, gaps, cited findings and optional ordered candidate_ids.	Every finding must cite at least one retained event_id
web_search	Public search. Offered only when web research is enabled.	3 per run, 5 results per query
read_public_page	Reads a public text or HTML page. Offered only when web research is enabled.	3 per run, 256 KiB of text

The investigator has no tool that edits a case, runs a shell command, approves an exclusion, changes rules or settings, or contacts a destination other than its provider and the research service.

Long investigations

• Tool results older than the last 4 rounds are sent again only as short digests: status, row count, columns, first rows and event IDs. The full result stays readable with read_observation.
• A conversation can grow past a 250,000-token window. When it does, a separate tool-less request folds the oldest rounds into an investigation summary. That request counts against the same run.

Verdicts and auto-resolution

The run publishes its report only if nobody changed the case while it ran. If you edited the case meanwhile, your change wins and the case shows "Report retained; findings were not published to current case material."

Assessment	Result
Benign	The case is resolved with outcome expected_activity and the conclusion "AI investigation found this activity benign: ". Each alert that is not resolved gets resolved / expected-activity triage. This applies at every severity, including High and Critical.
Suspicious / malicious, containment fully succeeded	The case is resolved with outcome true_positive and closure reason threat. The conclusion names the actions and the response job. Open alerts are resolved as true positives.
Suspicious / malicious, no containment or anything not fully verified	The case moves to in progress with an ai:<run_id> finding that says why. Alerts keep their triage, so the tray and Overview still show them.
Unknown	Left to you, with the gaps listed.
Run incomplete, cancelled or not published	Nothing changes. The AI never sets "investigating".

Some things are kept whatever the verdict:

• Alerts you resolved yourself keep your verdict.
• Alerts whose triage changed during the run keep that triage.
• Every AI conclusion carries ai:<run_id> provenance and is written to the case and story audit.
• A resolved case can be reopened.

Accepted risk

Telemetry made to mislead the model, such as prompt injection hidden in a command line or script, could make it call a real alert benign and resolve it. Resolved alerts stay listed under Resolved and in the case history.

Containment by the AI

This depends on Let AI contain threats it finds (off by default; turn it on in Settings or setup). FreeDR reads the switch when the run starts and again before it submits. The AI acts only if both reads allow it.

What it can run. For a suspicious or malicious verdict, FreeDR runs the candidate_ids the model sends to finish. They run as one response job, in order, through the same case response service the console uses. Only four actions are allowed:

• terminate processes
• quarantine a file. Quarantine is reversible. Permanent deletion is never an AI action.
• remediate (disable) persistence
• block traffic

What always stays with you. These never run from the AI. They stay in the report's Review response draft for you to submit:

• host isolation
• permanent deletion
• any restore or release
• targets that come from enrichment

Safeguards.

• Every target must come from server-side inspection of a retained alert or event of the case.
• The response service binds each target to its evidence again, runs its own Windows preflight and protections, and audits every step. It can refuse. Protected targets include FreeDR's own process, critical and protected processes, and protected services.
• AI jobs carry the purpose AI investigator (run <id>): …. They are tied to the exact case revision. If the case changes, the job is refused at creation, or cancelled before its next step (case_changed audit). Console jobs are not restricted this way.
• If you stop the run, the queued or running job is cancelled. After a restart, queued AI jobs are cancelled (investigation_interrupted).

Where to see it. The AI tab shows Response actions run by AI. The case's Response tab shows the job and each step's outcome.

Switch off. The plan is only a draft. The model is told it cannot execute actions, and it proposes candidates only for malicious verdicts.

See Response actions for how jobs run and how to undo them. Quarantine, persistence and traffic blocks can be undone. A terminated process cannot be undone.

Pending exclusions (owner approval only)

The model can use propose_exclusion only for an alert of its own case that it judged a false positive or benign. FreeDR then runs these checks in order:

1. Validation. The predicate is checked like a console exclusion:
2. at most 1,024 bytes;
3. a reason of 1–4,096 bytes;
4. valid against the rule's source;
5. it must match the alert's own trigger.
6. Writer anchor. For registry, file and image-load triggers the predicate must pin the writing program (actor_image_path). For process starts it must pin parent_image_path. A predicate that still matches when the writer is swapped for a decoy is refused.
7. Duplicate check. A predicate that adds nothing beyond the rule's pending proposals is refused as redundant. The same predicate again returns already_filed.
8. Preview. FreeDR runs the preview counts: matches over 7 days and recent alerts covered.

A valid proposal is stored pending and suppresses nothing. It shows on Overview, on the case and on the rule detail. Only you can approve it, with Approve in the console. The approve endpoint is POST /api/v1/detections/rules/{rule_id}/user-exclusions/{exclusion_id}/approve. No AI code calls it. You can also Reject it.

Run states and errors

Each run has one of these states: running, completed, incomplete or cancelled.

The run detail explains stops, for example:

• "AI provider switched off or key unavailable"
• "AI provider or model changed; start a follow-up to continue"
• "Token budget reached; continue with a follow-up when ready"
• "Stopped by user or service shutdown"
• provider timeouts or HTTP errors with retry countdowns

A reply cut off at the output limit, or one that cannot be parsed twice, is answered with one corrective request. That request asks for a shorter reply or an immediate finish.

---

Explain this alert

A plain-language explanation of one alert, from the alert detail. No case is needed.

What the model receives. An alert brief built from the case-summary builders:

• the rule text and playbook;
• the trigger with all named fields;
• the acting process and its chain;
• nearby, related and rare events;
• file history with host flags and tags;
• enrichment, if the alert's case has any.

The brief is at most 40 KiB.

What you get:

• a summary;
• what happened;
• why it fired;
• a concern level: likely_benign, unclear, suspicious or likely_malicious;
• confidence with its reason;
• up to six next steps, least disruptive first.

Guards:

• FreeDR's own severity and host flags are shown beside the AI verdict under "AI-generated. It may be wrong."
• Risk flags limit the verdict. If the brief has any of these flags, FreeDR changes likely_benign to unclear and high confidence to medium, each with a visible note:
  • lolbas
  • remote_access_tool
  • new_to_host
  • new_signer
• Unsafe next steps are removed, with a note. These are steps that contain links or shell commands, or that suggest disabling, stopping or excluding Defender, FreeDR, the firewall or similar protection.

Caching. FreeDR saves the newest completed explanation for each alert. Reopening it costs nothing and works with AI off. A change in evidence, case, enrichment or prompt version means a fresh request. Regenerate asks again, and the new reply becomes the saved one. Explanation requests for one alert run one at a time, so concurrent clicks pay once.

---

Ask AI to draft an exclusion

This is in the false-positive / Tune this rule dialog.

What the model receives. The alert brief (at most 16 KiB) and the names, labels and values of the fields the exclusion builder offers. It does not receive SQL.

What it returns. Field names and a short rationale only. It must keep every field the builder selects by default. It may only add fields.

Rejected replies. FreeDR rejects a reply that has any of these:

• a name the builder did not offer;
• a repeated name;
• an extra key such as predicate or sql;
• a missing default field.

What happens next. The console ticks the chosen fields and shows the rationale. FreeDR builds the predicate from its own clauses. You then use the normal Preview and Save. Nothing is saved by the AI.

---

Describe what to find (Hunt draft)

On the Hunt page, describe what you want in plain words, up to 2,048 bytes. The model returns one read-only DuckDB SELECT and a short explanation.

FreeDR checks the SQL against empty tables, so no evidence is scanned. If the check fails, FreeDR tries one automatic repair: it strips code fences, straightens quotes and drops a trailing ;.

If the SQL is valid, it is placed in the editor. It runs only when you choose Run. If it is still invalid, the console shows the error and the SQL.

---

Draft as rule

The same Hunt box can draft a custom detection rule. The model receives a rule manual built from the source registry, with typed-source columns and event-type codes. Event Log rules are not covered by this manual.

FreeDR builds a local.ai-… rule document and checks it with the custom-rule validator, using the same single repair. The rule editor is filled in for you. You then test the rule and save it enabled or disabled. The AI never saves or installs a rule.

---

Public web research

Setting. This needs Enable public web research. It is off by default.

Two ways to use it:

• Investigator tools. web_search and read_public_page, at most 3 of each per run.
• Manual research. On a case's AI tab, the Public web research panel can run a Web search or Read public URL. This works without an AI key. Manual research has a 30-second limit and is not tied to a model.

Search. Search uses the anonymous Parallel MCP endpoint https://search.parallel.ai/mcp. It returns at most 5 results and has a 10-second network timeout.

Search guards. A query must have at most 12 public terms. FreeDR rejects a query before anything is sent if it contains any of these:

• credentials or secret-looking tokens;
• long opaque strings (hashes are allowed);
• private host names (.local, .internal, .corp, .lan, .home …);
• private IP addresses;
• localhost;
• terms that start with -.

Page-read guards. A page read must use HTTP or HTTPS. FreeDR refuses:

• credentials in the URL;
• private or loopback destinations, including after a redirect. FreeDR follows at most 3 redirects and refuses a change from HTTPS to HTTP;
• secret-like query parameters;
• download types (.exe, .dll, .msi, .zip, .ps1, .pdf, .docx, .iso …).

Only text/html and text/plain are read. Page text is capped at 256 KiB.

Failure. If the web cannot be reached, the run records a gap. It is not treated as a clean result.

---

Guardrails summary

Evidence bounding

• The model sees only what FreeDR gives it: the case summary and tool results over retained evidence.
• Each finding must cite at least one retained event_id.
• A non-unknown verdict needs cited events.
• Missing data counts as a gap, not as proof of innocence.

Prompt injection

• Telemetry, scripts, notes, tool replies and your own descriptions are framed as untrusted data, never instructions.
• The prompt tells the model that a guess about who ran something ("a test", "an administrator") is never evidence.
• Model text is stored as JSON strings, and the console escapes everything it renders.

Authority

• The investigator's tool list is fixed.
• Assists have no tools. Each assist offers exactly one answer function: explain_alert, draft_exclusion, draft_hunt_query or draft_rule. Assists run no query, save nothing and call no web tool.
• Containment goes only through the response service, with its own target binding, protections and audit.
• Isolation, deletion, restores and exclusion approval are owner-only.

Network

• Only these hosts are contacted:
  • the selected provider's fixed endpoint;
  • the search service, if web research is enabled;
  • public pages the model or you choose to read.
• FreeDR does not use proxies or follow redirects to the provider, and the HTTP client never retries on its own.

Privacy

• Egress redaction is pattern-based (see AI overview).
• Hidden model reasoning is never stored.
• Run records keep tool observations, the visible report and token accounting. Each assist record keeps a SHA-256 of the redacted request.