Zero Trust Intelligence

chad@bitscon.net https://zerotrustintelligence.io

Security AI agents governance zero trust receipts verification The Zero Trust Intelligence Protocol (ZTIP) is an open, transport-neutral protocol for governed AI agent transactions. It defines five immutable JSON envelope types and a transaction lifecycle under which every agent-initiated action is authorized by policy before execution, integrity-protected by hash over a canonical form, and -- distinctively -- verified as complete by an authority independent of the actor that performed the work. An executor's claim of success is treated as attestation, and attestation alone never satisfies a required verification check. This document describes ZTIP version 1.0-draft for the record; the full specification, JSON Schemas, examples, and a reference runtime are maintained in the open at the repository referenced herein. About This Document This document is an individual submission with informational intent. It does not represent IETF consensus. Discussion and the authoritative, continuously maintained specification text are located at .

Introduction AI agents are being composed into production workflows at scale: planners invoke executors, orchestrators invoke specialists, tools invoke tools. In most deployed systems these handoffs carry no governance artifact. One agent passes a message; another acts on it. Nothing is authorized against policy, nothing is integrity-protected, and -- the gap this protocol is centrally concerned with -- nothing independently establishes that the work an agent claims to have finished was actually finished. Existing and emerging mechanisms in this space largely govern whether an agent MAY act (identity, authorization, policy interception) and record what was decided (signed decision or action receipts). ZTIP covers that ground and then addresses the remaining question: did the authorized action verifiably complete? ZTIP's answer is structural. Verification requirements are declared before execution, bound by hash to the authorized request, and evaluated after execution by an authority independent of the executor. A transaction resolves as succeeded only when every required check has passed under independent verification; otherwise it fails, closed, with a reason code that distinguishes a failed check from an unverified claim. ZTIP does not restrict which agent frameworks, models, or tools are used, and it does not define a transport. It governs the transaction artifact: what was requested, whether policy authorized it, and what verifiably happened. This document summarizes the protocol for the record; the authoritative, continuously maintained specification, JSON Schemas, lifecycle examples with recomputable hashes, and a reference runtime are published openly .

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Transaction

The full governed unit of work, from request creation to final receipt. A lifecycle with defined states, not a single message.

Envelope

An immutable, integrity-protected JSON object carrying one transaction event. Subsequent events produce new, linked envelopes; prior envelopes are never modified.

Actor

Any entity participating in a transaction: an AI agent, an automated system, or a human. All actors are identifiable to the control plane.

Role

A protocol-level governance classification. ZTIP defines nine roles: operator, control_plane, source_actor, target_actor, planner, executor, validator, auditor, and runtime. Roles describe governance function; tool, vendor, and model names MUST NOT appear as role values.

Control plane

The authority that evaluates policy and issues authorization decisions. ZTIP defines what a control plane must do, not what it must be; any implementation meeting the conformance requirements is a valid control plane.

Attestation

An actor's own report about its work or results. Attestation is input to verification -- evidence to be checked -- never the check itself.

Transaction Lifecycle A ZTIP transaction progresses through defined states; not every state is reached in every transaction. The states are: created, submitted, evaluated, authorized, rejected, accepted, executing, verifying, succeeded, failed, cancelled, and expired. Every terminal state -- succeeded, failed, rejected, cancelled, expired -- produces a receipt. The verifying state is first-class: after execution and before resolution, declared verification requirements are evaluated as described in .

Envelope Types ZTIP defines five envelope types:

transaction_request

Created by the source actor: the requested action (a structured action wrapper with typed parameters, capability requirements, and risk level), the target, and the verification requirements that must pass for the outcome to count as success.

authorization_decision

Issued only by the control plane after policy evaluation. Carries an authorization status (auto_authorized, human_approval_required, human_approved, evidence_required, rejected, or expired), references to the policies evaluated, reason codes, and the hash of the request it authorizes. Human approvals are transaction-specific, action-bound, target-bound, and single-use by default.

execution_receipt

The result envelope. References the original request by hash, records what was attempted and completed, and carries the verification results that establish (or refuse) completion.

evidence_record

Typed supporting material submitted to satisfy a policy or verification requirement: test results, approval records, prior receipts, compliance attestations.

amendment_event

A linked event against an existing transaction (for example, a cancellation request). Amendments do not mutate transaction state directly; the control plane evaluates them and issues the resulting transition.

Integrity Model Every envelope carries an integrity object declaring its canonicalization scheme, hash algorithm, and hash value. Integrity is mandatory: an envelope without a verifiable hash is not a ZTIP envelope. Encryption is policy-conditional and MUST NOT be a prerequisite for envelope processing; envelopes are human-auditable JSON by default. ZTIP v1 uses SHA-256 over the RFC 8785 JSON Canonicalization Scheme canonical form of the envelope, computed with the integrity hash_value itself removed and underscore-prefixed non-normative annotation keys stripped recursively before canonicalization. The remainder of the integrity object -- including the declared canonicalization and algorithm -- stays inside the hash input, so the declared method is itself tamper-evident. Envelopes reference one another by hash (for example, an authorization_decision binds the request_hash of the request it authorizes; a receipt references the request by hash), forming a verifiable chain for the transaction. For historical reasons the envelope version field is named ztap_version, after the protocol's original working name. The field name participates in the hashed canonical content and is therefore retained unchanged; implementations MUST treat it as a fixed protocol identifier.

Completion Verification An executor's claim of success is attestation. It is not verification. A transaction is not complete because the actor that performed the work says it is complete; it is complete when the verification requirements declared in the request have passed under an authority independent of that actor.

Declared Before Execution Verification requirements are declared in the transaction_request, before any action is taken. Each required check is structured (check identifier, check type, expected result); free-text-only checks are invalid. Because the envelope hash binds the declared checks to the authorized request, criteria invented after execution are not verification requirements.

The Independence Requirement Verification MUST be performed by an authority independent of the target actor that executed the action: the control plane, a designated validator actor, or deterministic re-execution of the declared checks. The executor's own report of its results is attestation. Attestation is input to verification -- evidence to be checked -- and attestation alone MUST NOT satisfy a required verification check. The entity that executes does not verify its own work; this is the same separation that forbids self-authorization, applied to completion.

Fail-Closed Acceptance A receipt claiming success is accepted as succeeded only when every required verification check has passed under independent verification. The failure modes are distinct and carry distinct reason codes:

• A required check that was independently executed and did not pass resolves the transaction failed with reason code VERIFY_FAILED.
• A required check satisfied only by executor attestation -- never independently verified -- resolves the transaction failed with reason code COMPLETION_UNVERIFIED.
• If required verification cannot be executed at all, the transaction MUST NOT resolve succeeded; it resolves failed with reason code VERIFY_UNAVAILABLE. An unverifiable success is not a success.

There is no partial credit for checks that were merely attested.

Conformance Levels The specification defines three conformance levels. Level 1 (Envelope Validator) parses and validates envelopes, verifies hashes, and enforces the role and registry rules. Level 2 (Control Plane) manages the full lifecycle: registration, policy evaluation, authorization issuance, approval scope and replay rejection, receipt ingestion with hash verification, and an append-only, hash-linked audit log. Level 3 (Governed Executor/Runtime) enforces the trust boundary at the point of action: refusing governed work without a valid, verified authorization record. Fail-closed behavior is a protocol invariant at every level, not a configuration option: invalid, unknown, expired, tampered, or unauthorized transactions are rejected, and ambiguity resolves to denial.

Transport Independence ZTIP conformance is not concerned with how envelopes are delivered. An envelope may travel over an API call, a file, a message queue, a version-control pull request, or any other channel; governance is enforced at the envelope level. The fact that a message arrived over a secure channel does not make it authorized. The authorization record governs; the transport does not.

Security Considerations ZTIP's guarantees are scoped to what hash-bound envelopes and independent verification can provide. Integrity protection detects tampering with any envelope content after issuance, including the declared checks; it does not by itself authenticate actors, and v1 leaves signature and key-management schemes to deployment profiles. The independence requirement removes the executor from the trust base for completion claims; its strength therefore depends on the actual independence and correctness of the verifying authority and the declared checks. Poorly chosen verification requirements verify the wrong thing faithfully. Validity windows and expiry depend on reasonably synchronized clocks. Denial of service against the control plane degrades the ability to authorize new work but, by the fail-closed invariant, never converts into unauthorized execution. Envelopes are cleartext JSON by default; deployments handling sensitive payloads SHOULD apply channel or storage protection appropriate to their environment, noting that encryption is deliberately not a precondition for envelope processing or audit.

IANA Considerations This document has no IANA actions.

References Normative References Informative References

Acknowledgements The specification this document summarizes is developed in the open; see the repository for history and contributions.