KEZEL
positionAug 2026

Move the work, not the data

Every enterprise analytics program starts with a copy. The model behind KEZEL starts with a policy instead.

The standard first step of an analytics program is an extract. Pull the tables, land them in a warehouse or a lake, rebuild the security model around the new location, and hope the two locations stay in step. From that day on there are two of everything: two stores, two credential sets, two retention schedules, two places a breach can start.

The copy is the expensive part. IBM prices the average breach at $4.4M (Cost of a Data Breach, 2025), and every additional copy of sensitive data is additional attack surface, storage and audit scope. Most of what a data-platform security review argues about is the copy: who holds it, where it sits, when it gets deleted.

KEZEL runs on a different sequence. Four beats, always in the same order.

The four beats

Policy first. Before anything executes, your policies define the boundaries: what may run, where, and who may read the outcome. Row filters, column masks, aggregation floors, reader roles. Versioned, and checkable one by one.

Execution in-boundary. The workflow moves to the data. An agent beside your databases receives an encrypted instruction, built from schema metadata and intent, and does the work there: queries, transformations, model runs.

Results remain in-boundary. Nothing is released. There is no outbound data path to review, because there is no outbound data path.

Access under policy. People and systems consume results inside the boundary, through the policy gate. A dashboard read, an alert, an API call: each is an in-boundary event, and each lands on the ledger with the question, the rule and the reader.

KEZEL control planeschema · plans · statusYOUR BOUNDARYcompute · beside the tablesresults · stay herereaders · through the policy gateencryptedinstructionno outbounddata path
fig. 01 · the only crossing is inbound · results are read inside

Compressed: move the work, not the data.

What this removes from a review

A security review of a copy-based platform has to answer for the copy, and the copy touches everything: storage, credentials, retention, incident response, the exit clause in the contract. The in-boundary model gives the review a shorter list. One policy file. One agent your team operates. One inbound path, carrying encrypted instructions built from schema metadata, with the whole run written to a ledger your auditors read in place.

There is a cost, and it is worth stating plainly: the compute runs in your environment, so you size it and you operate the runtime it needs. A team that wants a vendor to absorb its compute is asking for a copy, whatever the brochure calls it.

The four beats are the entire architecture; everything else on this site is machinery for running them well. The orchestration engine page walks one request end to end, in the order a review call asks about it.

written by the KEZEL team at DBTEZ · all articles · book a demo