Write a Rego policy.
Run it over a live stream.
This live demo runs Rego policies over a fictional company's device telemetry with Chalk's query engine. Run a policy against 28,000 historical events or a live stream from 120 simulated laptops at a fictional company, and see exactly which devices and owners it flags.
Trace a policy violation back to the input event
Run a preset over the fictional device history before trying a live stream.
Try this experiment · expected results
1Score the recorded history
Choose a preset and select Run on 7 days of history.
Expected: The returned violations connect policy rules to specific events and their context.
2Change the policy and compare
Edit one condition and run the history again, or start the simulated live stream.
Expected: The same policy can evaluate historical rows and new events; compare the resulting violations.
Run a policy on seven days of history, then compare live events. ChalkSQL joins endpoint context and evaluates the policy to return violations.
Built on Chalk
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.
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_encryptedImplementation details
How the example works
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.
More capabilities
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.