Summary
- A proposed agent-routing policy requires more than a successful check at each delegation hop: the value handed off must equal the value the next party says it received, inside an authenticated relation.
- Its own 1-to-1 and 3-to-2 example passes two local
NO_BROADERchecks while providing no valid chain between them.
Imagine two agents reporting clean delegation checks. The first received authority value 1 and passed on 1. The second received 3 and narrowed it to 2. Each local check says the outgoing value is no broader than the incoming one. The dashboard could be green twice. The chain is still fiction: nothing connects the first agent’s 1 to the second agent’s 3.
That is the deliberately small counterexample in revision 03 of Sumit P. Ahuja’s A Policy Grammar for Inter-Domain Agent Routing, submitted on 20 October. It is an individual Internet-Draft, not an IETF-approved standard. Its sharpest contribution is a test of what a string of local approvals can honestly prove.
The draft proposes four kinds of policy attribute. A domain may reduce its willingness to accept work without becoming unreachable. It may rank its own endpoints while leaving the counterparty free to choose. Two parties may use a policy tag whose meaning exists only in their agreement. Those three declarations are bilateral. The fourth, chain validity, is the one designed for a claim that survives multiple delegations. Calling all four “policy” does not make all four portable evidence of authority.
For a chain longer than one hop, every local comparison must return NO_BROADER. That is only the first condition. The value emitted at one hop must be the same value received at the next, and that identity must sit inside the authenticated relation joining the parties. The comparisons must also use the same immutable profile definition, relation rule and, where relevant, finite-domain identity. Finally, the “no broader” relation has to compose: its transitivity must follow from the definition or be mechanically established. Merely asserting transitivity in a profile buys no chain-wide result.
The arithmetic example exposes the missing middle term. The first hop’s 1 and the second hop’s 3 cannot be stitched together by displaying two successful checks in sequence. Even identical-looking values would be weak evidence if their connection were stated outside the authenticated handoff. A party could otherwise present unrelated hop records as one chain. The draft requires that binding from another layer; it does not generate the evidence artifact itself.
It also distinguishes a failed comparison from one that cannot be completed. BROADER means the proposed delegation exceeded the allowed relation. UNDECIDED means the required comparison is unavailable or ambiguous. Neither result authorizes acceptance. A locally successful comparison under a relation that cannot support a chain remains LOCAL_ONLY. These are useful labels for a reviewer because they stop a product from polishing “we checked this hop” into “the whole path is safe.”
There is no deployment tally or incident series in this draft. The change that would settle its practical value is an implementation showing authenticated adjacent-hop binding, fixed profile identities and reproducible transitivity checks across independently run domains. Until then, the document gives operators a precise question to put to a vendor: show the middle value, and show who authenticated it.
Sources · Capability receipts draft · Agentic AI requirements draft
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance





