]> 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 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. 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. The credentials defined in this document are constructed so that a verifier applying those rules has what it needs, at every hop, without requiring any change to this document's token profiles. The Passport carries the principal identity a verifier evaluates against. The Ticket's traceable reference to the Root Token, together with the TTL backstop defined above, gives a verifier a bounded, independently checkable validity window rather than an open-ended grant. The Boarding Pass carries the per-hop scope a verifier checks issuance against. The Visa carries the boundary-crossing authority in crosses(T_k) = 1 hop, keyed to the issuer whose evaluator key MUST differ from the boundary's own evaluator key, so that a verifier's issuer/evaluator separation check has a concrete credential to apply it to. This section does not restate 's rules, which are that document's contribution. It records, for implementers reading both documents together, that the token profiles in this document were designed to be evaluable under that framework without modification, and that future revisions of either document should preserve this compatibility rather than treat one as a special case of the other.

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.

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 two distinct problems, acquisition and binding. 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 actually represents the organization it claims to, is a residual this document does not eliminate, and no protocol fully eliminates it. Registry infrastructure narrows the residual and gives it a governance surface, who may publish for whom, what a registry compromise means, what the revocation propagation interval is, but it does not remove the first contact trust decision entirely. This document states that residual plainly 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 and binding have already produced a trusted issuer key. It does not itself solve acquisition or binding. 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 issuer/evaluator key separation text in , adapted from the GAL-37 rule proposed in .

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 acquisition/binding framing used in , and mapped this document's terms against the requirements set out in .