| Internet-Draft | Cross-Org Agent Delegation | August 2026 |
| Reece | Expires 4 March 2027 | [Page] |
Autonomous software agents increasingly act on behalf of human principals by invoking tools, services, and other agents, frequently across organizational boundaries. Existing workload and token-based authorization mechanisms were designed for a single trust domain and a small number of delegation hops. They do not adequately express, constrain, or verify authority that is delegated recursively among agents and that crosses the boundary between independently administered organizations. This document describes the problem of cross-organizational agent delegation, identifies the gaps in current mechanisms, and enumerates requirements that any solution within the scope of the Workload Identity in Multi-System Environments (WIMSE) working group should satisfy. It does not specify a solution.¶
This note is to be removed before publishing as an RFC.¶
Informative references to agent-to-agent and tool-invocation protocols, to workload identity credential formats, and to status-list-based revocation will be added in a subsequent revision; they are omitted here to keep the problem statement mechanism-neutral.¶
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 4 March 2027.¶
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.¶
Software agents that incorporate large language models or other autonomous decision logic are increasingly deployed to perform tasks on behalf of human principals. A common pattern is for an orchestrating agent to decompose a task and delegate sub-tasks to specialized sub-agents, each of which may invoke tools or further sub-agents. These tool and agent invocations are frequently mediated by protocols such as the Model Context Protocol and agent-to-agent messaging, and they increasingly cross the boundary between independently administered organizations: an agent operated by one organization invokes a tool or agent operated by another.¶
The Workload Identity in Multi-System Environments (WIMSE) working group is chartered to address identity for workloads that operate across multiple systems and trust domains. Autonomous agents are a workload class whose delegation behavior stresses existing identity and authorization mechanisms in ways that this document seeks to make explicit.¶
The authorization question raised at each agent action is not a single question but a composition of several: which workload is acting; what authority it holds; from whom that authority was delegated and through how many intermediaries; on behalf of which human principal it ultimately acts; and whether a relying party in a different organization can answer all of the foregoing without contacting the originating organization at the moment of the call.¶
Existing mechanisms answer some of these questions within a single trust domain. This document argues that none answers all of them across organizational boundaries, and that the gap is significant enough to warrant work within the WIMSE working group.¶
This document is a problem statement and requirements document. It deliberately does not propose or endorse any specific mechanism, credential format, or token construction.¶
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.¶
This document uses the following terms.¶
This section describes seven facets of the cross-organizational agent delegation problem. They are interrelated; a solution that addresses only a subset leaves exploitable or operationally untenable gaps.¶
An orchestrating agent commonly delegates a narrowed slice of its authority to a sub-agent, which may delegate a further narrowed slice to another sub-agent, and so on. Each step SHOULD only be able to narrow authority, never to widen it. Existing bearer-token mechanisms typically express a fixed set of scopes granted at issue time and provide no native, verifiable model in which authority is recursively attenuated across multiple hops while remaining verifiable end-to-end. Where multi-hop delegation is expressed at all, the constraint that a later hop cannot exceed an earlier hop is frequently enforced only by the issuing party's policy rather than being verifiable by an arbitrary relying party from the conveyed authority alone.¶
When an agent in organization A invokes a tool or agent in organization B, organization B's relying party must evaluate authority that was issued under organization A's trust anchor. In the general case there is no pre-existing bilateral agreement between A and B specific to this interaction. Mechanisms that assume a shared identity provider, a shared policy store, or a pre-provisioned federation relationship do not generalize to the open, many-to-many case in which agents from numerous organizations interact without having been federated in advance.¶
Two sub-problems are usefully distinguished within this boundary, because they admit very different treatment. The first is acquisition: how a relying party obtains candidate trust material for a previously unknown organization at all. The second is binding: whether the acquired material genuinely represents the real-world organization it claims to represent. Acquisition is fully addressable by mechanism: trust material can be made resolvable through generally available infrastructure that either party joins independently, so that nothing specific to the interaction needs to exist in advance. Binding is not: some initial act ties an anchor to a real-world entity, and no acquisition channel eliminates that act; Section 7 states this residual, its grading to consequence, and its amortization across repeated interaction. The requirements in this document, R2 in particular, demand the first property while bounding, not discharging, the second.¶
Agent tool invocations can occur at high frequency and with stringent latency budgets. Requiring the relying party to call back to the originating organization's infrastructure at the moment of each invocation -- to introspect a token, resolve a session, or confirm authority -- introduces latency, a runtime availability dependency on a third party, and a privacy exposure (the originating organization learns each time and where its agent's authority is exercised). A relying party SHOULD be able to reach a correct authorization decision from the conveyed authority, locally cached trust material, and locally cached revocation state, without a synchronous call to the originating organization on the critical path.¶
An agent typically acts on behalf of a human principal. Two distinct authorization questions arise at each action and are independent of one another: whether the agent is permitted to perform the class of action at all, and whether the human principal on whose behalf it acts is entitled to the specific resource the action targets. An authorization model that captures only the first question permits a "confused deputy", in which an agent authorized for a class of action is induced to apply it to a resource belonging to some principal other than the one it acts for. A model that resolves the second question by having the agent inherit the principal's full set of permissions produces an over-privileged deputy, in which compromise of the agent escalates to the full authority of the human. Across a multi-hop, cross-organizational delegation chain, the identity of the on-behalf-of principal must be conveyed and constrained in a manner that a remote relying party can evaluate, and that intermediary agents cannot silently alter.¶
Authority conferred on an agent must be revocable, and revocation must reach relying parties in other organizations. Because the verification path SHOULD avoid a synchronous callback (Section 3.3), revocation state must be conveyable to relying parties out of band and checkable locally, while remaining authentic (a revoked authority cannot be made to appear valid) and bounded in staleness (a relying party can reason about, and fail safe on, the age of its revocation information). Reconciling offline verification with timely cross-domain revocation is a central tension.¶
After the fact -- for incident response, compliance, or dispute resolution -- it must be possible to reconstruct who authorized a given action, through which intermediaries, and on behalf of which principal, even though the relevant events were recorded by different organizations. No single organization observes the entire delegation chain in a cross-organizational interaction. The records held by each participant must be composable into a coherent end-to-end account, and each participant's record must be resistant to undetectable alteration.¶
Some classes of action are consequential enough that an organization's policy requires a human decision at the moment of execution, regardless of what standing authority the acting agent otherwise holds: releasing a payment above a threshold, deleting or exporting a data set, modifying a safety boundary, or triggering a physical action in the world. Within a single trust domain this is commonly implemented as step-up authentication or an approval workflow anchored at a shared authorization server. Across a multi-hop, cross-organizational delegation chain, three properties become difficult to obtain at once: that the requirement itself survives delegation, so that no intermediary can shed it; that the human's decision is bound to the specific action being taken, rather than to a session or to a class of actions; and that the relying party which enforces the requirement, possibly offline and in another organization, can verify the decision's evidence at the moment of enforcement.¶
Public discussion has converged on this pattern from several directions, including grant-time consent records and challenge-based transaction-authorization proposals in the OAuth community, "user-mediated escalation" in agent-authorization use-case work, and "physical-world action authorization" requirements for embodied agents. These proposals differ in mechanism; they share the underlying need this facet states.¶
The following observations motivate work in this area. They are stated at the level of mechanism classes rather than specific documents, to avoid mischaracterizing any individual specification.¶
Session-oriented authorization frameworks excel at granting a client scoped access within a trust domain but generally assume a small, fixed delegation depth and a relying party that can reach the authorization server. Their extension to recursive agent delegation across organizations is not native.¶
Token exchange mechanisms [RFC8693] can express that one party acts on behalf of or is impersonating another, but they do not provide a verifiable model of recursive attenuation across an arbitrary number of hops, nor a guarantee, checkable by an arbitrary relying party, that the on-behalf-of principal is invariant along the chain.¶
Workload identity mechanisms establish strong identity for workloads and increasingly span multiple systems, which is precisely the WIMSE remit; the open question this document raises is how delegated, attenuated, principal-bound authority is conveyed and verified when the workloads in question are agents that delegate to one another across organizational boundaries.¶
Mechanisms that rely on a shared policy decision point evaluate rich policy at runtime but reintroduce a runtime dependency and a single administrative domain, which is the dependency Section 3.3 seeks to avoid in the cross-organizational case.¶
The cumulative gap is that no widely deployed mechanism today lets a relying party in one organization verify, locally and without a callback, a recursively attenuated, principal-bound delegation chain that originated in another organization, while supporting cross-domain revocation and composable audit.¶
Any solution within scope SHOULD satisfy the following requirements. They are derived directly from the problem facets in Section 3 and are stated independently of any particular credential format or cryptographic construction.¶
This document does not address the correctness of an agent's internal reasoning. Mechanisms that constrain delegated authority bound what an agent is permitted to do; they do not prevent an agent from misusing authority it legitimately holds, for example as a result of prompt injection. Defense against such misuse is complementary and out of scope here.¶
A second, distinct non-claim concerns authority the mechanism never conveyed. These requirements concern what a relying party can conclude from conveyed authority. They assume that, for the governed classes of action, the conveyed authority is the only authority path available to the acting agent. Where the execution environment also grants the agent ambient authority (the principal's own credentials, cached sessions, or other paths to the same resources), satisfying R1 through R10 establishes the validity and scope of what was presented; it does not establish that the principal's delegation governed the action. Three cases are therefore distinct: correct use through the delegated path, misuse within the conveyed scope, and action through another path altogether ("conveyed delegation bypassed by ambient authority" [I-D.bu-agentproto-security-principal-binding]). The requirements bear on the first two and are silent on the third. The assumption is load-bearing for R10 in particular: where an agent executes as the principal, with the principal's own credentials, no artifact can establish that the approver was distinct from the executing agent. Making conveyed authority the sole path is an environment and architecture concern, on the execution side (an agent runtime holding no ambient credentials) and on the resource side (declining ambient-credential access for agent-originated requests, which presupposes distinguishing agent-originated from principal-originated action), and is out of scope for this document.¶
This document does not address confidentiality of agent payloads beyond what is implied by ordinary transport security, nor does it address denial-of-service resistance except where a design choice in a future solution would create an asymmetric amplification.¶
This document does not select among credential formats, signature schemes, or policy languages, and does not endorse any specific product or implementation.¶
This document is a problem statement; its security considerations are the security properties that a future solution must provide, which are stated as requirements in Section 5 (notably R1, R4, R5, R7, and R10) and as problem facets in Section 3.¶
Several tensions deserve explicit attention by any solution. The avoidance of a runtime callback (R3) is in tension with timely revocation (R7); a solution must make the staleness of offline revocation state explicit and must fail safe. The reliance on a relying party's local trust material for cross-organizational verification (R2) makes the integrity of that trust material, and of the means by which it is resolved and cached, a high-value target; a solution must ensure that the trust root used to verify a remote organization's authority cannot be silently substituted. The binding of an on-behalf-of principal (R5) is only meaningful if the binding is integrity-protected end to end, including against modification by the intermediary agents that form the delegation chain.¶
Cross-organizational verification without an interaction-specific prior arrangement (R2) carries an irreducible first-contact residual: the initial binding of a previously unknown organization's trust anchor to the real-world organization it claims to be. Generally available infrastructure narrows that residual, and reliance on it can be graded to the consequence of the action, but no mechanism removes it. Its cost is, however, bounded by continuity: once the first-contact binding is taken, a hash-chained authority history and continuity signatures carry the binding across key rotation with no new leap of trust and no new bilateral arrangement. The prior arrangement is paid once, at first contact, rather than re-paid per interaction, so a repeated relationship sits lower on the trust gradient than a reading of R2 as tending toward a prior relationship would suggest: the residual is amortized to a single pin, not renewed.¶
Requirement R10 introduces considerations of its own. An execution-time approval is only as meaningful as the fidelity of what the approver was shown: a solution must ensure that the action presented for approval and the action bound into the evidence are the same action, and that no party, including the executing agent itself, can alter one relative to the other. Such commitment binding proves what presentation was committed to; it does not by itself prove what the human perceived or understood, and a solution's claims should be bounded accordingly. Those two poles are not adjacent: whether the committed presentation was in fact rendered to a display is a separate property, about delivery rather than perception, that an implementation MAY establish, and a verifier that establishes only commitment cannot distinguish a presented disclosure from an unrendered one. This document leaves that middle property open rather than settling it by omission. The at-most-once reliance property becomes a distributed-consumption problem when a relying party is replicated, and its failure mode must be refusal rather than double reliance. Fail-closed treatment of unrecognized designations is what preserves the requirement across verifiers of differing capability; a fail-open interpretation would convert the newest designation into the weakest link. Finally, R3 and R10 compose deliberately: the human's decision may be obtained through any interactive means, but verification of its evidence at the point of enforcement inherits R3's offline discipline. These considerations, like R10 itself, operate under the sole-authority assumption stated in Section 6: where the executing agent also holds ambient authority, verification establishes what was presented, not what governed the action. Conformance and test artifacts should preserve this boundary in their verdict vocabulary: an artifact-level result asserts that the presented delegation verified, never that the delegation governed the action, and a verifier that cannot observe or exclude alternative authority paths should report an indeterminate rather than a passing result for the stronger claim [I-D.bu-agentproto-security-principal-binding].¶
A solution SHOULD keep the evaluation of human-authorization evidence, its validity and policy sufficiency, separate from the atomic admission or consumption of the designated action, and SHOULD record the authorization decision and the admission result separately, including an already-consumed refusal reason; this composes with R8. The distinction matters because a replayed presentation can carry evidence that remains authentic, exact-action-bound, and policy-satisfying. The honest record of such a replay is two attempt records: the first attempt is authorized and admitted; the second presents the same still-valid authorization and is nevertheless refused as already consumed, and the refused attempt has no outcome. The converse failure also occurs in practice and is why consumption is constrained to admission: an implementation that consumes the reliance unit during evaluation and later refuses (on an exact-action mismatch, for example) destroys a valid human approval without performing any action. That converts every refusal path into a denial vector against approver attention, and where approvals are staged ahead of disconnected operation, it can burn an approval that cannot be re-obtained at the moment it is needed. Where the refusal can be induced by the presenter, by offering a near miss to the designated action, approvals can be burned at will: a denial of service aimed at the approving human rather than at the service, and one that appears in records as correct fail-closed behavior. A published example of this defect and its correction, including the rule that a refusal must not consume, appears in [I-D.thallapelly-oasnt-caid]. Stating the constraint as a property over outcomes rather than a step order constrains every correct ordering without prescribing one.¶
The phrase "verifiable ... from conveyed or locally cached material" in R10 is not to be read as "a signature is present." Offline verification presupposes locally selected or cached trust anchors, the binding of the evidence to its authorization and enrollment context, a revocation or status view, and a freshness policy scaled to the consequence class of the action; where these inputs are absent, or staler than the configured bound for the consequence class, enforcement refuses (see R3 and R7).¶
At-most-once admission bounds authorization; it does not resolve an indeterminate post-dispatch outcome. Where the effect of an admitted action may already have occurred, a solution reconciles the original attempt and MUST NOT treat the same authorization evidence as permission for a blind retry.¶
Where authority is long-lived, or where audit records must remain verifiable over a multi-year retention period, the long-term resistance of the chosen cryptographic mechanisms, including under a future quantum-capable adversary, is a consideration for any solution; data and signatures recorded today may need to remain unforgeable for the lifetime of the audit obligation.¶
[Note to the RFC Editor: please remove this section before publication, per the practice described in RFC 7942.]¶
This section records the status of known implementations of the requirements in this document at the time of posting, based on reports by the implementers.¶
EMILIA Protocol (reported by Iman Schrock, July 2026): EMILIA's current implementation exercises the separate-human-role, exact-action and acting-for binding, offline-verification-input, fail-closed-role, and atomic one-time-admission portions of R10. It remains conditional/partial on carrying the human-authorization designation monotonically through the WIMSE/OAuth delegation chain, because the current host-format mapping does not yet carry that designation.¶
OASNT (reported by Arun Thallapelly on the WIMSE mailing list, August 2026): exact-action binding met via three digests (the action and its arguments, the exact bytes displayed to the approver, and a fingerprint binding the token to one concrete request), with cross-pointing of an approved token to another action recorded as a measured refusal. Offline verifiability met with the preconditions applied: enrollment refuses outright when attestation material cannot be obtained, staleness is policy-bounded, and absence of evidence is the weakest state, never an intermediate one. Fail-closed designation met, including a deployment-time variant in which a route declaring no assurance floor is refused at startup. At-most-once admission met in the implementation, and in the published profile as of draft-thallapelly-oasnt-caid-01. In-chain designation carriage NOT MET and not currently attempted: the designation lives in relying-party route policy rather than traveling in delegated authority. Two independent implementations of different architectures stopping at the same clause suggests the gap lies in what current host formats can express rather than in either implementation.¶
The author maintains an implementation exercising all ten requirements; details are deferred to mechanism-track documents.¶
This document has no IANA actions.¶
The author thanks Iman Schrock (EMILIA Protocol) for an implementation-grounded review of the -01 execution-time human-authorization requirement, whose clarifications shaped the R10 refinements and the corresponding security considerations in this revision, for the first-contact continuity-amortization note, and for contributing the EMILIA implementation report. Thanks also to Barak Shelef and to Songbo Bu for the ambient-authority bypass review on the WIMSE list, which produced the sole-authority assumption in the Non-Goals section, and to Arun Thallapelly (OmniArx) for the published consumption example, the OASNT implementation report, and the display-fidelity refinement.¶