What happens between the question and the answer.
The engine at the family's core implements Zero Trust Orchestration, DBTEZ's patent-pending architecture. Below: the concept as four working principles, a request walked end to end, and the services inside the engine.
How it actually runs.
Classic zero trust stops trusting the network. Zero Trust Orchestration goes one step further and stops trusting the analytics pipeline with data: the coordinator plans and dispatches the work, and is built to do it without the rows.
01
Work moves to the data
Workflows are dispatched to agents beside the source. There is no staging area and no second copy of your source data to secure.
02
Built to hold no rows
The control plane plans from schema and context metadata and is built to work without raw-row access; what it holds is schema, plans and run status.
03
Every action is verified
Each instruction is compiled from policy, encrypted, and pulled by the agent over a connection the agent itself opens. Nothing pushes into your network.
04
Every action is accountable
Policy decision, reader and timestamp land on an in-boundary ledger, one row per read, kept where your auditors can check it.
zero trust orchestration · DBTEZ architecture · patent-pending
Policy is defined first
Before anything runs, your policies define what may execute, where, and who may read the outcome: row filters, column masks, aggregation floors, reader roles. Versioned, and checkable one by one.
The instruction travels, encrypted
The instruction is built from schema and intent alone, encrypted, and sent in. It is the only thing that crosses the boundary; your records have no path out.
Compute happens beside the tables
The agent sits with your databases and does the work there: queries, transformations, model runs. Masking and aggregation apply before a result even exists to show.
Results are read inside the boundary
Results stay where they were made. Dashboards and alerts read them through the policy gate, and the ledger keeps the question, the rule and the reader together.
Policy
your rules, versioned
Encrypted instruction
built from metadata, carries no records
Compute
beside your tables
Read under policy
reads go via the gate
boundary crossings · one, inbound, encrypted
consumption · inside, every read logged
Metadata Engine
schema and context; built to work without row access.
Instruction Generator
intent + policy compiled into an executable plan; LLMCore assists natural-language intent.
Vault & Crypto Services
vault-held keys; encrypts instruction payloads.
Orchestration Controller
dispatch, lifecycle and retries for every plan.
Streaming Agent
runs the plan beside your databases, with source credentials that stay in-boundary.
Monitoring & Audit Engine
the in-boundary ledger; control-plane events are written into it, so the trail is complete.
Your databases & applications
warehouses, operational stores and SaaS, reached through CDC and legacy connectors.
channel · TLS 1.3, payloads AES-256 · the agent initiates every connection and pulls its instructions; no inbound ports · restricted and air-gapped network patterns are a design target
What your security team reviews.
A policy file and one agent. The agent deploys as a Docker or Kubernetes container, a VM, or a system service your team operates; it initiates every connection and pulls its instructions, so no inbound ports are required.
transport · TLS 1.3 · payloads · AES-256 · secrets · vault-held keys · audit · every orchestration step logged
The full due-diligence answers and the agent spec are on the platform page. Attestation scope and security documentation live at 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.