A Policy Grammar for Inter-Domain Agent Routing
draft-ahuja-agent-routing-policy-02
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Sumit P. Ahuja | ||
| Last updated | 2026-10-04 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
ORCID
GitHub Username: Sup3rn0vaN0w Google Scholar Main Labs Personal site |
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ahuja-agent-routing-policy-02
Individual Submission S. P. Ahuja
Internet-Draft Main Labs
Intended status: Informational 4 October 2026
Expires: 7 April 2027
A Policy Grammar for Inter-Domain Agent Routing
draft-ahuja-agent-routing-policy-02
Abstract
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 7 April 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
Ahuja Expires 7 April 2027 [Page 1]
Internet-Draft Agent Routing Policy October 2026
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. Relationship to Existing Work . . . . . . . . . . . . . . . . 4
4. Scope Comparison Vocabulary . . . . . . . . . . . . . . . . . 5
5. Policy Attributes . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Graduated Self-Deprioritization . . . . . . . . . . . . . 6
5.2. Non-Binding Preference Signalling . . . . . . . . . . . . 6
5.3. Opaque Policy Tags . . . . . . . . . . . . . . . . . . . 7
5.4. Chain Validity Attribute . . . . . . . . . . . . . . . . 8
6. Profile Identity . . . . . . . . . . . . . . . . . . . . . . 8
7. Attribute Declaration . . . . . . . . . . . . . . . . . . . . 8
8. Transitivity Conformance . . . . . . . . . . . . . . . . . . 9
9. Chain Validity Condition . . . . . . . . . . . . . . . . . . 10
10. Requirements and Gaps Addressed . . . . . . . . . . . . . . . 13
11. Security Considerations . . . . . . . . . . . . . . . . . . . 14
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
13.1. Normative References . . . . . . . . . . . . . . . . . . 15
13.2. Informative References . . . . . . . . . . . . . . . . . 15
Changes Since -01 . . . . . . . . . . . . . . . . . . . . . . . . 16
Changes Since -00 . . . . . . . . . . . . . . . . . . . . . . . . 17
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
1. 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.
[INTENTREQ] 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). [GWGAP] 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.
Ahuja Expires 7 April 2027 [Page 2]
Internet-Draft Agent Routing Policy October 2026
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 Section 5 is here because it fails that way.
The attributes are declarations that domains exchange. They are not
the decision logic a domain applies to them. How a domain weighs a
counterparty's declarations, and what it chooses as a result, remains
its own and is not specified here.
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.
2. 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 [RFC2119] [RFC8174] 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 Section 6. A profile is not
global; two hops in one chain may name different profiles, with
the consequence stated in Section 9.
Attenuation relation: The relation a profile defines between two
Ahuja Expires 7 April 2027 [Page 3]
Internet-Draft Agent Routing Policy October 2026
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.
3. 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.
[INTENTREQ] and [GWGAP] are the documents this mechanism answers.
Section 10 states which requirements and gaps each part of the
grammar addresses and which constrain it.
[BCR] supplies the scope-comparison vocabulary and the chain-
composition rules this document uses. They are adopted, not
extended; see Section 4. [BINDING] 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.
[AGENTICREQ] Section 4 takes the opposite view, stating that crossing
an administrative boundary "adds no new protocol requirement beyond
authentication and authorization", and assigns the authorization
requirements it states to the OAuth and WIMSE working groups. This
document disagrees for the reason in the preceding paragraph. The
policy a domain expresses over onward delegation is not an
authorization decision, and none of those requirements carries it.
[AINDEPLOY] reaches the same conclusion from deployment: it describes
the inter-domain phase as requiring new protocol design currently
under research (Section 4.3), and lists "inter-domain policy and
governance" as the complexity that phase adds (Table 3).
[ROSENBERG] Section 3.3.2 treats routing between agents as the
invoking agent's decision, made on information the invoked agent
supplies about itself, such as language and channel capability. This
document adds the policy a domain expresses about that decision when
the agents sit in different domains.
Ahuja Expires 7 April 2027 [Page 4]
Internet-Draft Agent Routing Policy October 2026
Whether a claimed transition can later be established by a party that
did not participate in it is treated in [DET], and the evidentiary
weight of records asserting order is treated in [DECREC]. This
document produces no evidence artifacts and makes no ordering or
retrospective-determinability claims.
4. Scope Comparison Vocabulary
This document does not define a comparison vocabulary. It uses the
one published in [BCR] Section 7, and implementers are expected to
read that section. A relying party MAY use a scope verifier
conforming to [BCR] to evaluate the attribute defined in Section 5.4.
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 [BCR] 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
[BCR] 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.
Evaluation, and any refusal it produces, happens at the point a
delegation is offered for acceptance.
Ahuja Expires 7 April 2027 [Page 5]
Internet-Draft Agent Routing Policy October 2026
LOCAL_ONLY is a composition status carried on a decided attenuation
result, separate from that result. It is not a fourth 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.
5. 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 Section 7.
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 [INTENTREQ].
5.1. 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.
5.2. Non-Binding Preference Signalling
A domain advertises a preference among its own endpoints to a
counterparty that will make the selection.
Ahuja Expires 7 April 2027 [Page 6]
Internet-Draft Agent Routing Policy October 2026
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 [INTENTREQ] 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 [INTENTREQ] 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.
5.3. 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 Section 9.
This attribute does not establish that any handling occurred. A tag
is a request under a bilateral agreement, not a receipt.
Ahuja Expires 7 April 2027 [Page 7]
Internet-Draft Agent Routing Policy October 2026
5.4. 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 [INTENTREQ]. 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 Section 8.
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 Section 8 and
Section 9 permit one.
6. 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 [BCR] 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.
7. 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 Section 9. A bilateral attribute has meaning
available only to the parties to an agreement, and Section 9 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.
Ahuja Expires 7 April 2027 [Page 8]
Internet-Draft Agent Routing Policy October 2026
Under this document the attributes in Section 5 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 [BCR] 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 [BCR] and are not restated here.
A profile that makes no transitivity claim is permitted. Its results
are governed by Section 8.
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.
8. Transitivity Conformance
Section 9 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 [INTENTREQ]: 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 [BCR] 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.
The requirement above is a security requirement. A chain-wide
statement drawn from hop comparisons that do not compose asserts a
property no party verified, and a relying party acting on it has been
given a guarantee that was never established. That is why the
prohibition is normative here.
Ahuja Expires 7 April 2027 [Page 9]
Internet-Draft Agent Routing Policy October 2026
Under the applicable composition profile, a locally satisfied result
cannot contribute an effective satisfied result to a dependent
composite claim unless its required dependencies are established in
compatible evaluation contexts. The original per-hop result and its
scope remain recorded. [BINDING] Section 17 states this for
conjunctive composition of verifier results, and this document's
treatment aligns with it. A profile using other composition
semantics needs its own rule; nothing here supplies one.
Compatibility of evaluation contexts concerns how dependencies are
established. It does not relax condition 3 of Section 9, which
requires the relation inputs of adjacent comparisons to be the same.
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. [ATN] 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 Section 7 closes, and
[ATN] is cited here as the practice the requirement addresses rather
than as a competing mechanism.
[AGENTICREQ] states the corresponding requirements in the same
pairwise form. B3-1 requires each delegating agent to present a
credential that does not exceed the scope of the one it received, and
B3-12 requires a receiving party to be able to determine that the
authority conveyed to it does not exceed the authority conveyed to
the hop it received from. B3-3 adds that each credential can be
verified as issued by the delegating agent and that the chain traces
back to the original authorization. Taken together these supply per-
hop non-exceeding and verifiable linkage between hops. Whether a
chain-wide statement follows depends on whether the scope relation
composes, which none of them addresses. These requirements are cited
for their structure only. [AGENTICREQ] assigns them to other working
groups, and this document does not claim to satisfy them.
9. 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.
Ahuja Expires 7 April 2027 [Page 10]
Internet-Draft Agent Routing Policy October 2026
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. This is a structural identity case, and it
supplies no authorization or freshness decision of its own. A valid
chain of length zero says that no containment check was needed. It
says nothing about whether the holder may act.
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. for every adjacent pair of hops h(i) and h(i+1), the value
emitted by h(i) and the value received by h(i+1) are the same
value, and that identity is established inside the authenticated
relation that binds the two hops, together with the delegation
context they share;
3. 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
4. that transitivity basis is definition-derived or mechanically-
checkable.
Condition 2 is what makes the induction sound, and an immutable
relation alone does not supply it. Take the transitive relation in
which an emitted value is no broader than the value received. A hop
receiving 1 and emitting 1 returns NO_BROADER. A hop receiving 3 and
emitting 2 returns NO_BROADER. Both are governed by the same profile
under the same relation, so conditions 1, 3 and 4 hold, and nothing
whatever follows about a chain: the first hop emits 1 and the second
receives 3, so there is no shared intermediate value for transitivity
to act on. Transitivity composes a relation across a common middle
term, and a verifier presented with hop records has no chain until
that term is shown to be common.
Authentication carries the same weight as identity here. A value
correctly named on both sides of a boundary, but named outside the
authenticated relation binding the two hops, is an unauthenticated
assertion that the hops join, and a party able to present two
Ahuja Expires 7 April 2027 [Page 11]
Internet-Draft Agent Routing Policy October 2026
unrelated hop records can assert a chain that does not exist. The
binding identifies the specific value on the other side and sits
inside the relation, not beside it.
This document requires that relation and does not provide it. The
authenticated relation binding adjacent hops is supplied by another
layer, consistent with Section 3: this document produces no evidence
artifacts. Where no such layer is present, no chain-wide statement
is available under this document.
Condition 3 is not a convenience either. 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, and MUST NOT
treat two composable profiles as composing with each other.
A mediator that terminates a delegation and originates a new one
emits a value it did not compare against the value it received.
Condition 1 fails at that hop, and no chain-wide statement spans it.
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 Section 4. 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.
Ahuja Expires 7 April 2027 [Page 12]
Internet-Draft Agent Routing Policy October 2026
10. 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 [INTENTREQ] is the requirement this document answers. The
attributes in Section 5 are the means by which cross-boundary
interoperation is policy-controlled, and Section 9 is the means by
which that control survives onward delegation.
[GWGAP] 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 11.
[GWGAP] 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 Section 8 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.
Ahuja Expires 7 April 2027 [Page 13]
Internet-Draft Agent Routing Policy October 2026
11. 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 Section 5 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. [BCR] 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. Section 6 exists for that
reason.
Section 9 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 Section 4,
Section 8, or Section 9, 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.
Ahuja Expires 7 April 2027 [Page 14]
Internet-Draft Agent Routing Policy October 2026
12. 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 [BCR] and are registered, if
at all, by that document. A future revision may request a registry
for attribute types should the vocabulary stabilise.
13. References
13.1. Normative References
[BCR] Schrock, I., "Bounded Capability Receipts and Durable
Spend Control for Agent Actions", Work in Progress,
Internet-Draft, draft-schrock-ep-bounded-capability-
receipts-06, 9 September 2026,
<https://datatracker.ietf.org/doc/html/draft-schrock-ep-
bounded-capability-receipts-06>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
13.2. Informative References
[AGENTICREQ]
Reddy.K, T., Sarker, Z., and K. Yao, "Agentic AI Use Cases
and Requirements", Work in Progress, Internet-Draft,
draft-agentic-ai-usecases-requirements-02, 26 August 2026,
<https://datatracker.ietf.org/doc/html/draft-agentic-ai-
usecases-requirements-02>.
[AINDEPLOY]
Feng, C., "Agentic Intent Network (AIN): Applicability and
Deployment Scenarios", Work in Progress, Internet-Draft,
draft-feng-nmrg-ain-deployment-00, April 2026,
<https://datatracker.ietf.org/doc/html/draft-feng-nmrg-
ain-deployment-00>.
[ATN] Somoza, E., "Agent Trust Negotiation: Capability,
Delegation, and Provenance Binding for AI Agents", Work in
Progress, Internet-Draft, draft-somoza-dmsc-atn-agent-
Ahuja Expires 7 April 2027 [Page 15]
Internet-Draft Agent Routing Policy October 2026
trust-negotiation-00, 29 May 2026,
<https://datatracker.ietf.org/doc/html/draft-somoza-dmsc-
atn-agent-trust-negotiation-00>.
[BINDING] Bu, S., "Security Principal and Verifier Binding for Agent
Communication Protocols", Work in Progress, Internet-
Draft, draft-bu-agentproto-security-principal-binding-07,
15 September 2026, <https://datatracker.ietf.org/doc/html/
draft-bu-agentproto-security-principal-binding-07>.
[DECREC] B, B., "Signed Decision Records for Agent Authorization:
Disclosures, Entry Emission, and Ordering Evidence", Work
in Progress, Internet-Draft, draft-bradleyb-audit-
decision-records-00, 13 August 2026,
<https://datatracker.ietf.org/doc/html/draft-bradleyb-
audit-decision-records-00>.
[DET] Wadkins, D., "Independent Determinability of Agent
Actions", Work in Progress, Internet-Draft, draft-wadkins-
agentproto-action-determinability-00, 10 September 2026,
<https://datatracker.ietf.org/doc/html/draft-wadkins-
agentproto-action-determinability-00>.
[GWGAP] Dunbar, L., Wang, Y., Schrock, I., and B. Liu, "Deployment
Scenarios and Gap Analysis for AI Agent Gateway", Work in
Progress, Internet-Draft, draft-dunbar-dmsc-gw-scenarios-
gap-analysis-04, 14 August 2026,
<https://datatracker.ietf.org/doc/html/draft-dunbar-dmsc-
gw-scenarios-gap-analysis-04>.
[INTENTREQ]
Feng, C., "Requirements for Intent Routing in Multi-Agent
Systems at Internet Scale", Work in Progress, Internet-
Draft, draft-feng-dmsc-intent-routing-requirements-00, 14
August 2026, <https://datatracker.ietf.org/doc/html/draft-
feng-dmsc-intent-routing-requirements-00>.
[ROSENBERG]
Rosenberg, J. and C. Jennings, "Framework, Use Cases and
Requirements for AI Agent Protocols", Work in Progress,
Internet-Draft, draft-rosenberg-agentproto-usecases-00, 4
July 2026, <https://datatracker.ietf.org/doc/html/draft-
rosenberg-agentproto-usecases-00>.
Changes Since -01
Ahuja Expires 7 April 2027 [Page 16]
Internet-Draft Agent Routing Policy October 2026
* Stated in Section 9 that the authenticated relation binding
adjacent hops is supplied by another layer, and that this document
requires it and does not provide it.
* Stated that a valid chain of length zero is a structural identity
case and supplies no authorization or freshness decision.
* Adopted revised composition wording in Section 8: the rule applies
under the applicable composition profile, and requires
dependencies established in compatible evaluation contexts.
Clarified that this does not relax the same-relation requirement
for chain-wide statements.
* Stated that a terminating mediator breaks condition 1 at its hop.
* Answered, in Section 3, the position that crossing an
administrative boundary adds no protocol requirement beyond
authentication and authorization. Added deployment evidence and
the routing use case this document extends.
* Cited the pairwise attenuation requirements and chain traceback
requirement of other work beside the existing discussion of
current practice in Section 8.
* Stated that the attributes are declarations, not decision logic,
and that evaluation happens when a delegation is offered for
acceptance.
Changes Since -00
* Added authenticated adjacency as an explicit condition of the
chain validity induction in Section 9, with the counterexample
that motivates it. The previous text treated an immutable
attenuation relation as sufficient for the induction; it is
necessary and not sufficient.
* Restated the composition text in Section 8. A raw per-hop result
stays recorded as decided; what it cannot do is contribute an
effective satisfied result to a dependent composite claim. Noted
that the cited rule is for conjunctive composition and does not
generalise to other composition semantics.
* Rested the non-elevation requirement in Section 8 on its security
argument. Alignment with other work is noted as alignment.
* Corrected Section 4: LOCAL_ONLY would be a fourth attenuation
result, not a third.
Ahuja Expires 7 April 2027 [Page 17]
Internet-Draft Agent Routing Policy October 2026
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 Section 8
relies on, supplied the counterexample that showed the induction in
Section 9 unsound without an authenticated adjacency requirement,
reviewed the composition text, and identified that a valid chain of
length zero supplies no authorization decision and that the relation
binding adjacent hops must be supplied by another layer. Iman
Schrock additionally corrected the count of attenuation results in
Section 4. Chong Feng stated the requirements this mechanism
answers. Linda Dunbar, YiFei Wang, Iman Schrock and Bing Liu
identified the gap in policy expression that Section 10 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.
Author's Address
Sumit P. Ahuja
Main Labs
United States of America
Email: sumit@mainlabs.ai
URI: https://orcid.org/0009-0009-3487-5001
Ahuja Expires 7 April 2027 [Page 18]