Detection engineering, run by AI agents. Approved by engineers.
Kyrolan agents research the threat, check your telemetry, write the detection, test it, and keep it tuned after release. Your team reviews each stage and decides what ships.
We walk through the workflow on one technique of your choice.
Lab run · T1543.003 Windows ServiceG1 pending
Product preview · sample run
Synthetic values, not customer data.See sample outputs
Kyrolan is in early access. We are looking for design partners running Splunk.
Design-partner pricing is scoped per engagement.
Why detection teams fall behind
The backlog never shrinks.
New techniques and threat reports arrive faster than a small team can turn them into rules.
Rules rot after release.
A detection that was precise at launch gets noisy as the environment changes, and re-tuning always loses to new work.
Coverage is a guess.
Nobody can say with evidence which ATT&CK techniques are covered, which rules still fire, and which depend on logs that stopped arriving.
Six stages, one loop, an engineer at every gate.
New detections run from Research to Monitor. Live rules that get noisy go through a separate tuning loop. Both flows stop for an engineer before anything ships. See the lifecycle
From report to procedures
Turn an ATT&CK technique or a threat report into cited procedures and atomic test variants.
Check the data first
Check, per procedure, which log sources and fields you actually have before designing.
Draft in your format
Design the detection, then draft it in your repository format with its filter macro and test samples.
Prove it fires
Run attack simulations in your lab and measure false positives over a 7 to 30 day baseline.
Engineer approves
Then Deploy through your CI/CD.
Fix the noise
Find what makes a live rule noisy, propose the smallest safe change, and measure exactly which alerts disappear before anything ships.
Engineer approves
The tuning proposal reaches production through Deploy.
Catch drift early
Track ATT&CK coverage, rule health and drift, and reopen the loop.
The kind of SPL the agents write.
Three illustrative queries, one per job: check the data, draft the detection, measure a tuning change. Index and macro names are generic.
| tstats count latest(_time) as last_seen where index IN (wineventlog, sysmon) by index, sourcetype
| eval age_h=round((now()-last_seen)/3600,1)
| where age_h>24 OR count<100Illustrative. Flags sources that went quiet or barely log, before anyone designs on them.
| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Services where Services.start_mode IN ("auto","demand") by Services.dest Services.service_name Services.service_path Services.user
| `drop_dm_object_name(Services)`
| where match(service_path, "(?i)\\\\(users|programdata|windows\\\\temp)\\\\")
| `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`
| `windows_service_from_user_writable_path_filter`Illustrative. Base search through a datamodel, exceptions in the filter macro, no hardcoded index.
search index=notable search_name="<rule_name>"
| eval would_drop=if(`proposed_exception_predicate`, 1, 0)
| stats count as total sum(would_drop) as dropped values(eval(if(would_drop=1, dest, null()))) as dropped_entities
| eval pct_dropped=round(dropped/total*100,1)Illustrative. Lists the exact alerts a proposed exception removes, not just the before and after totals.
How Kyrolan fits your Splunk.
Kyrolan does not replace Splunk or ingest your logs. It works on top of your detection engineering workflow: read-only searches in, merge requests out, and your own CI/CD ships what your engineers approve. How the integration works
- 1Read-only searches. Kyrolan agents run read-only searches in your Splunk and get the query results back.
- 2Merge requests. Agents propose changes as merge requests in your detection repository (Git).
- 3Engineer review & approval. Your engineer approves the merge request, or sends it back.
- 4Your CI/CD deploys. Your pipeline ships the approved change into Splunk. Agents never deploy.
Principles
Evidence over assertion
Every agent output links to the queries, events and sources behind it.
Engineers decide
Agents propose; nothing reaches production without a named approver.
Your stack, your format
Output follows your rule repository conventions and ships through your existing CI/CD.
One rule, many tenants, different noise.
The same detection behaves differently in every customer environment. The tuning loop is built to run per rule and per tenant.
Same rule, different noise
A backup agent that is noisy for one tenant may not exist at another. The loop looks at each tenant's alerts on their own.
Per-tenant exceptions
An exception added for one tenant stays scoped to that tenant, with its justification recorded.
An audit trail per change
Every proposal, approval and post-check is logged, so you can show a customer what changed and why.
About Kyrolan
Kyrolan builds AI agents for security engineering teams, starting with detection engineering. We focus on making detection work measurable, evidence-driven and continuously maintained.
Founded by a detection engineer in Hanoi, Vietnam. More about us