The Zero Trust Intelligence Protocol (ZTIP): Governed, Independently Verified AI Agent Transactions
draft-mccormack-ztip-00

Network Working Group                                       C. McCormack
Internet-Draft                                   Zero Trust Intelligence
Intended status: Informational                             3 August 2026
Expires: 4 February 2027

  The Zero Trust Intelligence Protocol (ZTIP): Governed, Independently
                     Verified AI Agent Transactions
                        draft-mccormack-ztip-00

Abstract

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

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

McCormack                Expires 4 February 2027                [Page 1]
Internet-Draft                    ZTIP                       August 2026

   This Internet-Draft will expire on 4 February 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  Transaction Lifecycle . . . . . . . . . . . . . . . . . . . .   4
   4.  Envelope Types  . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Integrity Model . . . . . . . . . . . . . . . . . . . . . . .   5
   6.  Completion Verification . . . . . . . . . . . . . . . . . . .   5
     6.1.  Declared Before Execution . . . . . . . . . . . . . . . .   5
     6.2.  The Independence Requirement  . . . . . . . . . . . . . .   6
     6.3.  Fail-Closed Acceptance  . . . . . . . . . . . . . . . . .   6
   7.  Conformance Levels  . . . . . . . . . . . . . . . . . . . . .   6
   8.  Transport Independence  . . . . . . . . . . . . . . . . . . .   7
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   7
     11.2.  Informative References . . . . . . . . . . . . . . . . .   8
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

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

McCormack                Expires 4 February 2027                [Page 2]
Internet-Draft                    ZTIP                       August 2026

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

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.

   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.

McCormack                Expires 4 February 2027                [Page 3]
Internet-Draft                    ZTIP                       August 2026

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

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.

McCormack                Expires 4 February 2027                [Page 4]
Internet-Draft                    ZTIP                       August 2026

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.

   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.

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

McCormack                Expires 4 February 2027                [Page 5]
Internet-Draft                    ZTIP                       August 2026

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

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

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

McCormack                Expires 4 February 2027                [Page 6]
Internet-Draft                    ZTIP                       August 2026

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

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

10.  IANA Considerations

   This document has no IANA actions.

11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

McCormack                Expires 4 February 2027                [Page 7]
Internet-Draft                    ZTIP                       August 2026

   [RFC8785]  Rundgren, A., Jordan, B., and S. Erdtman, "JSON
              Canonicalization Scheme (JCS)", RFC 8785,
              DOI 10.17487/RFC8785, June 2020,
              <https://www.rfc-editor.org/info/rfc8785>.

11.2.  Informative References

   [ZTIP-SPEC]
              McCormack, C., "ZTIP: Zero Trust Intelligence Protocol --
              Specification, Schemas, Examples, and Reference Runtime",
              2026, <https://github.com/bitscon/ztip>.

Acknowledgements

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

Author's Address

   Chad McCormack
   Zero Trust Intelligence
   Email: chad@bitscon.net
   URI:   https://zerotrustintelligence.io

McCormack                Expires 4 February 2027                [Page 8]