]> Capitol Technology University

eseymour@captechu.edu

Security Individual Submission agent-to-agent authorization autonomous AI agents chained trust Zero Trust WIMSE The Zero Trust Fabric Layer (ZTFL) verified a single autonomous agent issuing a single request. It did not address what happens when that agent delegates its authority to a second agent, or a third, a pattern already standard in multi-agent orchestration. Existing delegation mechanisms do not close this gap. OAuth 2.0 Token Exchange represents prior actors as claims that are informational only for access control decisions. Classical logic-based and relationship-based authorization models were built for stable, long-lived principals and do not enforce a tenant boundary at the specific hop where it is crossed, nor do they bind every hop in a chain to a single expiring credential established at the chain's origin. This document extends ZTFL with a chained authorization model, structured on the mechanics of international travel. An immutable Passport establishes identity for the full journey. A Ticket, issued once at task initiation as a conditional ephemeral credential, binds every subsequent hop to the same authorized chain; a locally valid-looking Boarding Pass that cannot trace back to it is rejected regardless of appearance. A per-hop Boarding Pass, a child ephemeral token derived from and traceable to the Ticket, authorizes each leg. A Visa, an explicit and narrowly scoped grant, is required only at the moment a hop crosses a tenant boundary the Passport alone cannot cross. The model is formalized as a boundary-conditional evaluation function, implemented and validated against the Cedar policy language, and compared directly against OAuth Token Exchange, delegation logic, and relationship-based authorization on two properties none of them enforce structurally: chain-wide traceability to a single origin, and containment at the boundary itself. This revision further shows that the model's per-hop Boarding Pass structurally resists mid-chain redirection, including redirection caused by prompt injection reaching an intermediate agent, because issuing a Boarding Pass requires standing the redirected agent never holds and cannot acquire by altering its own behavior. This document is intended for discussion on the Workload Identity in Multi System Environments (WIMSE) Working Group mailing list (wimse@ietf.org), archived at .

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.

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

ZTFL enforces authorization at seven coordinated points rather than at the data plane. An Identity Broker issues and verifies the immutable principal tag P for each agent. System for Cross-domain Identity Management (SCIM) provisions and deprovisions that identity across every system the agent may touch, so a revoked agent's access changes everywhere at once rather than at each integration separately. Attribute-Based Access Control (ABAC) expresses every policy as attribute conditions rather than static role membership. Identity and Access Management (IAM), specifically AWS IAM in the implementation ZTFL verifies, is the runtime enforcement point where an ABAC policy is actually evaluated and a request is allowed or denied. Microsegmentation, implemented over VPC Lattice, contains the blast radius of a compromised or misbehaving agent to the specific service boundary the policy allows, independent of network routing. Mutual Transport Layer Security (mTLS) authenticates every service-to-service connection at the transport layer, so a valid principal tag alone is never sufficient without a matching certificate. A Security Token Service (STS) issues two distinct credential types from the same principal: the immutable principal tag P, which persists for the life of the agent's identity, and an ephemeral child token scoped to a single task and torn down on completion. This document assumes no prior familiarity with these seven mechanisms individually and extends only the STS token issuance model, adding the Ticket and Visa constructs introduces.

This gap is important because agent orchestration frameworks already build on exactly this pattern. A scheduling agent calls a retrieval agent, which calls a database agent, each acting on behalf of the original request but never revalidated against it. A child token issued at the first hop and simply forwarded unchanged to the next agent solves nothing on its own. A stolen or forged token can be replayed at any hop, and nothing in a naive delegation model checks whether the second or third agent in the chain was ever meant to reach the resource it is now requesting. This document treats that problem as two separate questions rather than one. First, does this hop belong to the same chain the original request started. Second, does this hop attempt to leave the boundary the original request was authorized within. ZTFL already answers the first question inside a single tenant. This document adds the second. Three conditions make this problem harder than ordinary delegation. First, an agent chain is ephemeral by construction; each hop's credential is issued and expires within the lifetime of a single task, unlike the longer-lived principals classical delegation and relationship graph models were designed around. Second, most of a chain's hops never leave the tenant that authorized the original request, so a mechanism that checks every hop at the same cost as a boundary crossing spends effort where none is needed. Third, existing token delegation standards record prior actors as claims a receiving service may read, not as a condition a network enforcement layer verifies before the request is allowed to proceed. The novelty of this work is not delegation itself; OAuth Token Exchange and logic-based delegation already solve that problem for stable principals. The novelty is binding an explicit, boundary-conditional credential to the same fabric-level enforcement ZTFL already proved for a single hop, so that only the hop attempting to cross a boundary carries the added cost, and every other hop remains exactly as fast as the original architecture.

OAuth 2.0 Token Exchange is the closest existing standard to the mechanism this document extends . A client presents a token it already holds and receives a new token scoped to a downstream service, with an actor claim recording who requested the exchange. The specification itself states that a token consumer must only consider the top-level claims and the current actor; prior actors named in nested actor claims are informational rather than an enforceable part of the access decision. A delegation chain longer than a single hop is therefore visible in an audit trail but not structurally enforced at the point a boundary is crossed. The standard also couples every delegation decision to a synchronous round trip to the authorization server, which makes that server's availability a dependency of every hop in a chain, not only the hops that cross a boundary.

Delegation Logic formalized distributed authorization as a proof-of-compliance problem, representing policies, credentials, and delegation chains in a logic-based language built to reason about whether a set of credentials satisfies a policy . It remains foundational to how the field reasons about chained trust, but it was built for principals in open, human-administered systems. It does not address ephemeral, per-hop credentials issued and retired within a single automated task, and it does not bind a delegation decision to a specific network enforcement layer.

Relationship-based authorization systems, exemplified by Zanzibar, express access as relationships in a globally consistent graph and scale to enormous request volumes with strong consistency guarantees . These systems answer whether a principal holds a relationship to a resource at query time, but the principal in this model is a stable human or service account, not a task-scoped agent whose identity is issued and retired inside a single chain. Extending a relationship graph to agent chains would require writing and later retracting a graph edge for every ephemeral hop, at a cost the original ZTFL architecture was built specifically to avoid.

Recent work on authorization propagation in multi-agent systems argues formally that classical access control models, including role-based, attribute-based, and relationship-based authorization, were not built to maintain authorization invariants as non-human principals delegate tasks and cross changing boundaries, naming transitive delegation and temporal validity as structural gaps none of these models close on their own . This document addresses the transitive delegation gap for the case that matters most operationally: a chain that crosses from one tenant into another, without requiring every hop to pay the cost of the crossing check.

The IETF's AI Agent Authentication and Authorization work, adopted by the WIMSE working group as the AI Identity Management System (AIMS), composes SPIFFE, WIMSE, and OAuth 2.0 to establish agent identity and runtime authorization . AIMS explicitly acknowledges a structural limitation in its application-layer authentication mechanisms: application-layer proof of possession "does not inherently provide channel binding to the underlying secure transport," requiring implementers to independently manage relay and replay risk through short token lifetimes, audience restriction, and nonce checks . These are implementation-level mitigations rather than a structural guarantee, and none of them require a credential to carry a verifiable reference back to a single chain origin. The Ticket referential integrity condition introduced in closes this gap directly: a Boarding Pass is rejected regardless of freshness or audience correctness if it cannot trace back to the Root Ticket issued at chain initiation, a property demonstrated empirically in .

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. Completion reporting alone is NOT sufficient to bound the Root Token's lifetime: a crashed, stalled, or compromised intermediate agent that never reports leaves the Root Token active indefinitely under that mechanism alone. The Root Token MUST therefore also carry a hard maximum lifespan set at issuance, independent of completion reporting, so that a hanging chain cannot leave a root credential valid beyond a bounded window.

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.

A Visa MUST be issued under the authority of the boundary it grants entry to, and MUST be signed by that boundary's issuer key. The issuer key MUST be distinct from any evaluator key used to verify requests at the same boundary . A verifier MUST reject a Visa whose issuer key is also an evaluator key for the same boundary. The Visa carries the principal P as an explicit claim, narrowly scoped to the crossing it authorizes. For any hop where crosses(T_k) = 1, the receiving verifier obtains P only from the Visa, never from the Boarding Pass. The travel analogy extends to where Visa authority actually resides. A destination country's visa is issued under that country's own authority even when the office issuing it sits inside another country's borders. An applicant seeking a student visa to attend a university in the United States, but applying at the United States embassy in Kingston, Jamaica because Jamaica cannot issue that visa, still receives a document whose authority derives entirely from the destination government, not from the mission's physical location. Jamaica hosts the building. It does not hold the authority. The Visa defined here works the same way. Its authority derives from cert(T_k) matching a key registered in V_authorized(P, tenant(R_k)), the destination tenant's own issuer key set, formalized in , never from the network path a request traversed or the physical or topological location of the service that minted it. A destination tenant's issuer key remains authoritative wherever the infrastructure signing the Visa happens to run. A look-alike issuer operated by the origin tenant carries no authority regardless of how close it sits to that boundary, because its key was never entered into the destination's registry. discusses how that registry is itself populated and trusted, which is a separate question from the location independence established here. 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.

This document defines what a chain of custody looks like: the Passport, Ticket, Boarding Pass, and Visa, and the conditions under which each remains valid as a chain moves across hops and tenant boundaries. A separate and complementary question is how a verifier at any single hop evaluates the credentials it is handed. addresses that question directly, defining the evaluation inputs and rules a verifier applies at the point of decision. defines five evaluation inputs a verifier requires: the frozen call, the evaluation instant (not derived from the records under evaluation), the principal on whose behalf the call is made, structurally separated issuer and evaluator keys, and, as of 's Section 3.5, the standing of every issuer on a path, established at the evaluation instant from a source the relying party pins rather than from the presented token alone. It further defines four evaluation rules: process all authorization entries or reject the token, evaluate delegation paths independently with one valid path sufficient, bind consumption to the specific frozen call, and verify records using role-separated keys. The credentials defined in this document supply each of the five inputs without requiring any change to their token profiles. The principal on whose behalf the call is made is carried as an explicit claim on the Passport, unchanged across every hop, giving a verifier a fixed reference point rather than a value it must reconstruct from the chain itself. The frozen call does not belong on the Passport: the Passport is immutable per-principal identity, established once and unchanged across every hop, while the frozen call is specific to a single approved operation. It is instead carried on the Ticket, which is already issued once per task at chain initiation, the same scope the frozen call requires. The evaluation instant is supplied independently of the Ticket and Boarding Pass: the TTL backstop on the Root Token bounds how old that instant is permitted to be relative to issuance, so a verifier checking freshness is not relying on a timestamp the credential under evaluation asserts about itself. Issuer standing is satisfied by a property of the Boarding Pass that this document did not previously name explicitly: a Boarding Pass is bound not only to a single hop and a single principal, but to a single issuer, the carrier of record for that flight number, drawing on the travel mechanics introduced in . A verifier checking issuer standing confirms that the entity which signed the Boarding Pass is the same entity STS authorized to issue credentials for that hop, a check made at the evaluation instant against STS's own current issuer registration rather than against any claim the Boarding Pass makes about itself. This is the structural property that forecloses self-issuance. A compromised or redirected agent, for example one whose task instructions were altered by injected content reaching it mid-chain, retains its Passport and its reference to the Root Token unchanged, since neither is something the agent itself controls or can rewrite. What it does not possess, and cannot acquire by altering its own behavior, is standing to issue a Boarding Pass. It may request the next hop. It cannot answer that request on STS's behalf. develops this case directly. Rule one, process every authorization entry or reject the token, is satisfied by the Ticket's traceability requirement: a Boarding Pass that cannot trace back to the Root Token is invalid regardless of how correct any single entry within it appears, so a verifier cannot selectively honor part of a chain. Rule two, independent evaluation of delegation paths, follows from each Boarding Pass being issued and evaluated per hop rather than as a single monolithic structure. Rule four, role-separated keys, is the Visa's issuer and evaluator key separation requirement stated above, applied at exactly the boundary-crossing hop where role separation matters most. Rule three, binding consumption to the specific frozen call, is only partially addressed by the credentials defined here. The Boarding Pass's single-hop scope and expiry bound the window during which it is valid, but scope and expiry alone do not guarantee one-time consumption. Neither prevents a valid, unexpired Boarding Pass from being presented more than once before that hop reports completion. 's Section 4.3 now states this rule more precisely than the revision this document previously tracked: consumption occurs only at release or rejection of the frozen call, by the full principal the call was frozen for, and an indeterminate outcome during release execution MUST NOT return an approval to pending status, since doing so would permit a retry to duplicate an effect the first attempt may have already caused. That sharper rule describes the requirement correctly. It does not supply this document's missing mechanism. This document does not yet define a durable, atomic consumption mechanism equivalent to the ConsumeOnce invariant defined in , where a terminal state transition at the executor rejects any second presentation of the same authorization instance. names the physical analogue this document intends to formalize in a future revision, the torn Boarding Pass stub, rather than claiming the gap closed here. Aligning the frozen call's canonical representation is a separate task from defining that consumption mechanism: the canonical action reference belongs to , while the executor-side admission and consumption boundary belongs to . This section does not restate 's rules as its own contribution. It records, for implementers reading both documents together, that the token profiles in this document satisfy that framework's five inputs and four rules without modification, and that future revisions of either document should preserve this compatibility rather than treat one as a special case of the other.

Issuer standing has a direct consequence for an agent that is redirected mid-chain, whether by a compromised dependency, a manipulated tool response, or content reaching it through retrieval that was crafted to alter its next action. The redirection can change what the agent attempts to do. It cannot change what the agent is able to present as authorization for doing it, because the agent was never the issuer of any credential it carries. traces this through the travel analogy at the one moment it matters most, a connecting flight after an already-completed clearance.

Standing Clearance Does Not Authorize the Next Hop | Passport + Visa. | | Boarding Pass. | | issued. | | Identity bound | | Scope = THIS | | Ticket | | for full | | flight only. | | issued | | itinerary | | | | for full | | (Ticket). | | | | chain. | | Immigration and | | | | | | Customs CLEARED. | | | +----------+ +--------+---------+ +--------+---------+ | ^ | This clearance is an event | | in the PAST. It is evidence | | identity and entry authority | | were valid AT THAT INSTANT. | | It is not a standing grant to | | board any later flight. | v | +------------------+ | | Traveler now | requests | | holds: Passport | Flight 2 ---->+ | (still valid) + | | Ticket (still | No party here can | valid). Does NOT | self-issue a Boarding | hold a Boarding | Pass. Only the carrier | Pass for Flight 2| of record for Flight 2 +------------------+ holds standing to issue one, checked fresh at this evaluation instant. ]]>

The agent's Passport and Root Token reference are unaffected by redirection because neither is minted by the agent. A Boarding Pass is the one credential a successful redirection would need the agent to produce on its own, and it is precisely the one credential issuer standing prevents the agent from producing. Redirection changes intent. It does not grant standing.

This working group's problem statement includes hardware-based attestation among the context a workload carries across trust boundaries. The credentials defined above establish principal identity, chain traceability, and per-hop scope, but none of them say anything about the hardware the workload issuing the initial request is actually running on. This section defines an optional precondition on Passport issuance that closes that gap without altering any existing token profile. Where an implementation requires it, Passport issuance MAY be conditioned on a hardware attestation step performed under the Remote ATtestation procedureS (RATS) architecture . In RATS terms, the requesting workload's underlying hardware acts as an Attester and produces Evidence, a Verifier appraises that Evidence and produces an Attestation Result, and the Passport issuer acts as the Relying Party that consumes that result before issuing the Passport. Evidence SHOULD be conveyed as an Entity Attestation Token . The Passport carries a reference to the resulting Attestation Result rather than the raw Evidence itself, following the same principle already applied to the Ticket: a downstream verifier checks traceability to an appraised result through local verification, and does not re-run attestation or query the original Verifier at every hop. A Passport issued without this precondition simply omits the reference, and its absence MUST NOT be treated as a defect by a verifier that does not require hardware attestation for the boundary it protects. RFC 9334's model assumes hardware capable of participating in a standard attestation exchange, which a meaningful share of constrained and legacy devices, including much of the installed base in operational technology and embedded medical device environments, cannot do. For hardware that cannot act as a RATS Attester directly, a physical-layer alternative such as RF-PUF based authentication MAY serve as the Attester mechanism, producing Evidence a Verifier appraises the same way. This extends the hardware attestation precondition to hardware classes the RATS model alone does not reach, without requiring those devices to support a standard attestation stack they were never built to run.

A Boarding Pass is consumed at the moment of boarding, not at the moment its validity window closes. The gate scan records the pass as used, independent of whatever expiry timestamp it carried. The physical stub torn at the jet bridge makes this visible: a torn stub cannot be re-presented at another gate even if the printed flight time has not yet passed, and a pass that is never scanned at all simply expires unused, a different and unremarkable outcome. This distinction matters because expiry and consumption fail differently, and collapsing them loses the difference. An unscanned Boarding Pass that expires was never exercised, and rejecting it afterward is a validity check with no bearing on disposition. A scanned Boarding Pass presented a second time, at the same gate or a different one, is not failing a validity check. It is being rejected against a consumed-state record that persists independently of the token's own lifetime, exactly the property 's Section 4.3 now states as a rule: an indeterminate outcome during release execution MUST NOT return an approval to pending status. This document does not yet define the mechanism that would make Boarding Pass consumption atomic and durable in the way a torn stub is durable, the gap already named in . A future revision should define a consumption record, keyed to the Boarding Pass's reference to the Root Token and its hop index, written by STS at the moment a hop reports its first completion attempt and checked by the next hop's issuance request before a second Boarding Pass for the same hop index is ever minted. That record is the torn stub. Until it is defined, this document's consumption guarantee is bounded by scope and expiry alone, as stated plainly in , not by one-time use.

The objects below illustrate the claims each credential carries, as JSON for readability. An implementation MAY encode these as JOSE-based tokens consistent with this working group's token security direction; the field names here are illustrative, not a registered claim set. The Boarding Pass's issuer_standing_ref field is new in this revision. It points a verifier at the source STS itself designates for issuer standing checks under Section 3.5, rather than requiring the verifier to trust an issuer claim the Boarding Pass makes about itself. The Visa's absence of an issuer_standing_ref is deliberate: Visa issuer standing is established through the destination tenant's own registry, defined in , a distinct trust path from STS's.

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. Traceability itself, k(T_k), is verified through local asymmetric signature chain verification: the Boarding Pass embeds a signed reference to K, checkable with public-key cryptography alone. This is what keeps the unconditional per-hop check consistent with this document's efficiency claim; verification never requires a synchronous round trip to STS or a centralized state lookup. 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)) and cert(T_k) = cnf(V) A Visa scoped explicitly to the destination tenant, issued under the authority of that destination boundary rather than the control plane that issues P and K, and never inherited automatically from a prior hop's authorization. Issuance authority for the Visa is defined in . The term cnf(V) is the certificate thumbprint bound to the Visa at issuance under OAuth 2.0 Mutual-TLS , and cert(T_k) is the mTLS certificate actually presented at hop T_k. A Visa relayed or replayed over any connection other than the one it was issued against fails v(T_k) even when V is itself validly signed and correctly scoped, closing a channel-level replay gap the Ticket referential integrity condition does not address on its own. 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.

The formal model in 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. 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. Cedar Playground Validation Results

#	Scenario	Result
1	Valid Ticket and Boarding Pass, same tenant, correct hop	ALLOW
2	Valid Ticket, Boarding Pass issued for a prior hop presented at the current hop	DENY
3	Boarding Pass referencing a nonexistent Ticket	DENY
4	Valid Ticket and Boarding Pass, crossing into a new tenant, no Visa presented	DENY
5	Same as 4, with a Visa naming the destination tenant and referencing the same Ticket	ALLOW

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.

compares the connected flight model against the three approaches discussed in on the specific property each was not built to enforce: containment at the exact hop a tenant boundary is crossed. Comparison of the Connected Flight Model Against Existing Delegation and Authorization Approaches

Property	OAuth Token Exchange	Delegation Logic	Zanzibar / ReBAC	This Work
Traceability to a single chain origin	Partial; actor claims recorded but not required to validate	Yes in theory, but not bound to a runtime, expiring credential	No; no concept of a chain origin distinct from the principal	Yes; every hop must trace back to one Root Token or fail
Boundary crossing enforced structurally	No; prior actors are informational claims only	No; chains proven offline, not bound to a network boundary	No; principal assumed stable, boundary not a first-class check	Yes; Visa condition activates only at the crossing hop
Cost on within-tenant hops	Synchronous authorization server round trip at every hop	Proof evaluation at every hop	Relationship graph query at every hop	None beyond ZTFL's existing boundary check
Chain visibility beyond immediate actor	Yes, via nested actor claims, informational only	Yes, full chain reasoned about explicitly	Limited; graph reflects current state, not history	Traceable to the original Passport at every hop
Built for ephemeral, task-scoped principals	No; designed for longer-lived client credentials	No; designed for relatively stable principals	No; principal expected to persist	Yes; Boarding Pass expires at hop completion by design

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.

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 . 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. 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. This document's traceability requirement, that a Boarding Pass carry a verifiable reference back to the Root Token issued at chain initiation, has informally shaped two other proposals circulating in this working group. adopts the same requirement in its own token profile for authority-attenuated delegation chains. maps this document's terms against a separate, independently derived requirements set for cross-organizational delegation. Neither convergence was coordinated in advance of either document's initial submission, which this document takes as evidence that chain-wide traceability to a single origin is a requirement the problem itself imposes, rather than a preference specific to the travel analogy chosen here.

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 . This document previously left open how the Visa itself should be authorized. That question splits into three distinct problems: acquisition, binding, and trust. Acquisition, obtaining candidate issuer key material for a sending boundary through generally available infrastructure with no interaction specific arrangement, is a problem a protocol can and should name. A shared registry, to which participating control planes publish their current issuer keys, with rotation and revocation handled centrally, is the acquisition channel this document recommends. Binding, whether the key material obtained through that channel is actually tied to the organization it claims to represent, is a narrower and more tractable question than acquisition alone. Registry infrastructure with rotation and revocation narrows this considerably by giving it a governance surface: who may publish for whom, and what a registry compromise means. Trust, whether a specific relying party chooses to extend authority on the basis of a given registry or anchor, is a separate decision again. No protocol can make this decision on an organization's behalf regardless of how well acquisition and binding are solved. This document states that residual plainly, as a governance choice rather than a technical gap, rather than leaving Visa authorization out of band. The issuer evaluator key separation described in is a related but distinct property. It constrains who may mint a valid Visa once acquisition, binding, and trust have already produced an accepted issuer key. It does not itself solve any of the three. Two directions are under consideration for narrowing the binding question further, without closing the trust decision it sits next to. An OpenID Federation style trust chain would let a verifier check a signed chain of entity statements rooted in a shared anchor rather than a bare key drawn from the registry, composing directly with the acquisition channel already described. Transparency log auditability, along the lines already established for certificate issuance, would let a verifier check a key registration against an append-only log before extending trust, strengthening prevention rather than substituting for it by closing the window an attacker would need to exploit a substituted or unregistered key. Acquisition and binding can both be made more verifiable through mechanisms such as these. Trust ultimately rests on a governance layer outside the protocol, the same way a registry of travel document issuers depends on a diplomatic trust framework rather than cryptography alone, and this document states that boundary explicitly rather than implying either mechanism closes it. This is distinct from the location independence property described in , where a destination tenant's issuer key remains authoritative regardless of where the infrastructure minting a Visa runs. A flat registry already provides that property without federation. Federation, where adopted, changes how entries in that registry are attested, not whether authority follows the key rather than the network path. This document still does not address how a compromised Identity Broker or STS would affect the guarantees described here, or side-channel risks in the underlying transport. These remain open questions for future work.

This document has no IANA actions.

SSRN Electronic Journal ACM Transactions on Information and System Security, vol. 6, no. 1, pp. 128-171 et al. Proc. 2019 USENIX Annual Technical Conference (USENIX ATC 19), Renton, WA, USA, pp. 33-46 arXiv:2605.05440

Wes Jackson contributed the Visa issuance text in , adapting the issuer/evaluator role separation defined as rules GAL-37/38 in a specification he cited informally in correspondence.

The author acknowledges the WIMSE working group's published work on AI agent identity, which this document extends rather than replaces. Morgan Reece proposed the original acquisition/binding framing used in , and mapped this document's terms against the requirements set out in . Wes Jackson proposed splitting the binding question further into binding and trust, which now reflects, and separately flagged that 's addition of issuer standing as a fifth evaluation input would leave this document's prior four-input claim stale, prompting the mapping in and .