Zero Trust Fabric Layer Agent-to-Agent Chained Trust on a Connected Flight

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 22 March 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

The original Zero Trust Fabric Layer (ZTFL) moved authorization enforcement off the data plane and onto the network fabric, closing the gap left by identity models that verify who an agent is but not whether that decision holds at the moment of every request [ZTFL]. That architecture was scoped deliberately to a single agent issuing a single request. It did not test what happens when an agent's task requires handing part of that task to a second agent, which may in turn hand a piece of it to a third.¶

2. Related Work

3. The Connected Flight Model

International travel already solves a version of this problem, and it does so with a structure worth referencing for building the framework.¶

A traveler's passport is issued once for ten years, by one authority, and does not change for the duration of a trip. It establishes who the traveler is at every leg, but it is never sufficient on its own to board a flight. A boarding pass is issued separately, at check-in or at the gate, scoped to one specific flight, and it expires the moment that flight departs. The passport and the boarding pass answer different questions. The passport says who you are. The boarding pass says which leg you are cleared for, right now.¶

Most connected flights operate on the same principle. A traveler flying domestically through a connecting hub presents the same passport and a fresh boarding pass at each gate, and that is the end of it. A visa only enters the picture when a leg of the journey crosses into a country the passport alone does not grant entry to. The visa is not carried by default. It is requested, scoped to a specific destination, and checked only at the border where it is needed.¶

This structure maps directly onto ZTFL agent-to-agent delegation:¶

Passport corresponds to P:

the immutable principal identity established once by ZTFL's identity broker, unchanged across every hop in a chain.¶

Ticket corresponds to the Root Token:

issued once by STS at task initiation and never reissued mid-chain. Unlike the Boarding Pass, which expires at a fixed window scoped to a single hop, the Root Token remains valid conditionally for the life of the entire chain and is torn down only once every hop has reported completion, a conditional ephemeral credential rather than a fixed-window one.¶

Boarding Pass corresponds to the per-hop child ephemeral token:

issued by STS for one specific hop, derived from and cryptographically traceable to the Root Token, and useless once that hop completes. A Boarding Pass that cannot trace back to the Root Token is invalid regardless of how correct it otherwise appears.¶

Visa corresponds to a new element:

required only when a hop attempts to cross from one tenant into another, absent by default, and scoped narrowly to the destination tenant it was issued for.¶

An agent operating entirely within its own tenant, the common case, never needs a Visa. Its Passport, Boarding Pass, and traceable reference to the Root Token already satisfy ZTFL's existing boundary check at every hop. The Visa activates only at the specific moment a chain attempts to leave that boundary, which is precisely the moment ZTFL's original single-agent design was never tested against. A compromised agent can still forge a locally valid-looking Boarding Pass, but it cannot forge a reference to a Root Token it was never issued against, which is what stops a rogue downstream agent from acting outside the chain it was actually authorized to join.¶

4. Formal Extension

Let a chain consist of hops T(1) through T(n), each carrying the same Passport P, each issued its own Boarding Pass by STS, and each tracing back to the same Root Token K issued once at task initiation. For hop T(k), define a boundary indicator:¶

crosses(T_k) = 1 if tenant(R_k) != tenant(P), else 0

Every hop, regardless of whether it crosses a boundary, must additionally satisfy a traceability condition:¶

k(T_k): the Boarding Pass at T_k carries a valid reference to K

Unlike the Boarding Pass, which expires at a fixed window scoped to a single hop, K is a conditional ephemeral credential: it remains valid for the duration of the chain and is torn down only once every hop has reported completion, not on a fixed per-hop timer. This distinguishes three separate credential lifetimes in the model: P persists unchanged for the life of the relationship, K persists conditionally for the life of the chain, and the Boarding Pass expires at each individual hop regardless of the chain's overall state.¶

When crosses(T_k) = 0, hop T_k is evaluated using the conditions already established in the original ZTFL architecture (temporal validity, boundary alignment, handshake freshness, and access policy match), together with the new traceability condition k(T_k). When crosses(T_k) = 1, an additional condition activates:¶

v(T_k): V is an element of V_authorized(P, tenant(R_k))

A Visa scoped explicitly to the destination tenant, issued by the same control plane that issues P and K, and never inherited automatically from a prior hop's authorization. The per-hop evaluation function becomes:¶

F_chain(T_k) = t(T_k) * b(T_k) * h(T_k) * a(T_k) * k(T_k)
               * v(T_k)^crosses(T_k)

Because the exponent on the Visa term is 0 on the common path, that term evaluates to 1 automatically and costs nothing when no boundary is crossed. The traceability term k(T_k), by contrast, is checked at every hop unconditionally, since it is what binds the entire chain to a single authorized origin rather than allowing any individually valid-looking Boarding Pass to stand on its own.¶

This closes the gap a naive child-token model leaves open. A forged Boarding Pass presented at any hop, whether or not that hop crosses a boundary, fails k(T_k) unless it carries a genuine reference to the Root Token issued at the chain's origin. A forged or replayed Boarding Pass presented at a boundary-crossing hop additionally fails v(T_k), since no Visa was ever issued for that specific destination tenant. Identity alone, satisfied by presenting P, is not sufficient at any hop. A locally valid Boarding Pass alone, without a traceable reference to K, is not sufficient either.¶

5. Cedar Policy Validation

The formal model in Section 4 was implemented and tested directly against the Cedar policy language to confirm that the traceability and boundary conditions evaluate as specified, rather than resting on the formal expression alone. The schema and policies below encode k(T_k) and v(T_k) as executable Cedar policy.¶

entity Agent = { homeTenantId: String };
entity Resource = { tenantId: String };

action Access appliesTo {
  principal: Agent, resource: Resource,
  context: { ticket: { id: String, issuedTo: Agent,
    homeTenantId: String },
    boardingPass: { ticketRef: String, hopIndex: Long,
      expiresAt: Long },
    currentHopIndex: Long, now: Long,
    visa?: { targetTenant: String, ticketRef: String } }
};

// Policy 1: Ticket and Boarding Pass validity
permit (principal, action == Action::"Access", resource)
when {
  context.boardingPass.ticketRef == context.ticket.id &&
  context.ticket.issuedTo == principal &&
  context.boardingPass.hopIndex == context.currentHopIndex &&
  context.boardingPass.expiresAt > context.now
};

// Policy 2: Visa gate at the tenant boundary
forbid (principal, action == Action::"Access", resource)
when {
  resource.tenantId != context.ticket.homeTenantId
} unless {
  context has visa &&
  context.visa.targetTenant == resource.tenantId &&
  context.visa.ticketRef == context.ticket.id
};

Five requests were constructed against this schema and policy pair to test the traceability condition, the hop-scoping condition, and the boundary condition independently, each isolating one variable at a time against a fixed valid baseline.¶

All five outcomes matched the model's specification exactly. Requests 2 and 3 confirm that k(T_k) rejects a stale or forged Boarding Pass independent of tenant boundary status. Requests 4 and 5 confirm that v(T_k) activates only at the boundary crossing and is satisfiable only by a Visa naming the correct destination and the correct originating Ticket, never by the Boarding Pass or Passport alone.¶

6. Comparison with Existing Approaches

Table 2 compares the connected flight model against the three approaches discussed in Section 2 on the specific property each was not built to enforce: containment at the exact hop a tenant boundary is crossed.¶

None of the three existing approaches were built to answer whether a specific hop crosses a boundary. Each instead answers a broader question: is this actor allowed to exchange this token, does this chain of credentials satisfy the policy, does this principal hold this relationship, without distinguishing an in-tenant hop from a boundary-crossing hop. The connected flight model does not replace any of these three mechanisms. OAuth Token Exchange or an equivalent may still issue the underlying Boarding Pass. Delegation Logic or a similar language may still express the policy a Visa is checked against. What this work adds is the boundary-specific condition that none of the three enforce on their own.¶

7. Discussion and Future Work

This model sits at a deliberate midpoint. The original ZTFL document tested a single agent issuing a single request, formally proven under a non-interference theorem for the hardware-rooted case [ZTFL]. A fully tested multi-agent architecture, with empirical validation of chains of arbitrary length across real infrastructure, remains future work, consistent with the limitation already named in the original document. What this document adds is the missing formal structure for the specific failure mode chaining introduces: an unauthorized boundary crossing hidden inside a chain of otherwise valid-looking hops, without requiring a full empirical chain study to state and justify that structure.¶

Future work includes empirical testing of chains of increasing length against production AWS IAM infrastructure, extending the non-interference theorem to cover the Visa condition explicitly, and evaluating how Visa issuance itself should be authorized, a question this document deliberately leaves open rather than answers by assumption. Section 5 validates the traceability and boundary conditions in isolation against the Cedar policy language; a full chain of arbitrary length exercised against production infrastructure remains the next step.¶

8. Security Considerations

Agent-to-agent delegation breaks a single-agent authorization model at exactly one point: the boundary crossing a naively forwarded token cannot see. This document closes that point specifically, adding a Visa condition that activates only when a chain attempts to leave the tenant its Passport was issued within, while leaving every within-tenant hop exactly as fast and exactly as simple as the original ZTFL architecture already made it.¶

The Ticket referential integrity condition (k(T_k)) is the primary security property this document contributes: a Boarding Pass that cannot trace back to the Root Ticket issued at chain initiation is rejected regardless of how correct it otherwise appears, including cases where the credential is individually well-formed, unexpired, and correctly signed. This closes a replay and relay window that application-layer proof-of-possession mechanisms mitigate only through short token lifetimes and audience restriction, as discussed in Section 2.5.¶

This document does not address how the Visa itself should be authorized, how a compromised Identity Broker or STS would affect the guarantees described here, or side-channel risks in the underlying transport. These are left as open questions for future work.¶

9. IANA Considerations

This document has no IANA actions.¶

Appendix A. Acknowledgments

The author acknowledges the WIMSE working group's published work on AI agent identity, which this document extends rather than replaces.¶

Author's Address