A family of pre-engineered components.
The models will keep changing every few months. This layer is built to stay put: workflows, an orchestration engine and an analytics module that adopt independently and compose into one platform.
What each component does.
Workflows
Agent workflows, ETL and scheduled jobs that act with permission. Every step is checked against policy at run time, every run lands on the in-boundary ledger, and the orchestration controller handles dispatch and retries.
agent workflows · ETL · scheduled jobs · run-time policy checks · run ledger
Start here when the first workload is operational: casework, refresh jobs, movement inside the boundary.
Orchestration engine
The Zero Trust Orchestration runtime that carries the other two. Policies compile into encrypted instructions; agents beside your data pull them, run them, and write every action to the ledger. This is the layer your security team reviews.
Metadata Engine · Instruction Generator · Vault & Crypto Services · Orchestration Controller · Streaming Agent · Monitoring & Audit Engine
Review this first. Its page walks one request end to end, in the order a review call asks about it.
Analytics module
Dashboards through VizEngine, plain-language queries through LLMCore, and the Insights Studio engines, all over governed views. Third parties collaborate on those views inside your boundary; the records stay put.
VizEngine · LLMCore · Insights Studio · governed views · lineage
Most teams' first visible result. Its page shows every surface on sample data.
The second component attaches to the first.
The runtime underneath every component is the same engine, so adding a component extends the deployment your security team already reviewed instead of opening a second program. The policy layer and the ledger are shared.
The questions your architect will ask.
Short answers, in the order they come up on a review call.
Do we have to adopt the whole platform?
No. KEZEL is a family of pre-engineered components. Start with one workflow or one dashboard; the orchestration engine underneath is the same, so later components attach to what you already run.
Where do AI models and agents fit?
Analytical models and agent workflows run inside the boundary, acting with permission through the orchestration engine, and every action lands on the ledger. LLMCore plans from schema metadata in the control plane and is built to plan without raw-row access. Swap models as they improve; the policy layer stays.
What stays inside our boundary?
Raw records, computed results, and their consumption. Dashboards and APIs are read inside the boundary through the policy gate; no records pool in a second platform.
What actually crosses it?
One thing, inbound: an encrypted instruction built from schema metadata and intent. There is no outbound data path. Dashboards, alerts and APIs are consumed inside the boundary, through the policy gate, and every crossing and read is logged.
What can the control plane see?
Schema and context metadata, plans and run status. It is built to work without raw-row access.
How does the agent deploy?
As a Docker or Kubernetes container, a VM, or a system service your team operates: on-premises, in your cloud, or hybrid. The agent initiates every connection and pulls its instructions, so no inbound ports are required; restricted and air-gapped patterns are a design target.
Which systems does it speak to?
Warehouses (Snowflake, BigQuery, Redshift), SaaS (Salesforce, HubSpot, Zendesk) and custom systems, with CDC and legacy connectors for estates that predate the cloud.
What do our auditors get?
The orchestration ledger: question, plan, policy decision, reader, timestamp. Plus lineage from any published figure back to its sources.
The boardroom case and the agent spec.
No new copies of sensitive data
IBM prices the average breach at $4.4M (Cost of a Data Breach, 2025). Every extra copy of sensitive data is attack surface, storage and audit scope. KEZEL's answer is structural: the analytics happen without the copy.
Data stays in its jurisdiction
Data that must stay in-country stays there. Designed to support DPDP, GDPR and CCPA obligations through locality, lineage and access logs rather than paperwork after the fact.
First deployment is a single agent
The first workload starts where the data already is. Your security team reviews a policy file and one agent, not a re-platforming program.
KEZEL · AGENT SPEC
- deploy
- Docker · Kubernetes · VM · system service
- footprint
- one lightweight agent inside your environment
- transport
- TLS 1.3
- encryption
- AES-256
- secrets
- vault-held keys
- connectors
- Snowflake · BigQuery · Redshift · Salesforce · HubSpot · Zendesk · custom
- audit
- every orchestration step logged
Security documentation and attestation scope: trust.dbtez.com
Bring a real workload. We’ll answer it in place.
Start with a demo on our sample boundary. Move to a pilot in yours once your security review clears it.