Write the policy once.
Run it on every event.
Edit a Rego policy and run it over a fictional company's device telemetry: process launches, network connections and USB events, each joined to the device's owner, posture and agent version. The same policy scores a live stream and seven days of history, evaluated natively inside Chalk's query engine.
Pick a policy, or write one
Choose a preset or edit the Rego, then press Run on 7 days of history to score 28,000 recorded events, or Start live stream to score new events as a simulated fleet of 120 laptops produces them. Both run live, through ChalkSQL on a Chalk environment, with your policy. The company, people and network destinations are all made up.
Policy where the data is
Telemetry alone rarely decides anything. Whether a USB drive matters depends on whose laptop it is plugged into, so the policy runs after the join, not before it.
Join the context
Each telemetry event is joined to its endpoint record: owner, team, posture, disk encryption and monitoring-agent version. The policy sees both as one input document.
Evaluate natively
regorus_eval is a function in Chalk's query engine, backed by a Rust Rego interpreter. There is no OPA sidecar and no round trip per event: the policy runs where the data is.
Batch and stream
The same SQL scores seven days of history in seconds, and scores every two-second batch of live events in well under a second. Change the policy, and both change with it.
One function, four arguments
regorus_eval(policy, query, input, data) takes the Rego source, the rule to evaluate, the input document and the data document as strings, and returns the query results as JSON. Build the input from whatever you joined, in the same query.
This demo sends the policy as a caller-supplied table, so an edited policy can never change the SQL around it. Its live stream sends each two-second batch of new events the same way.
package telemetry
import rego.v1
# Removable storage is fine, except on sensitive teams or unencrypted laptops.
violations contains v if {
input.event.kind == "usb_insert"
input.event.mass_storage
sensitive_context
v := {
"rule": "usb_storage_on_sensitive_device",
"severity": "medium",
"reason": sprintf("%s mounted on a %s laptop", [input.event.product, input.device.team]),
}
}
sensitive_context if input.device.team in data.sensitive_teams
sensitive_context if not input.device.disk_encryptedPolicy as code, at data speed
Keep the rules your security team writes, and run them over every event you collect.
Plain Rego
Policies are standard Rego v1: rules, sets, comprehensions and built-ins. Security teams keep writing the language they already review.
Context in the input
Join any table, feature or online value into the policy's input. A rule can depend on who owns the device, not just on what the event says.
Fast enough for history
In this demo, one rule checks 28,000 historical events against 120 endpoints in about five to ten seconds, and all four rules together in about twenty.
Policy as data
The policy travels as a table, not as SQL text. A visitor-edited policy can only change which events it flags, never the query around it.
Structured violations
Rules return rule names, severities and reasons as JSON, so results feed alerts, tickets or features without parsing log lines.
Backtest a rule
Before you ship a new rule, run it over last week's telemetry and see exactly which devices and owners it would have flagged.
Bring your policies to your telemetry
Talk to an engineer about running Rego over your streams and history, with the context you already have.