Designing an AI investigation tool security teams can trust

Most security incidents are not lost for lack of tools. They are lost in the gaps between them. An analyst pivots from an endpoint alert to an identity log to a cloud audit trail, copying identifiers between browser tabs, taking screenshots for the record and reconstructing the timeline in a document at the end. The investigation happens; the evidence of how it happened mostly does not survive.

CyberCore is our research into a different shape for that work: a local-first investigation workspace that connects read-only to the security tools a team already owns, opens each incident as a durable case, records every search and finding automatically, and uses AI to propose the next investigative step. It is a concept, not a product. Nothing described here is released. We are publishing the principles because they apply to any team putting AI into security operations.

Principle one: the AI proposes, the analyst decides

The fastest way to lose an analyst’s trust is to let an assistant act on its own. In CyberCore’s design, the AI may suggest a query, a pivot or a hypothesis, but every query against a live system requires explicit human approval before it runs. Connectors are read-only and deny-by-default. The assistant can make an investigation faster; it cannot change the environment being investigated.

An assistant can make an investigation faster. It must never change the environment being investigated.

Principle two: every claim carries its evidence

Language models write fluently about things they have not seen. In an incident, that is dangerous: a confident sentence in a customer brief can become a contractual or regulatory statement. The design therefore requires every factual claim the AI makes to cite the specific evidence it came from, a log line, an alert or a query result held in the case. Claims that cannot be cited are flagged as hypotheses, not stated as findings.

• Findings are linked to the evidence that supports them
• Uncited statements are labelled as hypotheses
• The analyst approves every statement that leaves the case
• Drafts for customers or regulators are clearly marked as drafts

Principle three: the record must be provable

An investigation is only as useful as its record. If the case file can be edited after the fact without trace, it cannot support a handover, a legal hold or a regulatory notification. The design uses an append-only, hash-chained audit log, so each action is linked to the one before it and tampering is evident, and signed exports, so a case shared with a customer can be verified as unaltered.

Principle four: sensitive data stays put

Incident data is some of the most sensitive data an organisation holds. A local-first design keeps case data in an encrypted store on the analyst’s machine, credentials in the operating system’s keychain, and redacts sensitive values before anything is sent to a language model. The question to ask of any AI security tool is simple: where does my incident data go, and who can read it there?

Principle five: threat-model the tool before it ships

A tool that connects to an organisation’s security stack is itself a target. The research plan requires a threat model before any beta and an independent penetration test before release, with the same scrutiny we would apply to a client system. Security tooling that has not been attacked has not been tested.

What we are validating

Before writing production code, the research sets explicit gates: structured interviews with security teams and managed security providers, a manual prototype of the workflow, and design-partner pilots that measure whether investigation time actually falls. If the evidence does not support the product, it will not be built. That is the same standard we apply to every engagement: a claim is not true until it has been shown.

If your team investigates incidents across Microsoft security tools and would like to contribute to this research, we would like to hear from you.