SOCPilots

Reasoning you can read back

A security tool that produces confident paragraphs nobody can verify is a liability. Everything here is built so the working is visible, the actions are gated, and the record survives the conversation.

The agent works in a loop, not a prompt

Given a question, it reasons about what it needs, calls a tool, reads the result, and decides again — until it can answer. The tools reach into your environment, not a general model of the world.

Alert search

search_alerts

Queries the tenant’s own SIEM over a time window and returns what fired, so the agent argues from this environment rather than from training data.

agent tool

Indicator enrichment

enrich_ip

Looks an address or hash up across reputation and pulse sources, caching the result so a busy hour does not become a bill.

agent tool

Case history

check_cases

Searches what this SOC has already decided about something similar. Prior judgement is evidence.

agent tool

Behaviour lookup

query_ueba

Pulls the entity’s profile from the behaviour graph: what it normally touches, and what is new today.

agent tool

Asset context

query_assets

Resolves a host or address to the inventory — owner, criticality, exposure — so severity means something.

agent tool

Exposure lookup

query_shodan

Checks what an address exposes to the internet, for the outside-in half of the picture.

agent tool

Each call and each result is stored with the case. When an analyst disagrees with a verdict they can see exactly which observation produced it, instead of arguing with a summary.

Grounded in ATT&CK and in what you already decided

Retrieval sits underneath the agent. Technique descriptions, detection content and the SOC’s own written procedures are embedded and searched semantically, so an answer about lateral movement is anchored to the framework rather than improvised.

Uploaded evidence is indexed the same way. A document attached to a case last quarter is findable during an investigation this quarter, including text pulled out of screenshots.

retrievaltop 4 of 1,120
  • T1003.001LSASS memory0.89
  • T1550Alternate material0.81
  • proc-14Credential theft response0.77
  • SP-1904Prior case, same host0.74
interface illustration

Automation that survives a restart

Playbooks are drawn on a canvas and stored as a graph. Runs are persisted, so a playbook waiting three days for an approval is still waiting after a deploy, and a step that was half-finished when a container restarted does not silently vanish.

Twelve step types cover the work: calling the agent, invoking a connector, asking a human to approve, branching on a condition, waiting, notifying, updating the case. Four trigger types start a run — a person, an incoming alert, a schedule, or a signed webhook.

playbookphishing · v4 · enabled
alert trigger enrich malicious? approval connector action notify close case
interface illustration · runs are durable and survive a restart mid-playbook

Where the models come from

bring your own key

Your account, your spend

Model access runs on keys you supply. Self-hosted deployments keep that relationship entirely between you and the provider, and nothing is routed through us.

multi-provider

More than one provider, by design

Different work is routed to different models, and a provider outage falls through to another rather than taking investigation offline. Provider choice is configuration, not a rebuild.

cost visibility

You can see what it cost

Model calls are traced and priced, per case and per tenant, because “the AI feature” turning into an unexplained invoice is how these programmes get cancelled.

off is a setting

The AI parts are optional

Automated disposition and agent investigation can be turned off entirely and the platform still works as a SIEM-agnostic console. Nothing depends on a model being available.

Watch it investigate something real

The demo we would rather give you is one where the agent runs against your own alerts and you get to disagree with it.