| Internet-Draft | ZTIP | August 2026 |
| McCormack | Expires 4 February 2027 | [Page] |
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.¶
This note is to be removed before publishing as an RFC.¶
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 https://github.com/bitscon/ztip.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 4 February 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
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 [ZTIP-SPEC].¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
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 Section 6.¶
ZTIP defines five envelope types:¶
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 [RFC8785] 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.¶
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.¶
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.¶
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.¶
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:¶
There is no partial credit for checks that were merely attested.¶
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.¶
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.¶
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.¶
This document has no IANA actions.¶
The specification this document summarizes is developed in the open; see the repository for history and contributions.¶