An assistant that has to show its evidence
A security assistant that cannot be checked is worse than no assistant, because a confident wrong answer costs more than an empty screen. Falak's analyst assistant is constrained to the OCSF events in your tenant, and every sentence it produces carries the event uids that support it. If it cannot cite, it does not claim.
- Every claim carries the event uids that support it
- Grounded in your tenant's OCSF events, nothing else
- Drafts hunt queries you review before running
- Explains process ancestry in plain language
- Suggests a disposition and says why
- Never executes a response action on its own
Capabilities
What it does
Citations, not confidence
Each paragraph of a generated summary is annotated with the event uids it was derived from. Click one and the raw OCSF document opens. An assertion with no citation is rendered as an open question rather than a finding.
Scoped to a single tenant, always
The retrieval layer is constructed from the caller's tenant scope, the same way every other query in the platform is. There is no shared index and no cross-tenant embedding store. Your events are not training data for anyone.
Ancestry explained, not summarised away
Given a process tree, the assistant describes what each step in the chain did and which step is anomalous relative to the workload's own history — which is the judgement an analyst is actually making.
Hunt drafting with a review step
Describe a hypothesis in a sentence and get a hunt query against real OCSF field paths, plus the compiled ClickHouse it would run. You read it, edit it, and run it. The assistant never runs a query on your behalf.
Disposition suggestions with reasons
It proposes true positive, false positive or benign, and states the evidence for and against. On a false-positive suggestion it identifies the specific legitimate behaviour it matched, so you can write a scoped exception rather than disabling a rule.
No autonomous response, by design
The assistant can populate a response request. It cannot sign one — signing is core's, and the sensor verifies the signature. Automation that can kill processes without a human in the loop is not a feature we are willing to ship.
Detections
Representative detection content
| Detection | Technique | Primary signal |
|---|---|---|
| Incident summary with citations | grounded | evidence event_uids |
| Process ancestry narration | grounded | 1007 ancestry |
| Anomaly framing vs workload baseline | statistical | 30d per-workload |
| Hunt query drafting | assisted | OCSF field catalog |
| Disposition recommendation | assisted | rule + FP list |
| Exception scoping suggestion | assisted | matched FP clause |
| Related-finding clustering | statistical | correlation_uid |
| Case narrative drafting | grounded | case member findings |
Telemetry collected
- Retrieval scope
- single tenant
- Grounding source
- OCSF events
- Cross-tenant index
- none
- Customer data in training
- never
- Autonomous response
- disabled
- Citation requirement
- enforced
- Audit trail
- every prompt logged
- Opt-out
- tenant setting
what a grounded summary looks like
A process named "memfd:payload" executed from an anonymous memory file descriptor on ip-10-40-118-14 at 09:31:04Z. [evt_9c2f…, evt_4a71…] Its parent was a shell spawned by the container entrypoint two minutes earlier, which is not a pattern this workload has shown in 30 days. [evt_e30b…, baseline: ledger-writer 30d] Eight seconds after the exec, the process opened an outbound connection to 198.51.100.77:4444 (AS209242). [evt_1d55…] Not established: whether the payload persisted. No 1001 write events were observed on this host in the following 10 minutes.
Assistance you can audit
Try it against a real incident in your own tenant and check every citation. That is the only way to evaluate a security assistant, and the product is built to make it easy.