Open protocol

ZTAP
The governed
transaction layer.

An open protocol for AI-generated action. Every request is enveloped, evaluated, authorized, executed, and receipted — in a standard, machine-readable form.

Transport-agnostic · Integrity-required · Auditable by design

View the protocol on GitHub See enforcement →
ztap-envelope.json v1.0
{
"ztap_version": "1.0",
"action": "deploy_service",
"actor": "ci-bot@org.io",
"target": "prod/api-gateway",
"integrity_hash": "sha256:a3f9..."
}
01 / envelope valid
02 / hash verified
03 / policy ALLOWED
04 / execution in progress
05 / receipt pending...
open protocol

transport

HTTP gRPC MQ

Protocol flow

Every governed action follows the same path.

Five deterministic steps. Each mandatory. No step can be skipped without breaking the chain of verifiability.

1

Request

AI agent initiates action. Intent captured in transparent JSON envelope.

2

Policy evaluation

Envelope submitted to policy engine. Rules evaluated against action, identity, and context.

3

Authorization

Policy engine returns signed allow/deny decision. Decision carries policy reference and timestamp.

4

Execution

If authorized, action proceeds. System knows what ran, when, by whom, under which policy.

5

Receipt + Audit

Signed receipt generated. Immutable evidence for compliance, forensics, operations.

transport-agnostic JSON envelope # integrity hash signed receipts policy-conditional

Deep dive

Each step examined.

What it is, why it matters, and what breaks without it.

1

Step one

Transparent JSON envelope

What it is

A structured, machine-readable JSON object that captures the complete intent of an AI-generated action before execution. Includes actor, action type, target, context, and timestamp.

Why it matters

Intent must be externalized and explicit before it can be evaluated. An opaque action is an ungovernable action. The envelope is the unit of governance.

Without it

No policy engine can evaluate an action it cannot read. No receipt can reference an intent that was never recorded. The entire chain collapses at the first step.

2

Step two

Integrity hash

What it is

A cryptographic hash of the envelope contents. SHA-256 by default. Content-addressed: the hash uniquely and deterministically identifies the exact envelope that was submitted.

Why it matters

The integrity hash makes the envelope tamper-evident. Any modification to the envelope after hashing invalidates the hash. The receipt must reference the hash — not the envelope text.

Without it

An envelope without a hash can be modified after authorization. The receipt would reference intent that no longer matches the action that executed. Audit integrity breaks.

3

Step three

Authorization decision

What it is

A policy engine evaluates the envelope against defined rules. The evaluation considers actor identity, action type, target, context constraints, and any applicable scope limits.

Why it matters

This is the governance checkpoint. The decision must be explicit (allow or deny), signed, and include the policy reference. A signed decision is itself evidence of the governance step.

Without it

Any action could execute regardless of whether it was within scope, authorized by an appropriate identity, or compliant with organizational policy. Governance becomes a post-hoc review — not a pre-execution control.

4

Step four

Execution

What it is

The authorized action proceeds. The execution system receives the signed authorization and acts within its defined scope. The action is bounded by what was specified in the envelope.

Why it matters

Execution is what actually changes systems. Binding it to a prior authorization — with an unbroken hash chain — means every change is traceable to a governed decision. Not an assumption.

Without it

An authorization step without bounded execution is meaningless. The action could execute beyond its scope, or execute with different parameters than what was authorized.

5

Step five

Execution receipt + audit trail

What it is

A signed document capturing: the original envelope hash, the authorization decision, the actor, the outcome, and the timestamp. Receipts accumulate into an append-only audit log.

Why it matters

The receipt is the output of the ZTAP process. It is the evidence. It answers: what was requested, who authorized it, what policy applied, what ran, and when. This is what compliance and forensics require.

Without it

Without receipts, governance has no artifact. Every prior step — envelope, hash, authorization — produces nothing that persists. The action is indistinguishable from an ungoverned one.

Technical spec

Designed for the real world.

Transport-agnostic

Works over HTTP, gRPC, message queues, webhooks, or any transport layer. ZTAP governs the action — not the pipe it travels through.

Structured JSON

The envelope is a defined JSON schema. Human-readable. Machine-parseable. Diff-able. Policy engines, audit systems, and tooling can all operate on the same structure.

Integrity-first

Integrity is required. Encryption is policy-conditional. ZTAP does not secure the pipe — it verifies the action. These are different problems with different solutions.

Open standard

ZTAP is published openly. Any implementation can conform. Any audit tool can verify conformance. No vendor lock-in to the protocol layer.

Sample ZTAP envelope

{
"ztap_version": "1.0",
"action": "deploy_service",
"actor": "ci-bot@example.com",
"target": "production/api-gateway",
"timestamp": "2025-05-22T14:32:11Z",
"context": { ... },
"integrity_hash": "sha256:a3f9c2b1..."
}

The gap

ZTAP defines the protocol.
But a protocol without enforcement is just documentation.

You need a policy engine that evaluates envelopes. An agent registry that defines actors. An audit store that persists receipts. An interface that makes governance operational.

ZTAP without enforcement is like HTTP without a server.

Meet ZTI Core: the enforcement layer