Developers
One documented API, and nothing behind it you cannot see
Results reach you through a small REST API, a generated client, or the console your analysts already have open. The API is also the boundary: it returns named fields and never the internals of our graph.
The API
An OpenAPI 3 specification describes every route, and the specification is checked against the server by a test — so a field the server requires and the document omits fails the build rather than surprising you.
Responses are field-allowlisted by construction. An attack plan comes back as technique names and ATT&CK identifiers, with the command and every internal node identifier absent — our library cannot be enumerated by asking the API politely.
What you can do with it
- List and inspect engagements, and start an assessment
- Read a run, its chain, and its findings
- Pull the detection gap for a run or for a stored chain
- Plan an attack path without executing anything
- Read immunity results and regressions
- Request a remediation, and apply one under a separate grant
Planning is deliberately not gated by the kill switch. A stopped engagement is exactly when someone wants to see what would have run.
Client and integrations
Python client
Generated from the specification rather than hand-written, so it cannot drift from the server. Typed models, synchronous and async calls.
Splunk
A technology add-on for getting results in, and an app with attack-coverage and posture views for looking at them.
Splunk SOAR
A connector whose containers and artifacts follow a documented field contract, so findings become the tickets your responders already work.
Vendor-neutral content
Detection content is exported as Sigma plus product-specific searches from one source rule — including for products we do not sell an app for.