Quick Summary: Custom Identity Detection Rule Authoring in Oleria, an AI-native identity security & governance platform, lets detection engineers write, test, and deploy identity rules in code — using the same repo, review, and CI/CD workflow they already use for every other detection.
Author custom rules and detections in a familiar workflow.
Code-style authoring, version control, test-before-deploy. Detection engineering for identity, in the workflow you already use for everything else.
Detection engineers work in code: SIEM rules, EDR detections, NDR signatures — all in repos, with review, testing, deployment pipelines. Identity tools that require GUI-clicking for detection authoring break that workflow. The detection engineer either doesn't author identity detections or maintains them outside their normal process.
What's needed is identity detection authoring that fits the detection engineer's workflow: code in a repo, reviewed via pull request, tested against historical data, deployed via CI/CD, versioned and rollback-able. Most identity tools don't support this and don't pretend to.
Custom Identity Detection Rule Authoring in Oleria means writing identity detections in YAML or Python — version-controlled, PR-reviewed, and test-validated before they ever touch production
Detections expressed as YAML or Python (customer choice). Editable in any text editor; storable in any repo.
Detections live in your repo. Pull requests, code review, branching — standard.
Run a detection against historical identity data. See what it would have caught; tune before deploying.
Standard pipeline. Promote from non-prod to prod; roll back on issue.
Bring identity detections into your engineering workflow — no GUI required.Detection engineers shouldn't have to leave their repo to author identity rules. Oleria lets you write, test, and deploy custom identity detection rules in the same code-first workflow you use for every other detection — faster iteration, better coverage, no backlog.
YAML for declarative detections (common patterns: matches on access-graph state, on event sequences, on combinations). Python for custom logic where YAML is too constrained. Both editable in any text editor; both storable in standard repos. Customers choose based on team preference.
Oleria stores recent identity history (access state, events, changes). The test framework runs your detection against that history and reports: what it would have triggered, when, with what context. False-positive rate is measurable before deploy; tuning happens before deployment, not in production.
Complementary. SIEM detections continue to live where they live; Oleria detections live in Oleria's repo (often the same git org, different repo). Both fit the detection engineer's pull-request workflow. Where detections need to be cross-cutting (SIEM signal + Oleria graph state), the orchestration layer decides which engine evaluates which dimension.
Yes. Pre-built detection library covers common identity-attack patterns (lateral movement, privilege escalation, OAuth abuse, federation hijack, NHI takeover). Customers extend with environment-specific detections; the pre-built set is the starting point and accumulates over time.
Through your CI/CD pipeline. A bad detection deploy gets rolled back the same way a bad code deploy does — revert the commit, redeploy. Oleria's detection state matches the deployed code; rollback is mechanical.
