The Zero Trust Intelligence Protocol (ZTIP): Governed, Independently Verified AI Agent Transactions

Status of This Memo

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 20 April 2027.¶

Copyright Notice

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.¶

Table of Contents

1. 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 [ZTIP-SPEC] .¶

Implementation experience since the previous revision surfaced a failure mode that deserves protocol-level treatment: a verifier can report "verified" over content whose scope it never established -- an empty set of envelopes, a reference that resolved to nothing, a record that is missing the envelope that would contradict it. A tool that does this reproduces, one layer down, the very substitution of claim for evidence that ZTIP exists to prevent. Section 5.2 states what integrity verification does not establish, and Section 7 specifies the fail-closed rules for verifying a set of envelopes together. Appendix "Changes from draft-mccormack-ztip-00" lists the changes in this revision.¶

2. 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 [RFC2119] [RFC8174] 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.¶

Bundle

A set of ZTIP envelopes verified together: the envelopes of one transaction, an audit-trail export, or an evidence package. A bundle is a verification unit, not a transaction event, and is not itself an envelope.¶

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.¶

Annotation field

A non-normative member whose key begins with an underscore. Annotation fields are removed before canonicalization and are therefore outside the envelope hash.¶

3. 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 Section 6 .¶

4. 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.¶

An object that declares any ZTIP envelope field -- ztap_version, envelope_type, transaction_id, or integrity -- is an envelope and MUST be verified as one, even when it also carries a member that would otherwise mark it as a bundle wrapper. See Section 7 .¶

5. 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 [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. This hash rule is unchanged from the previous revision.¶

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.¶

6. 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.¶

7. Bundle Verification

Envelopes are commonly verified in sets: the envelopes of one transaction, an audit-trail export, an evidence package. Verifying a set raises questions that verifying a single envelope does not -- what was in scope, what resolved, and what is absent -- and each of them is a way for a report to claim more than was checked. An implementation that verifies a bundle MUST apply the following rules. Each fails closed.¶

A wrapper carries envelopes; it is not one.

An object declaring any ZTIP envelope field -- ztap_version, envelope_type, transaction_id, or integrity -- is one envelope and is verified as such, even when it also carries an envelope collection member. Reading such an object as a wrapper would leave the envelope itself unverified while the reported count described its payload. An object declaring none of those fields, and carrying an envelope collection, is a wrapper. Testing a single field, such as envelope_type alone, leaves this bypass open to any object that drops or nulls that one field.¶

An empty bundle is not a verified bundle.

Verification over zero envelopes MUST NOT report success. An implementation MUST report how many envelopes it verified, so that no consumer -- human or automated -- can read "nothing to verify" as "everything verified".¶

Report what was counted, not what was submitted.

An implementation reporting a count states how many envelopes it verified and how many references it resolved. Zero resolved references is not a verified chain.¶

References MUST resolve.

A request_hash that names a transaction request not present in the bundle leaves that linkage unverified and MUST be reported as such. An implementation MAY offer an explicit mode for verifying a deliberately partial bundle -- receipts held without their requests, for example -- and in that mode it MUST state that chain linkage was not verified.¶

References resolve by transaction.

A request_hash is resolved against the transaction_request carrying the same transaction_id, and MUST equal that request's hash. Resolving by hash value alone would let a receipt bind itself to a different transaction's request.¶

Every binding site is resolved, not only the top-level field.

An authorization decision's human approval reference carries its own transaction_id and request_hash, and that pair is what binds a human approval to the work it approved. It is resolved under the same rule. Leaving it unchecked is how an approval for one transaction gets attached to another while every hash still verifies.¶

One transaction request per transaction.

A bundle carrying more than one transaction_request for a single transaction_id has an ambiguous request history: a second request can shadow the first while every hash still checks out. This is invalid regardless of which request the receipts reference.¶

One transaction, one outcome.

A transaction may carry several envelopes and several receipts, but receipts reporting different terminal states for one transaction_id are contradictory: a consumer would have to guess which one settles the transaction.¶

A success MUST NOT contradict its own record.

A succeeded receipt whose every recorded check reports failure is internally inconsistent, regardless of which checks were required.¶

Envelopes MUST be ZTIP envelopes.

Content that does not satisfy the envelope contract -- a protocol version the verifier supports, a known envelope_type, a transaction_id, an integrity object declaring the canonicalization and hash algorithm it was sealed under, and the fields that envelope type requires -- is not verifiable ZTIP content, and a self-computed hash over it MUST NOT be reported as a verified envelope. Value-level conformance beyond that contract -- identifier formats, role vocabularies, reason-code namespacing -- is schema validation, and a verifier that does not perform it MUST NOT imply that it did.¶

Verify under the rules the envelope declares.

An envelope declaring a canonicalization or hash algorithm the verifier does not apply MUST be reported, not silently verified under the verifier's own default. Otherwise the report describes a computation nobody performed.¶

Content beside the envelopes is not verified.

A wrapper may legitimately carry metadata -- an export identifier, a timestamp -- beside its envelopes. That content is outside every envelope hash, so an implementation MUST report it alongside its result. This is a disclosure duty, not grounds for refusal: refusing such an export would push integrators to stop verifying exports at all.¶

The document MUST be unambiguous.

A JSON object that declares the same member name twice means different things to different parsers while every hash still checks out. An integrity model built on a canonical form cannot accept that; such a document is not verifiable.¶

Content that cannot be read at all -- input that is not well-formed UTF-8 JSON, or an envelope for which no canonical form can be computed -- is a usage error rather than a verification finding, and an implementation SHOULD report the two conditions distinguishably.¶

8. Conformance Levels

The specification defines three conformance levels. Level 1 (Envelope Validator) parses and validates envelopes, verifies hashes, enforces the role and registry rules, and applies the bundle verification rules of Section 7 whenever it verifies more than one envelope together. 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.¶

Conformance also constrains what an implementation may say about its own results. A report that names a verdict without naming the scope it covered is non-conforming, at every level.¶

9. 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.¶

10. Implementation Status

This section records the state of implementation at the time of writing, in the spirit of [RFC7942] , and is not part of the protocol.¶

An open-source reference runtime implements the canonicalization, hashing, envelope verification, and bundle verification rules described here, with a command-line interface that hashes and verifies envelopes and bundles and exits non-zero on any finding. A conformance corpus of ten lifecycle examples with recomputable hashes is published alongside the JSON Schemas, and the schemas alone accept that corpus. The rules in Section 7 were derived from defects found in that runtime: in each case the tool reported a verified result over content it had not established the scope of. Continuous integration executes the runtime against the corpus, which had previously been validated only for schema and JSON syntax conformance. Current status, test matrix, and open questions are maintained at [ZTIP-SPEC] .¶

11. 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.¶

A verification tool is itself part of the attack surface, and an overstated verification report is the failure this revision is most concerned with. An adversary who cannot alter a sealed envelope may still be able to shape what a verifier examines: submit an empty set, a wrapper whose own envelope goes unchecked, a receipt whose request is absent, a second request that shadows the first, a result stored under an annotation field that the seal does not cover, or an object with a duplicated member name that two parsers read differently. In each case every hash presented checks out and the honest answer is "scope not established". An implementation that answers "verified" has been used as a laundering step for an unverified claim. The rules in Section 7 exist to close that gap, and they are stated as reporting duties as well as verdicts: a verdict without its scope is not a usable security statement.¶

Consumers of a verification report SHOULD treat the report's declared scope -- how many envelopes were verified, how many references resolved, what content was carried outside the envelopes, and whether chain linkage was verified -- as part of the result, and SHOULD fail closed when that scope is absent.¶

12. IANA Considerations

This document has no IANA actions.¶

Changes from draft-mccormack-ztip-00

This section is to be removed before publishing as an RFC.¶

No change was made to the integrity hash rule, to the envelope version field name, or to the five envelope types. Every change below either states a limit that was always true or specifies behavior an implementation must not get wrong when verifying more than one envelope at a time.¶

• New Section 5.2 states the three questions integrity verification does not answer -- authenticity, whether a declared check ran, and whether the record is complete -- and forbids presenting a hash check as answering any of them. New Section 5.1 states, correspondingly, what recomputing a hash does establish.¶
• New Section 7 specifies the fail-closed rules for verifying a set of envelopes together: envelope-over-wrapper precedence on any declared envelope field, refusal of an empty bundle, reference resolution scoped by transaction_id, resolution of the human-approval binding site and not only the top-level reference, one transaction request and one terminal outcome per transaction, no succeeded receipt that contradicts its own recorded checks, the envelope contract that content must satisfy before a self-computed hash may be called verified, verification under the rules the envelope declares, disclosure of content carried beside the envelopes, rejection of a document with a duplicated member name, and the duty to report the counts actually verified and resolved.¶
• New Section 6.4 requires a succeeded receipt to record at least one structured verification result naming the check and its outcome, states that a result carried under an annotation field is not recorded because the seal does not cover it, and makes identifying the verifying authority a producer obligation whose absence is an audit gap rather than a verification failure.¶
• Section 4 and Section 8 carry the envelope-over-wrapper precedence rule and the bundle rules into Level 1 conformance, and add that a report naming a verdict without naming its scope is non-conforming.¶
• Section 11 adds the verification tool itself as attack surface: the ways an adversary can shape what a verifier examines without altering a sealed envelope, and the corresponding advice that consumers treat a report's declared scope as part of its result.¶
• New Section 10 records the reference runtime, the ten-example conformance corpus, and the fact that the rules in this revision were derived from defects found in that runtime.¶
• Definitions added for Bundle and Annotation field; the abstract and introduction updated to name the new material.¶

Acknowledgements

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

Author's Address