Main Labs

United States of America sumit@mainlabs.ai https://orcid.org/0009-0009-3487-5001

ART Individual Submission agents delegation inter-domain policy routing Agent tasks are delegated across organizational boundaries. Existing work specifies how agents are identified, discovered, and described, states requirements for cross-domain isolation and authorization, and identifies the absence of a mechanism for expressing capability policy as a gap. This document defines four policy attributes for inter-domain agent delegation, the declarations each attribute carries, and a validity condition on delegation chains that no party establishes by observing the whole chain. Whether independently chosen policies converge is analysed in separate work.

Introduction A delegation crosses an organizational boundary when the party receiving a task is operated by someone other than the party sending it. The sender then has no view of what the task encounters downstream, and the receiver is acting under policy the sender cannot inspect. requires that a coordination substrate let an organization isolate its capability namespace, and that interoperation across organizational boundaries be explicitly authorized and policy-controlled (REQ-13). Section 7.2 states the same absence as a gap: capability descriptions say what an agent can do and do not say who may discover or invoke it under what conditions, and there is no standard mechanism for expressing, distributing, and enforcing those constraints. This document specifies a mechanism for the expression half of that gap. The test applied throughout is whether a behaviour must be specified to survive crossing a boundary, or whether a domain may decide it alone. An attribute a domain can implement internally, with no counterparty obliged to read it, does not belong in a protocol. Each attribute in is here because it fails that way. Domains exist for administrative reasons. Data residency law, sovereign compute programmes, sunk regional infrastructure, and organizations that will not route work through a competitor's systems all produce boundaries that no improvement in agent capability removes. This document takes no position on whether specialised or general agents prevail.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Domain:

A jurisdiction of policy ownership. A domain owns policy over the agents it operates and over the delegations it accepts and emits. The term carries no claim about knowledge, capability, or subject-matter expertise. Two domains may operate identical agents and hold opposite policies.

Delegation:

The transfer of a task from one agent to another.

Delegation chain:

The ordered sequence of delegations by which a task reaches its current holder. A chain of length zero is a task that has not been delegated.

Hop:

A single delegation, together with the domains on either side of it.

Governing profile:

The immutable definition, agreed between the parties to a hop, under which attribute values are compared. Profile identity is subject to . A profile is not global; two hops in one chain may name different profiles, with the consequence stated in .

Attenuation relation:

The relation a profile defines between two values of an attribute, under which one value is no broader than another.

Relying party:

A party evaluating a hop or a chain in order to accept, forward, or refuse a task.

Relationship to Existing Work Agent identity, discovery, and capability advertisement are specified elsewhere and are not restated here. This document assumes an agent can be named, located, and described. and are the documents this mechanism answers. states which requirements and gaps each part of the grammar addresses and which constrain it. supplies the scope-comparison vocabulary and the chain-composition rules this document uses. They are adopted, not extended; see . states the same non-elevation property for composed verifier results generally, and is cited where this document relies on it. Authorization frameworks answer whether a party may act. An authorization decision does not identify who holds a task after the permitting credential expired, and it does not identify who is accountable for a task two delegations downstream of the party that was authorized. Policy over delegation is not a generalised form of authorization and does not subsume it. Whether a claimed transition can later be established by a party that did not participate in it is treated in , and the evidentiary weight of records asserting order is treated in . This document produces no evidence artifacts and makes no ordering or retrospective-determinability claims.

Scope Comparison Vocabulary This document does not define a comparison vocabulary. It uses the one published in Section 7, and implementers are expected to read that section. A relying party MAY use a scope verifier conforming to to evaluate the attribute defined in . The summary below identifies only what this document relies on. Membership and attenuation are separate decisions. Membership returns IN_SCOPE, OUT_OF_SCOPE, or UNDECIDED. Attenuation returns NO_BROADER, BROADER, or UNDECIDED. This document is concerned with attenuation. Where an attribute has mandatory components, the composite rules of Section 7 apply unchanged: any BROADER component makes the composite broader, otherwise any UNDECIDED component makes the composite UNDECIDED, each component result remains visible, and a missing component is not a successful comparison. An UNDECIDED attenuation result states why. Two reasons defined in are relied on here, and they are relied on because a relying party does different things with them.

NO_COMPARISON_RELATION:

The verifier holds the exact governing profile and that profile supplies no applicable relation for the component and values reported. This is absence of a relation under that profile and is not a claim that comparison is globally impossible. No party holding different inputs changes it, so the relying party halts.

PROFILE_NOT_HELD:

The exact governing profile definition is unavailable to the deciding verifier. Its absence does not establish that the profile defines no relation. Retrieval of the exact definition, or re-evaluation by a verifier accepted under relying-party policy, may remedy it, so the relying party MAY route the evaluation.

These two do not exhaust the causes of UNDECIDED, and another cause MUST NOT be reported as either of them. Until a required current comparison succeeds, the relying party refuses. LOCAL_ONLY is a composition status carried on a decided attenuation result, separate from that result. It is not a third attenuation value and not a substitute for UNDECIDED. A negative local result stays negative whatever its composition status. UNDECIDED describes an unavailable comparison. It is not the execution outcome INDETERMINATE, and the two MUST NOT be reported interchangeably.

Policy Attributes Each attribute is stated in the same form: what the advertising domain asserts, what a receiving domain is obliged to do, what it is not obliged to do, and what the attribute does not establish. An attribute value carried on a delegation MUST be accompanied by the declarations in . Attribute values are compared by matching declared identifiers under the governing profile. Evaluating an attribute MUST NOT require any party to interpret the semantics of the task, consistent with REQ-10 and REQ-11 of .

Graduated Self-Deprioritization A domain advertises a graduated reduction in its willingness to receive delegations, without becoming unreachable. The advertising domain asserts that delegations to the named agents remain acceptable and that it prefers they be sent elsewhere where an alternative exists. A receiving domain MUST treat the advertisement as ordered against other advertisements from the same domain under the governing profile. It MUST NOT treat the advertisement as a refusal, and MUST NOT require the advertising domain to justify the value. This attribute does not establish capacity, health, or load. A domain may deprioritize itself for contractual reasons unrelated to its state. A relying party that reads load from this attribute is reading something the attribute does not carry.

Non-Binding Preference Signalling A domain advertises a preference among its own endpoints to a counterparty that will make the selection. The advertising domain asserts a ranking over agents it operates. The counterparty MAY use the ranking and MAY disregard it. A domain MUST NOT treat its own preference as having bound the counterparty's choice, and MUST NOT refuse a delegation solely because the counterparty selected a lower-ranked endpoint. REQ-7 of requires that any selection depending on real-time state be made by the entity holding that state. This attribute is conformant because it is not a selection. The advertising domain states a preference derived from what it knows about its own endpoints; the decision remains with the party holding the requesting context. A binding form would place the decision with a party that cannot see the inputs it needs, which is the failure REQ-7 excludes. REQ-8 of defines a mode in which the infrastructure returns multiple matching handlers and the requester chooses. That mode exists for endpoint reachability rather than for preference, and this document does not claim otherwise. The attribute is usable within it. This attribute does not establish that the ranked endpoints are interchangeable, and establishes nothing about endpoints operated by other domains.

Opaque Policy Tags A domain attaches a tag whose meaning is agreed bilaterally with the receiving domain and is not defined by this document. The advertising domain asserts that the tag is drawn from the vocabulary agreed with the receiver. A receiving domain that holds the agreement MUST apply the agreed handling. A receiving domain that does not hold the agreement MUST forward the tag unaltered if it forwards the delegation at all, and MUST NOT infer meaning from an unrecognised tag. A tag's meaning is not available to parties outside the agreement, including parties on the same chain. This is the property that makes tags usable for compliance, residency, and priority arrangements a domain will not publish, and it is the property that excludes them from . This attribute does not establish that any handling occurred. A tag is a request under a bilateral agreement, not a receipt.

Chain Validity Attribute A domain attaches a value stating the class of onward delegation it considers commercially coherent for this task. Values are drawn from an aggregable hierarchical namespace supporting prefix matching, as required by REQ-12 of . That namespace is used as substrate and is not redefined here. A profile MAY define containment as prefix containment over that namespace, in which case transitivity follows by construction and the basis is definition-derived under . A receiving domain MUST NOT emit an onward delegation whose value returns BROADER against the value it received. A receiving domain MAY emit an onward delegation whose value returns NO_BROADER. This attribute does not establish that a chain is authorized, safe, or correct. It establishes that each hop was no broader than its predecessor, and a chain-wide statement only where and permit one.

Profile Identity Every profile identifier used to govern a comparison MUST identify immutable comparison semantics. An identifier fixed by immutable standards text satisfies this. Any other profile identifier MUST be content-addressed. A mutable alias or version label alone is insufficient. This requirement is taken from Section 7 and applies here unchanged, because a chain-wide statement made under a profile that can change afterwards is not a statement about anything. A relying party MUST pin the exact profile definition selected by an identifier and MUST refuse if that definition cannot be resolved unambiguously or has changed.

Attribute Declaration An attribute is either chain-checkable or bilateral. A chain-checkable attribute has values compared under a governing profile and is the subject of . A bilateral attribute has meaning available only to the parties to an agreement, and excludes it. Every attribute definition MUST declare which it is. The declaration is a field of the definition. A definition that states the property in prose without declaring it is not conformant, because a party evaluating a chain reads fields. Under this document the attributes in are declared as follows: graduated self-deprioritization, bilateral; non-binding preference signalling, bilateral; opaque policy tags, bilateral; chain validity, chain-checkable. A profile defining an attenuation relation for a chain-checkable attribute MUST state whether that relation is reflexive and whether it is transitive, and MUST classify the basis of any transitivity claim as definition-derived, mechanically-checkable, or asserted, as specified in Section 7. The requirements on a mechanically-checkable claim, including the finite domain, the deterministic procedure, the establishment record, and the disclosure of reliance mode, are those of and are not restated here. A profile that makes no transitivity claim is permitted. Its results are governed by . A profile whose relation is not reflexive MUST state that an unchanged value will be refused. A domain forwarding a task without narrowing it under such a profile is refused, and that consequence is a design choice the profile makes rather than an error.

Transitivity Conformance draws a chain-wide statement from per-hop comparisons. A party that verifies each hop concludes that the value at the end of the chain is no broader than the value at its start, without holding the chain entire. This is what allows a chain-wide statement to be reached under REQ-4 and REQ-6 of : no party holds state proportional to the chain, and each comparison is local. The induction is sound only if the relation composes. A relying party MUST NOT promote per-hop comparisons into a chain-wide statement unless transitivity is definition-derived or mechanically established over the profile's complete declared finite domain, as Section 7 requires. A decided comparison under a non-transitive relation, an asserted-transitive relation, or a relation whose transitivity is not claimed is LOCAL_ONLY to its hop. It remains useful evidence about that hop and does not compose. Section 17 states the same property for composed verifier results generally: an aggregate result does not carry a claim stronger than its verified inputs, and a satisfied result does not survive composition when something it depends on is not established. Two independently developed documents arriving at this rule is the reason it is stated here as a constraint rather than as a recommendation. Relations defined by threshold, by rounding, or by table lookup over an incompletely declared domain are commonly not transitive. A profile using such a relation is not thereby non-conformant. Its results are hop-scoped, and LOCAL_ONLY is the conformant way to say so. Current practice does not close this. specifies delegation-chain verification as five steps, of which the second requires each link's scope to be a subset of its parent's. That is pairwise checking. The document states no transitivity property for the relation, classifies no basis for one, and defines no composition rule along the chain. A relying party following those steps has verified every link and has no stated ground for a statement about the chain. That gap is what the declaration in closes, and is cited here as the practice the requirement addresses rather than as a competing mechanism.

Chain Validity Condition Let a chain consist of hops h(1) through h(n), each carrying a value of a chain-checkable attribute and each governed by a profile. A chain of length zero is valid. The holder has received no delegation and has narrowed nothing, so there is no hop at which containment could fail. A chain of length one requires a current NO_BROADER comparison at that hop. It requires no transitive induction, and the transitivity basis of its profile does not affect the result. A chain of length greater than one is valid for an attribute when all of the following hold:

1. for every hop h(i), the comparison of the value emitted by h(i) against the value received by h(i) returns NO_BROADER under the profile governing h(i);
2. every adjacent comparison used for the chain-wide statement uses the same immutable profile definition, the same relation-rule definition, the same finite-domain identity where applicable, and the same transitivity basis; and
3. that transitivity basis is definition-derived or mechanically-checkable.

Condition 2 is not a convenience. Transitivity established separately for two different relations does not establish that those relations compose, and this document defines no cross-relation composition rule. Where a chain changes any of those relation inputs, the decided comparisons on either side of that boundary remain LOCAL_ONLY across it, and no chain-wide statement is available even though every hop was decided and every profile claimed transitivity. A relying party MUST report that outcome rather than treating two composable profiles as composing with each other. Bilateral attributes are excluded. A relying party MUST NOT evaluate chain validity over a bilateral attribute, and MUST NOT infer from a valid chain that any bilateral attribute was honoured at any hop. Where a comparison at a hop returns UNDECIDED, the relying party proceeds according to the reason as described in . Under NO_COMPARISON_RELATION the chain is not valid and the relying party halts. Under PROFILE_NOT_HELD the chain is not valid to this relying party, which MAY route the evaluation to a party holding the exact definition. A relying party MUST NOT treat a chain as valid by default in either case, and MUST NOT substitute LOCAL_ONLY for an unavailable comparison. A failure to establish composition does not convert a decided hop result into UNDECIDED. The hop result stands with its LOCAL_ONLY composition status, and the chain-wide statement is refused. A structural statement about a chain and a comparison result MUST NOT be combined into an overall validity claim unless both reports travel with the claim, including their decidability and composition limits.

Requirements and Gaps Addressed This section states the relationship between this mechanism and the documents it answers. It claims no conformance on behalf of any implementation. REQ-13 of is the requirement this document answers. The attributes in are the means by which cross-boundary interoperation is policy-controlled, and is the means by which that control survives onward delegation. Section 7.2 names the absence of a standard mechanism for expressing, distributing, and enforcing capability visibility policy. This document addresses expression. It does not address distribution, and it is not an enforcement point; see . Section 7.4 identifies binding agent interactions to organizational identity and authorization context as that document's highest-priority candidate. This document does not supply that binding. A policy grammar is one component of it and is not a substitute for it. REQ-12 supplies the namespace on which the chain-checkable attribute is defined. REQ-7 and REQ-8 constrain the form of non-binding preference signalling. REQ-4 and REQ-6 are the reason exists. A chain-wide statement is drawn from local per-hop comparisons precisely so that no party holds chain-scale state. REQ-10 and REQ-11 constrain evaluation to declared identifiers, with no inference required of any evaluating party. REQ-14 requires bounded convergence. This document specifies the attributes and the per-hop and chain semantics. Whether domains setting these attributes independently, and according to their own interests, reach a stable global outcome is analysed in separate work and is out of scope here.

Security Considerations Opaque policy tags are a channel between domains holding a bilateral agreement. The channel is intended and its capacity is bounded by the agreed vocabulary, but a vocabulary agreed for one purpose can carry information for another. Domains that forward tags they do not understand, as requires, are forwarding content they cannot inspect. Graduated self-deprioritization can be advertised falsely. A domain that deprioritizes itself while remaining reachable may be shedding work it has accepted an obligation to perform, and a domain that never deprioritizes itself may be concealing saturation. The attribute carries no evidence either way. A profile that classifies a transitivity basis as definition-derived for a relation that does not compose causes relying parties to draw chain-wide statements from per-hop comparisons that do not support them. The resulting error is silent, which makes it more damaging than a profile that claims nothing. A declared basis is a claim by the profile's author. Section 7 states the trust and freshness conditions under which a mechanical establishment record may be relied on, and those conditions apply here. A mutable profile identifier permits the semantics of a past comparison to be changed after the fact. exists for that reason. places no bound on chain length. A relying party evaluating a chain performs at least one comparison per hop, and a chain presented to it may be arbitrarily long. A relying party SHOULD bound the number of hops it will evaluate, and MUST NOT treat exhaustion of that bound as a valid chain. The bound is a local resource decision and is not a property of the chain, so two relying parties applying different bounds to the same chain may reach different results and neither is wrong. The default on an unresolved evaluation is to refuse. A relying party that cannot evaluate a chain, for any reason in , , or , MUST NOT forward or accept the task on the basis of that evaluation. The isolation REQ-13 requires is not supplied by this document. These attributes express policy across a boundary that some other mechanism establishes, and a valid chain is not an access-control decision. A deployment that treats attribute evaluation as enforcement has substituted a policy statement for an enforcement point.

IANA Considerations This document requests no IANA actions. Attribute types are carried in profiles agreed between parties and are not registered at this revision. Comparison results, reason codes, composition status, and transitivity basis values are those of and are registered, if at all, by that document. A future revision may request a registry for attribute types should the vocabulary stabilise.

References Normative References EMILIA Protocol, Inc. Informative References Strakewright 11 AI Blockchain Developments LLC

Acknowledgements Iman Schrock authored the scope-comparison vocabulary and the chain-composition rules this document adopts. Songbo Bu stated the non-elevation property for composed verifier results, which relies on. Chong Feng stated the requirements this mechanism answers. Linda Dunbar, YiFei Wang, Iman Schrock and Bing Liu identified the gap in policy expression that maps to. Mirja Kuehlewind posed the test this document uses to select its attributes: what must be standardised to survive crossing a domain boundary, as distinct from what a domain may decide alone. Douglas Wadkins and Henri Sirkkavaara sharpened, on the agentproto mailing list, the distinction between evidence of one transition and evidence of another, which is why this document states what its attributes do not establish. Bradley B distinguished correspondence from precedence in records, cited here for the limit it places on what a chain report can claim.