Zero Trust Datazerotrustdata.io GitHub
ztd pre-release Zero-trust execution layer Source available · BSL 1.1

Zero Trust Data

Verify, then execute.

We build ztd, a zero-trust execution layer for AI agents and the infrastructure they touch. AI systems propose actions; they never get direct control of real systems. The model can ask. The machine that owns the workload decides.

Run it locally Read the source

// ztd is Zero Trust Data: typed intent, independent verification, governed execution, and local evidence.

01 / The problem

Agents that think, approve, act, and log in one process

Most AI agent stacks collapse four separate jobs into a single process. That is a dangerous mix. ztd pulls them apart so the thing that reasons is never the thing that authorizes or executes.

Typical agent stack

Reasoning
Authorization
Execution
Audit

→ one process, one trust boundary. Whatever the model decides is what runs, and the record of it lives in the same place.

With ztd

  • Modelproposes typed intent
  • Gatewaygoverns: policy, consensus, human approval
  • Operatorverifies again and executes locally
  • Evidencerecorded at the execution boundary

This is not a sandbox. It is a governance boundary.

02 / How ztd works

A control plane for AI-driven operations

A client or agent submits a typed intent. The Gateway validates policy, applies human or quorum approvals when needed, and sends the action over an outbound-only connection to a local Operator. The Operator verifies the request on its own, executes only the approved action, and writes its own signed evidence.

Ingress

AI client

MCP, A2A, governed HTTP dispatch, direct envelope, or CLI.

expresses intent
Policy Decision Point

Governance Gateway

Authenticates over mTLS, builds a canonical GovernanceEnvelope, runs L1–L3, binds it to one Operator session.

ztd gw start
Policy Execution Point

Governed Operator

No inbound listeners. Pulls from its session channel, re-verifies everything in L4, executes in L5.

ztd operator start
Evidence

Signed receipts

EXECUTING and COMPLETED/FAILED receipts, plus a hash-chained commitment ledger on the host.

local-first audit

Gateway decides, never executes on your hosts

The Gateway admits transactions, manages PKI, and coordinates deliberation. It publishes each envelope to one exact session channel. There is no broadcast.

Operators verify for themselves

Each Operator recomputes the transaction hash, checks the replay nonce, expiry, and state root, and re-runs doctrine locally. It doesn't take the Gateway's word for it.

Receipts you can check

The Actuator signs a receipt before and after every action and appends to a hash-chained ledger. The host's local evidence is authoritative; Gateway copies are only mirrors.

Humans approve mutations

Under human-approval postures, mutating actions suspend until someone approves with a WebAuthn passkey. Read-only actions don't need that step.

Quorum, signed

L2 Consensus requires K-of-N Ed25519 signatures from enrolled member keys over the transaction hash and decision.

Tribunal: advice, not authority

The optional ztde ensemble runs a five-member Tribunal that reviews proposed host commands. Its verdict is advisory and can never stand in for a protocol signature or passkey.

03 / The interlock

Five layers between intent and execution

Every operation on a governed path crosses the same five-layer pipeline. Missing proofs or rule violations reject the transaction.

L1

Doctrine

Forbidden-pattern matching, MITRE ATT&CK heuristics, and command safety analysis for things like reverse shells, privilege escalation, destructive disk operations, and credential theft.

OwnerGateway + Operator
L2

Consensus

K-of-N multi-signature Ed25519 authorization from enrolled member keys, each signing the transaction hash and its decision.

OwnerGateway + Operator
L3

Notary

Human authorization for mutations: the transaction suspends for WebAuthn passkey approval, or needs an Ed25519 signature from an approved suspended transaction.

OwnerGateway + Operator
L4

Warden

Pre-dispatch gate on the target host: durable nonce reservation, expiry, typed payload decode, local doctrine, hash recomputation, state Merkle root, and posture-required proofs.

OwnerExecuting Operator
L5

Actuator

The single execution boundary. Signs an EXECUTING receipt, appends a signed commitment, mints a short-lived capability bound to the transaction hash, runs the typed handler, dissolves the capability, and signs the final receipt.

OwnerExecuting Operator
Governance postures · fixed at Gateway startup
PostureL1L2L3
doctrineenforcedauditedaudited
consensusenforcedenforcedaudited
ratifyenforcedauditedmutations
notaryenforcedenforcedmutations

Fail closed under every posture

  • L1 doctrine violation
  • transaction hash ≠ envelope id ≠ recomputed hash
  • replayed nonce
  • expired transaction
  • state Merkle root mismatch
  • invalid action type or undecodable payload

04 / Design lineage

An old idea, pointed at AI

The 1972 reference monitor said every access should pass a mediator that is always invoked, tamper resistant, and small enough to verify. Replace subjects and objects with agents and actions, and you get the shape ztd is built around.

// 01

Always invoked

every governed path → five layers

Every operation entering a governed path goes through L1–L5, and the L5 Actuator is the only place execution happens. Operators take work from one session channel and expose nothing inbound.

// 02

Tamper evident

signed receipts · hash-chained ledger

Receipts are signed at the execution site, commitments chain together in a local ledger, nonces are reserved durably to stop replays, and sensitive results are encrypted at rest with AES-256-GCM.

// 03

Verifiable

independent re-check · public source

The executing Operator recomputes hashes and re-checks proofs without trusting the Gateway. The code is published and the documented invariants carry stable IDs, so you can audit claims against the source.

Scope, stated plainly: ztd governs actions that enter through a ztd ingress. A client's own built-in tools, MCP servers it reaches directly, and other side channels stay outside the boundary.

05 / Zero trust, all the way down

Identity on every hop

Transport
TLS 1.3 + mutual TLSRequired on protected routes and pub/sub channels.
Workload identity
SPIFFE URIsOperators, CLIs, apps, and users each have their own identity.
Certificates
ECDSA P-256 · 7-day leavesSeparate intermediates; revocation checked per request.
Topology
Outbound-only OperatorsNo inbound management ports into target environments.
Signatures
Ed25519Consensus votes and approval proofs over the transaction hash.
At rest
AES-256-GCM vaultThree-tier keys: master key, HKDF-derived KEK, wrapped DEK.
Human auth
WebAuthn passkeysFor the console and for L3 approvals.
Revocation
Immediate cut-offRevoking an enrollment adds it to the CRL and drops live sockets.

06 / Local-first, air-gap ready

Your hosts keep the truth

Under ztd's Local-First Audit Architecture, the host where an action runs is the authoritative record of what happened there.

  • One static Go binary. The same ztd binary runs as the Gateway and as each Operator.
  • Sovereign audit. Each runtime owns its SQLite audit database, vault, and state root.
  • Air-gapped deployment guide. Stage native binaries, source builds with vendored dependencies, or prebuilt images for offline transfer.
  • Bring your own models. An Inference Operator can serve local models through Ollama, so inference can stay inside your network.

Ways in · all governed

POST /mcpModel Context Protocol over HTTP, or stdio via ztd mcp serve POST /a2aAgent-to-agent skill calls /operators/commandsGoverned HTTP dispatch for enrolled apps /governance/envelopesPre-built envelopes; missing proofs are never synthesized ztd operator runCLI dispatch to bound Operators
Claude CodeCodexGemini CLIGooseDevin CLI

32 typed native tools in the reference binary: database triage, logs, containers, filesystem, network and TLS, Git, cloud/Kubernetes inspection, and audit receipt queries.

07 / Quick start

Gateway up in three commands

The recommended path builds the binary and starts the Gateway on localhost.

The Gateway-only track needs git, Go 1.26.9, and make. It doesn't need Python, Ollama, or a model SDK. The full platform adds four Operators and the Python ensemble.

make buildBuild locally
./ztd --helpExplore the CLI
$ git clone --depth 1 https://github.com/zerotrustdata/ztd.git
$ cd ztd
$ make up
# builds the binary and starts the Gateway on localhost

08 / Where it stands

Serious, experimental, and looking for pilots

ztd is a serious experimental platform, not a polished enterprise product yet. It's under active development, built with a lot of design depth, and meant for real pilot-and-feedback cycles. The first ztd release is still in progress, and we won't claim certifications we don't have.

Getting started Contribute
  • Pilot itRun it in a lab, platform team, or security group that's evaluating LLM execution boundaries.
  • Break itReview the security and governance assumptions. Design critique is welcome.
  • Watch itBrowse live evaluation campaigns on the public OpenDevOps.ai Evaluation Explorer.
  • Build on itHelp with examples, docs, and integrations for real use cases.

// end of transmission

Let the model ask.
Let the machine decide.

Clone the repo, start a Gateway, and see a governed action come back with its own receipt. If you have a concrete use case, open an issue.

github.com/zerotrustdata/ztd Talk to us on GitHub