Spec-driven development for
agentic detection engineering
opentide gives every detection an ontology and a taxonomy, so it stays threat-aligned, maintainable and fast to ship, with or without agents.
pip install opentide01why it matters
Agents made the query cheap. Not threat-aligned.
Intelligence outruns detection engineering, and agents now write a KQL or SPL query in seconds. What did not get any cheaper is knowing that the query is valid, maps to a real threat and is deployed where it should be.
Writing a detection query
seconds
- by hand
- the baseline
- with agents
- seconds
Aligning and maintaining it
still hours
- by hand
- the baseline
- with agents
- still hours
Threat alignment, coverage and maintenance did not get cheaper with the text. A spec has to carry that work.
what becomes scarce
schema: rule::1.1
severity: Significant incident↳ severity::1.001A spec
An ontology and a taxonomy for what a detection is.
- 02
Threat alignment
Every rule traces to an objective and a threat.
$ opentide validate --strict
OK Validation passed
$03Quality gates
Strict validation in CI, for humans and agents alike.
- 04
Maintainability
One model across every integration, versioned in git.
That is what opentide is.
02what opentide is
Three objects. Three questions. One graph.
A threat says what you defend against, an objective what to detect, a rule how and where. They link to each other by UUID, threats chain into attack paths, and all of it meets the assets, log sources and detectors of your environment by name and vocabulary.
objects/
.opentide/configurations/
- UUID reference, resolved by opentide validate
- name or vocabulary value
Objective
What are we trying to detect?
The detection goal, with a priority, a type and a composition strategy. It lists the threats it covers, and the signals that together satisfy it.
Signals
What evidence do we look for?
Each signal is one observable part of the objective: the entities it watches, its methodology and severity, the log sources it needs, and the detectors that already see it.
Rule
How do we detect it, on which integration?
One configuration block per integration, each with its own query, status and schedule. The rule names the objective it implements, so every alert traces back to a threat.
Detectors
What already sees it?
Vendor or in-house detections that watch your assets. Signals record the detectors that already cover them, so new work goes where nothing is looking yet.
Assets
What do we run?
The systems in your environment, tagged with the surface vocabulary that threats use, and ranked by criticality. A threat on OS::Windows::Desktop meets the workstations that run it.
Log sources
What do we collect, and where does it land?
Telemetry from your assets, and the integration it lands in. opentide generate writes the names into the JSON Schema, so a signal’s log sources complete in the editor.
Integrations
Where does it run?
The SIEM and EDR platforms the rules deploy to, each configured once per repository with the tenants a plan deploys to.
the taxonomy
35 versioned vocabularies keep every value comparable.
hover one to see its values
- surface
- att&ck
- actors
- chaining_relations
- severity
- impact
- leverage
- viability
- criticality
- killchain
- signal.entities
- detection.methodology
- detection.composition
- detection.types
- alert_severity
- datasources
- att&ck.groups
- mitigations
- malapi
- collection
- objectives
- stakeholders
- sectors
- resources
- efforts
- feasibility
- level
- maturity
- scheduling
- sophistication
- tier
- tlp
- pap
- rsit
- violation
Coverage is a graph, not a heatmap.
“We cover 85% of ATT&CK” cannot say which threats hit what you run, or where an attack path goes unseen. The graph can: threats meet your assets on their surface, chain into attack paths, and every step traces to the objective and rules that detect it, or shows up as a gap.
A colour per technique. It cannot say which threats reach your assets, or where an attack path goes unseen.
01 · Edge firewalls · High
Gateway exploitation
Portal exploitation on PAN-OS → Threat log · SPL
02 · Corporate workstations · Medium
Credential dumping from LSASS
Credential access via LSASS → LSASS · KQL, LSASS · SPL
03 · Windows servers · High
Lateral movement over SMB
Gap: no objective covers it
04 · File servers · Severe
Ransomware deployment
Mass file encryption → Encryption burst · KQL
03how it runs
From YAML to every integration.
One pipeline: author, generate, validate, deploy, document. The commands you run on a laptop are the commands CI runs.
- 01
Author
Threats, objectives and rules as YAML, from generated templates.
objects/*.yaml - 02
Generate
Deterministic schemas, templates, vocabularies and snippets. Safe to commit.
opentide generate - 03
Validate
Schema, unique UUIDs, references, vocabularies. Exit 1 blocks the merge.
opentide validate --strict - 04
Deploy
Per integration and tenant. Staging from the pull request, production on merge.
opentide deploy - 05
Document
Wiki pages with chaining diagrams and ATT&CK coverage.
opentide generate docs
ci, generated by opentide setup ci · github · gitlab · azure
pins the opentide version you ran
pull request
merge to main
One model. Every integration. No rewrites.
A rule carries one configuration block per integration, so adding an integration adds a block, not a rewrite. Threats and objectives stay as they are.
opentide deploy turns each block into that integration’s own detection, from a Sentinel analytics rule to a Splunk saved search. The rule’s status decides where it lands: staging tenants while you refine it, production once it is live.
detection_model: …0001 configurations: sentinel: defender_for_endpoint: splunk: sentinel_one: carbon_black_cloud: crowdstrike: harfanglab: your_next_one:
Microsoft Sentinel
KQL analytics rule
Defender for Endpoint
KQL custom detection
Splunk Enterprise Security
SPL saved search
SentinelOne
S1QL STAR rule
Carbon Black Cloud
Lucene watchlist IOC
CrowdStrike Falcon
correlation rule
HarfangLab
Sigma or YARA rule
- Your integration next?Request it
04built for agents
An agent is only as good as the spec it is held to.
People and agents need the same things from detection tooling. Agents need them stricter: a contract to read, feedback to act on, tools to call, knowledge to load, and gates they cannot skip.
- 01
A contract it can read
Normative specs, generated JSON Schema, 35 versioned vocabularies
objective::1.0 - 02
Feedback it can act on
--json results, exit codes, file:line findings
exit 0 · 1 · 2 - 03
Tools it can call
MCP: search, chaining, coverage, validation, dry-run deploy
opentide mcp start - 04
Knowledge it can load
The same skills and an agent entry point (AGENTS.md or CLAUDE.md), installed by opentide setup skills
opentide setup skills - 05
Gates it cannot skip
setup ci: strict validate and lint, live query checks, staging first
opentide setup ci
Three ways in. One model.
Every command answers the same way, so pipelines and agents act on results, not prose. The CLI, the Python SDK and the MCP server load the same objects from the same models, in one package.
$ opentide validate --strictOK Validation passed$ echo $?0- Every link resolves
- A rule names a real objective, an objective names real threats, or validation fails.
- Every value is in the taxonomy
- Vocabulary fields take versioned values only: severity::1.0, surface::1.0, att&ck::1.1.
- One JSON document on stdout
- --json returns ok and a status, and every issue with its code, file, line and field.
- Exit codes gate CI
- 0 success · 1 error · 2 usage. No parsing needed.
05agentic detection engineering
Agents draft. opentide checks. Humans decide what reaches production.
Prompt in, objects out: skills draft the chain, opentide validates it, and the pull request meets the same gates as any human change.
What agents may do, and what stays human.
agents and opentide
Let agents
- Search, read and summarise objects and coverage
- Draft objects from templates
- Run
validation_reportand surface concrete errors - Fix dangling references and vocabulary violations
- Preview deploys with
dry_run=true
people
Keep a human in the loop
- Real, non-dry-run deploys to production
- Bulk promotion to
PRODUCTION - Credentials and deployment plans in
.opentide/configurations/ - Reviewing and merging the pull request
- Regenerating or hand-editing UUIDs
Strict gates keep agent output threat-aligned and shippable.
06what comes next
The north star: intel to a reviewed, deployed detection in under an hour.
Agents and opentide carry everything up to STAGING. People keep the gates that decide what reaches production.
target sub-hour from intel to STAGING, with a human approving every promotion
- agents + opentide
- waiting on a human
Intel lands
an advisory, a report,
a ticketAgent drafts
the chain, in YAML
skills + MCPopentide checks
validate --strict
validate query --livePR opened
branch + diff
CI gates runSTAGING
from the pull request
--plan STAGINGHuman review
a reviewer
approves the mergePRODUCTION
on merge
--plan PRODUCTION
Where opentide goes next.
Four directions, tracked in public issues, RFCs and the migration guide, each with a clear status.
- in progress
- rfc accepted
- planned
- proposed
- 012 items
Integrations
More places the same rule runs.
- 023 items
In the editor
The spec where you type.
- 033 items
A stronger model
Richer rules, cleaner state.
- 043 items
Toward 1.0
A stable surface, fewer legacy paths.
07get started
Start in five commands.
From an empty folder to a validated detection repo, with your agent wired in.
# opentide, with the MCP server extra
$ pip install 'opentide[mcp]'
# a detection repo: Sentinel, GitHub CI
$ opentide setup --yes --platform sentinel --ci github
OK Setup complete
# wire your agent: writes .mcp.json
$ opentide setup mcp --claude-code --yes
OK MCP configuration generated
# give it the authoring skill
$ opentide setup skills --claude-code --yes --install opentide-detection-rule
OK Agent skills installed
# the same strict gate your CI runs
$ opentide validate --strict
OK Validation passed, but no detection objects were found under ~/detection-repowhat you get
validated- detection-repo/
- ├── objects/threats/ objectives/ rules/
- ├── .opentide/configurations/platforms/sentinel.toml
- ├── .github/workflows/opentide.ymlvalidate · lint · deploy
- ├── .mcp.jsonruns opentide mcp start
- ├── CLAUDE.mdthe agent's entry point
- └── .claude/skills/opentide-detection-rule/
Generated pipelines install the exact opentide version you ran setup with, so upgrades arrive as a diff you review.
the ecosystem
Each repository has one job.
The toolchain, the contract, the content, the interface and the agent brain. Your detection repo stays yours.
- opentidetoolchain
The CLI, Python SDK and MCP server, in one package on PyPI.
- specificationscontract
The contract: normative object specs, 35 versioned vocabularies and RFCs.
- librarycontent
Shared content: published threats, objectives and rules at TLP:CLEAR.
- explorerinterface
The interface: browse threats, objectives, signals, rules and their chains.
- skillsagents
The agent brain: 27 skills for Claude Code, Cursor, Codex, Copilot and Kiro.
- language-servercoming soon
Rust and tree-sitter language server for KQL, SPL and Tide YAML. In progress.
- vscode-extensioncoming soon
VS Code onboarding, validation and authoring, built on the language server.
- your detection repoyours
Your content: private objects, platform configuration and CI. The source of truth, in git.
Agents write the queries. The spec keeps them aligned.
An ontology, a taxonomy, and the gates that hold every detection to them. Open source and forever free: the spec under CC-BY-4.0, opentide under EUPL-1.2. You choose how much runs with you, and how much runs on its own.