



Network Working Group                                        Y. Yan, Ed.
Internet-Draft                                               S. Sun, Ed.
Intended status: InformationalInstitute of Computing Technology, Chinese Academy of Sciences
Expires: 11 October 2026                                          Q. Gao
                                                                  Huawei
                                                             M. Liu, Ed.
          Institute of Computing Technology, Chinese Academy of Sciences
                                                                X. Zhang
        Computer Network Information Center, Chinese Academy of Sciences
                                                            9 April 2026


          Security Requirements for Intent-based Agent Routing
             draft-yan-iba-routing-security-requirements-01

Abstract

   This document specifies security requirements for intent-based agent
   routing.  It defines a security architecture, phase-specific attack
   surface analysis, and normative protections for the Registration,
   Resolution, and Dispatch phases of routing.  It also describes a
   secure operational process and an annotated interaction flow for
   protecting routing decisions, intent privacy, and capability
   integrity.

   Intent-based routing enables autonomous agents to collaborate based
   on semantic intent rather than static addresses, but this model
   introduces new security risks beyond those addressed by traditional
   channel protection and endpoint authentication.  Existing mechanisms
   such as Transport Layer Security (TLS) and Public Key Infrastructure
   (PKI) verify identity and protect transport, but do not constrain
   what an agent claims to be capable of, nor do they protect the
   semantic content of intent queries during routing.  This document
   establishes requirements to mitigate these risks and provides a
   comprehensive security framework for intent-based agent networks.

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/.






Yan, et al.              Expires 11 October 2026                [Page 1]

Internet-Draft     Intent-based Agent Routing Security        April 2026


   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 11 October 2026.

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
   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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Background and Motivation . . . . . . . . . . . . . . . .   3
     1.2.  Scope and Non-Goals . . . . . . . . . . . . . . . . . . .   4
     1.3.  Document Contributions  . . . . . . . . . . . . . . . . .   4
     1.4.  Requirements Language . . . . . . . . . . . . . . . . . .   5
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   5
   3.  System Architecture and Security Attack Surface . . . . . . .   6
     3.1.  System Architecture . . . . . . . . . . . . . . . . . . .   6
     3.2.  Attack Surface Analysis . . . . . . . . . . . . . . . . .   8
       3.2.1.  Registration Phase Attack Surface . . . . . . . . . .   8
       3.2.2.  Resolution Phase Attack Surface . . . . . . . . . . .   9
       3.2.3.  Dispatch Phase Attack Surface . . . . . . . . . . . .  10
   4.  Security Requirements . . . . . . . . . . . . . . . . . . . .  10
     4.1.  Registration Phase Requirements . . . . . . . . . . . . .  10
       4.1.1.  REQ-R-01: Mutual Authentication for Registration  . .  10
       4.1.2.  REQ-R-02: Attested Capability Advertisement . . . . .  10
       4.1.3.  REQ-R-03: Semantic Namespace Enforcement  . . . . . .  11
       4.1.4.  REQ-R-04: Routing Table Audit Logging . . . . . . . .  11
     4.2.  Resolution Phase Requirements . . . . . . . . . . . . . .  11
       4.2.1.  REQ-Q-01: Leader Agent Authentication . . . . . . . .  11
       4.2.2.  REQ-Q-02: Intent Minimization . . . . . . . . . . . .  11
       4.2.3.  REQ-Q-03: Privacy-Preserving Intent Matching  . . . .  12
       4.2.4.  REQ-Q-04: Signed Route Response . . . . . . . . . . .  12
     4.3.  Dispatch Phase Requirements . . . . . . . . . . . . . . .  12
       4.3.1.  REQ-D-01: Route Response Verification . . . . . . . .  12



Yan, et al.              Expires 11 October 2026                [Page 2]

Internet-Draft     Intent-based Agent Routing Security        April 2026


       4.3.2.  REQ-D-02: Direct End-to-End Encrypted Session . . . .  12
       4.3.3.  REQ-D-03: Transport Encryption for All Signaling  . .  12
   5.  Secure Routing Process  . . . . . . . . . . . . . . . . . . .  13
     5.1.  Phase 1: Trusted Registration . . . . . . . . . . . . . .  13
     5.2.  Phase 2: Privacy-Preserving Resolution  . . . . . . . . .  14
     5.3.  Phase 3: Verifiable Dispatch  . . . . . . . . . . . . . .  14
   6.  Secure Interaction Flow . . . . . . . . . . . . . . . . . . .  15
   7.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .  17
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  18
     10.2.  Informative References . . . . . . . . . . . . . . . . .  19
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  19
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

1.  Introduction

   Intent-based agent routing represents a fundamental shift in network
   architecture.  Autonomous agents powered by artificial intelligence
   are increasingly capable of reasoning, planning, and executing tasks
   on behalf of users or other agents.  Rather than communicating via
   fixed service endpoints or static addresses, these agents express and
   receive requests as high-level semantic intents, which are resolved
   and forwarded by an Agent Gateway (AG) based on capability matching.

1.1.  Background and Motivation

   Traditional networking protocols and security mechanisms—including
   TLS [RFC8446], IPsec, and OAuth 2.0 [RFC6749]—are designed to protect
   the transport layer and verify endpoint identity.  These mechanisms
   assume that communication targets are identified by fixed, pre-known
   addresses.  In intent-based routing, however, this assumption no
   longer holds.  The AG must dynamically select a Partner Agent by
   semantically matching an incoming task intent against a registry of
   advertised capabilities.  This introduces a semantic control plane
   that has no equivalent in traditional network security models.

   Securing the transport channel is therefore necessary but
   insufficient.  Trust decisions in intent-based routing must extend
   beyond identity to encompass the semantic validity of capability
   claims and the confidentiality of intent content.  A standardized
   security framework operating at the intent level is required.








Yan, et al.              Expires 11 October 2026                [Page 3]

Internet-Draft     Intent-based Agent Routing Security        April 2026


1.2.  Scope and Non-Goals

   This document specifies the security architecture, attack surface
   analysis, and normative security requirements for the intent-based
   agent routing framework.  It covers security mechanisms for the three
   phases of the routing lifecycle:

   *  *Registration Phase*: agent registration and capability
      advertisement.

   *  *Resolution Phase*: intent query and semantic matching.

   *  *Dispatch Phase*: routing decision dispatch and end-to-end session
      establishment.

   This document explicitly does *not* cover:

   *  General network-layer defense mechanisms such as DDoS protection
      or firewall policy.

   *  Internal security of Large Language Models or agent reasoning
      engines.

   *  Human-user authentication protocols, except where they directly
      affect routing decisions.

   *  Inter-registry federation or cross-domain trust establishment
      beyond what is specified here.

1.3.  Document Contributions

   This document provides the following:

   1.  *Attack Surface Analysis* (Section 3): A structured analysis of
       security vulnerabilities specific to each phase of the intent-
       based routing lifecycle.  Registration phase surfaces are
       identified as AS-R-01 through AS-R-03; Resolution phase as AS-
       Q-01 through AS-Q-03; Dispatch phase as AS-D-01 through AS-D-02.

   2.  *Security Requirements* (Section 4): Normative per-phase security
       requirements identified as REQ-R-01 through REQ-R-04
       (Registration), REQ-Q-01 through REQ-Q-04 (Resolution), and REQ-
       D-01 through REQ-D-03 (Dispatch).  Each requirement is explicitly
       mapped to the attack surface it addresses.

   3.  *Secure Routing Process* (Section 5): A normative description of
       the three-phase secure routing operation, specifying the
       applicable requirements and concrete procedures for each phase.



Yan, et al.              Expires 11 October 2026                [Page 4]

Internet-Draft     Intent-based Agent Routing Security        April 2026


   4.  *Secure Interaction Flow* (Section 6): A complete annotated
       message sequence diagram showing the full secure routing
       lifecycle, with each security action labeled by its corresponding
       requirement identifier.

1.4.  Requirements Language

   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.

2.  Conventions and Definitions

   The following terms are used throughout this document.  Terms
   specific to the base routing framework are defined below for
   convenience, along with security-specific terms.

   Leader Agent (LA)
      An agent that initiates a task by submitting an Intent Descriptor
      to the Agent Gateway.  The LA is responsible for generating the
      intent vector locally, signing intent request messages, and
      establishing a direct session with the selected Partner Agent
      after route resolution.  Also referred to as Source Agent in
      related literature.

   Partner Agent (PA)
      An agent that receives and executes a forwarded task.  The PA MUST
      register its capabilities with the Agent Gateway via an
      authenticated Capability Advertisement before receiving any task
      requests.  Also referred to as Target Agent in related literature.

   Agent Gateway (AG)
      The infrastructure component that receives intent queries from
      Leader Agents, performs semantic matching against a registry of
      authenticated capabilities, and returns a signed routing decision.

   Intent
      A declarative expression of a desired outcome.  Represented at
      three conceptual levels:

      *  _Human Intent_: A high-level, possibly ambiguous expression
         from a human user.  Out of scope for this specification.

      *  _Task Intent_: An abstract, task-oriented description of the
         objective, independent of any specific agent or execution plan.




Yan, et al.              Expires 11 October 2026                [Page 5]

Internet-Draft     Intent-based Agent Routing Security        April 2026


      *  _Intent Descriptor_: A structured, machine-interpretable
         representation of Task Intent, used for routing and dispatch
         decisions within the AG.

   Intent Vector
      A numerical embedding of an Intent Descriptor, used by the AG to
      compute semantic similarity scores against registered Capability
      Advertisements.

   Capability Advertisement (CAP_ADV)
      A registration message submitted by a Partner Agent to the AG,
      containing the agent's functional descriptors, supported intent
      domains, and associated cryptographic attestation.

   Semantic Namespace
      A bounded domain of intent types and functional roles that a
      Partner Agent is authorized to operate within, as asserted by a
      Domain Authority credential.

   Domain Authority (DA)
      A trusted entity that issues Verifiable Credentials binding a
      Partner Agent's identity to its authorized Semantic Namespace.

   Verifiable Credential (VC) / Verifiable Presentation (VP)
      A cryptographically signed attestation, issued by a Domain
      Authority, asserting a Partner Agent's identity and its authorized
      functional roles.

   Decentralized Identifier (DID)
      A globally unique, cryptographically verifiable identifier that
      does not require a centralized registry, used for agent identity
      establishment [DID-CORE].

3.  System Architecture and Security Attack Surface

3.1.  System Architecture

   The intent-based agent routing framework involves three primary
   entities: the Leader Agent (LA), the Agent Gateway (AG), and the
   Partner Agent (PA).  The routing lifecycle is structured into three
   security-relevant phases: Registration, Resolution, and Dispatch.
   Security controls are required at each phase boundary.









Yan, et al.              Expires 11 October 2026                [Page 6]

Internet-Draft     Intent-based Agent Routing Security        April 2026


                       [Domain Authority]
                              |
                 (issues VC / validates namespace)
                              |
     [Partner Agent]     [Agent Gateway]          [Leader Agent]
          |                    |                       |
          |                    |                       |
     PHASE 1: REGISTRATION     |                       |
     ========================  |                       |
     [SC-1] mTLS session +     |                       |
     VP credential attach  --> |                       |
                       [SC-2] Verify VP sig +          |
                       namespace scope check           |
          |  <-- ACK (routing table updated) --        |
          |                    |                       |
     PHASE 2: RESOLUTION       |                       |
     ========================  |                       |
                               | <-- [SC-3] Signed     |
                               |     intent vector     |
                       [SC-4] Authenticate LA          |
                       + semantic search               |
                               | -- [SC-5] Signed  --> |
                               |    route response     |
                               |                       |
     PHASE 3: DISPATCH         |                       |
     ========================  |                       |
                               |           [SC-6] Verify AG sig
          | <====== Direct E2E encrypted session ====> |
          |         (task payload, bypasses AG)        |

         Figure 1: System Architecture and Security Control Points

   *Security Control Points:*


















Yan, et al.              Expires 11 October 2026                [Page 7]

Internet-Draft     Intent-based Agent Routing Security        April 2026


   +======+==============+============+===============================+
   | ID   | Phase        | Location   | Security Action               |
   +======+==============+============+===============================+
   | SC-1 | Registration | PA to AG   | Mutual TLS session            |
   |      |              |            | establishment + VP attachment |
   +------+--------------+------------+-------------------------------+
   | SC-2 | Registration | AG         | VP signature verification +   |
   |      |              | (internal) | namespace scope check         |
   +------+--------------+------------+-------------------------------+
   | SC-3 | Resolution   | LA to AG   | LA signs intent vector before |
   |      |              |            | submission                    |
   +------+--------------+------------+-------------------------------+
   | SC-4 | Resolution   | AG         | LA identity verification +    |
   |      |              | (internal) | filtered semantic search      |
   +------+--------------+------------+-------------------------------+
   | SC-5 | Resolution   | AG to LA   | AG signs route response as    |
   |      |              |            | proof of routing              |
   +------+--------------+------------+-------------------------------+
   | SC-6 | Dispatch     | LA         | LA verifies AG signature      |
   |      |              | (internal) | before connecting to PA       |
   +------+--------------+------------+-------------------------------+

                                 Table 1

3.2.  Attack Surface Analysis

   This section analyzes the security vulnerabilities specific to each
   phase of the routing lifecycle.  Each attack surface is assigned a
   unique identifier used throughout this document to link threats to
   requirements and process steps.

3.2.1.  Registration Phase Attack Surface

   The Registration phase is when Partner Agents publish their
   capabilities to the AG's routing table.  This phase is exposed to the
   following attack surfaces:

3.2.1.1.  AS-R-01: Unauthenticated Registration

   An adversary may attempt to register capabilities without holding a
   valid identity.  If the AG accepts unauthenticated CAP_ADV messages,
   any process can inject arbitrary entries into the routing table,
   enabling subsequent routing manipulation.








Yan, et al.              Expires 11 October 2026                [Page 8]

Internet-Draft     Intent-based Agent Routing Security        April 2026


3.2.1.2.  AS-R-02: Capability Poisoning

   A validly authenticated agent may advertise capability vectors that
   are semantically crafted to match task intents outside its authorized
   domain.  For example, a "Logging Agent" may embed intent vectors
   artificially aligned with "Financial Audit" tasks to intercept
   sensitive requests.  Standard PKI verifies identity but does not
   constrain what an agent claims to be able to do.

3.2.1.3.  AS-R-03: Routing Table Tampering

   An adversary with access to the AG's routing table management
   interface may overwrite or delete legitimate routing entries,
   redirecting traffic to unauthorized agents or causing service denial.
   Without audit logging, such modifications are undetectable.

3.2.2.  Resolution Phase Attack Surface

   The Resolution phase is when the LA submits an intent query and the
   AG performs semantic matching.  This phase is exposed to the
   following attack surfaces:

3.2.2.1.  AS-Q-01: Unauthenticated Intent Queries

   An adversary may flood the AG with unsigned or spoofed intent
   queries, either to probe the network's capability registry or to
   exhaust the AG's embedding and vector search resources.  This
   constitutes an Intent Denial of Service (IDoS) attack, targeting the
   computational cost of the routing logic rather than network
   bandwidth.

3.2.2.2.  AS-Q-02: Intent Content Exposure

   The AG requires visibility into the semantic content of the Intent
   Descriptor to perform similarity matching.  This creates an inherent
   tension with end-to-end confidentiality: the AG must process the
   intent, but the intent may contain sensitive data (e.g., patient
   records, proprietary business logic).  Without privacy-preserving
   mechanisms, the AG becomes a single point of failure for data
   leakage.

3.2.2.3.  AS-Q-03: Candidate List Manipulation

   An adversary performing a man-in-the-middle attack between the AG and
   the LA may tamper with the returned candidate list, substituting
   legitimate Partner Agents with malicious endpoints.  Without
   integrity protection on the route response, the LA has no means to
   verify the routing decision.



Yan, et al.              Expires 11 October 2026                [Page 9]

Internet-Draft     Intent-based Agent Routing Security        April 2026


3.2.3.  Dispatch Phase Attack Surface

   The Dispatch phase is when the LA uses the routing decision to
   establish a direct session with the selected PA.  This phase is
   exposed to the following attack surfaces:

3.2.3.1.  AS-D-01: Route Hijacking

   An adversary may intercept the route response from the AG and
   substitute a malicious endpoint for the legitimate PA.  If the LA
   does not cryptographically verify the AG's routing decision, it will
   establish a session with the attacker's endpoint and transmit the
   task payload to an unauthorized party.

3.2.3.2.  AS-D-02: Task Payload Interception

   If the task payload is transmitted through or via the AG rather than
   directly to the PA, the AG becomes a potential point of cleartext
   exposure for sensitive data.  The payload must not traverse any
   intermediary that is not the intended recipient.

4.  Security Requirements

   This section specifies the normative security requirements for
   intent-based agent routing.  Requirements are organized by routing
   phase, corresponding to the attack surfaces identified in Section 3.
   Implementations MUST satisfy all requirements marked MUST to be
   considered compliant with this specification.

4.1.  Registration Phase Requirements

   _Applicable attack surfaces: AS-R-01, AS-R-02, AS-R-03_

4.1.1.  REQ-R-01: Mutual Authentication for Registration

   The AG MUST enforce mutual TLS (mTLS) for all CAP_ADV registration
   sessions.  Unauthenticated agents MUST NOT be permitted to submit
   capability advertisements or query the routing table.

   _Addresses: AS-R-01_

4.1.2.  REQ-R-02: Attested Capability Advertisement

   A CAP_ADV message MUST include a Verifiable Presentation (VP) issued
   by a trusted Domain Authority.  The VP MUST cryptographically bind
   the PA's public key to its authorized Semantic Namespace.  The AG
   MUST verify the VP signature before accepting any registration.




Yan, et al.              Expires 11 October 2026               [Page 10]

Internet-Draft     Intent-based Agent Routing Security        April 2026


   _Addresses: AS-R-02_

4.1.3.  REQ-R-03: Semantic Namespace Enforcement

   The AG MUST perform a semantic scope check on the advertised intent
   vector.  If the vector falls outside the authorized namespace defined
   in the PA's VP, the AG MUST reject the registration and return an
   appropriate error response.

   _Addresses: AS-R-02_

4.1.4.  REQ-R-04: Routing Table Audit Logging

   All routing table modification events (registration, refresh,
   deregistration) MUST be recorded in a tamper-evident audit log.  The
   log MUST capture the agent identity, timestamp, and operation type to
   enable detection of unauthorized routing table changes.

   _Addresses: AS-R-03_

4.2.  Resolution Phase Requirements

   _Applicable attack surfaces: AS-Q-01, AS-Q-02, AS-Q-03_

4.2.1.  REQ-Q-01: Leader Agent Authentication

   The AG MUST verify the digital signature on every intent request
   message before performing any semantic search.  Unsigned or invalidly
   signed queries MUST be rejected with an AUTH_FAILED error.  This
   prevents unauthenticated probing and mitigates IDoS by tying query
   admission to verified identities.

   _Addresses: AS-Q-01_

4.2.2.  REQ-Q-02: Intent Minimization

   The LA SHOULD separate the intent query into two components: (a)
   Routing Metadata (intent vector and constraints), transmitted to the
   AG; and (b) Task Payload (sensitive data), retained locally.  The
   Task Payload MUST NOT be transmitted to the AG.  Only the Routing
   Metadata is used for semantic matching.

   _Addresses: AS-Q-02_








Yan, et al.              Expires 11 October 2026               [Page 11]

Internet-Draft     Intent-based Agent Routing Security        April 2026


4.2.3.  REQ-Q-03: Privacy-Preserving Intent Matching

   The AG SHALL support at least one privacy-preserving intent matching
   mechanism, such as computation over encrypted vectors using
   Homomorphic Encryption (HE) or semantic matching performed within a
   Trusted Execution Environment (TEE).  This allows the AG to perform
   similarity scoring without access to plaintext intent content.

   _Addresses: AS-Q-02_

4.2.4.  REQ-Q-04: Signed Route Response

   The AG MUST digitally sign all route responses using its private key
   before returning them to the LA.  The signature MUST cover the
   Partner Agent identifier, endpoint URI, and response timestamp,
   providing a cryptographically verifiable proof of routing decision.

   _Addresses: AS-Q-03_

4.3.  Dispatch Phase Requirements

   _Applicable attack surfaces: AS-D-01, AS-D-02_

4.3.1.  REQ-D-01: Route Response Verification

   Upon receiving a route response, the LA MUST verify the AG's digital
   signature before establishing any session with the indicated PA.  If
   verification fails, the LA MUST abort the session and report an
   error.

   _Addresses: AS-D-01_

4.3.2.  REQ-D-02: Direct End-to-End Encrypted Session

   The LA MUST establish a direct, end-to-end encrypted session (e.g.,
   TLS 1.3 [RFC8446] or QUIC [RFC9000]) with the selected PA for task
   payload transmission.  The task payload MUST NOT be routed through
   the AG.  The AG MUST NOT have access to the plaintext task payload.

   _Addresses: AS-D-02_

4.3.3.  REQ-D-03: Transport Encryption for All Signaling

   All signaling traffic between any two entities (LA to AG, PA to AG)
   MUST be transmitted over encrypted channels (TLS 1.3 or equivalent).
   This applies to capability advertisements, intent queries, and route
   responses.




Yan, et al.              Expires 11 October 2026               [Page 12]

Internet-Draft     Intent-based Agent Routing Security        April 2026


   _Addresses: AS-R-01, AS-Q-01, AS-D-01 (baseline for all phases)_

5.  Secure Routing Process

   This section describes the normative operational procedure for secure
   intent-based agent routing.  The process is decomposed into three
   phases: Registration, Resolution, and Dispatch for security analysis
   purposes.

   Steps are numbered continuously (Steps 1-11) to correspond directly
   to the interaction flow diagram in Section 6.

5.1.  Phase 1: Trusted Registration

   _Applicable requirements: REQ-R-01, REQ-R-02, REQ-R-03, REQ-R-04,
   REQ-D-03_

   This phase establishes the trust domain.  All Partner Agents MUST
   complete registration before any routing requests can be resolved to
   them.

   1.  *Step 1 - Session Establishment:* The PA initiates a mutually
       authenticated TLS (mTLS) session with the AG.  Both parties
       present certificates; the AG MUST reject any connection where the
       PA cannot present a valid certificate. _(REQ-R-01, REQ-D-03)_

   2.  *Step 2 - Capability Advertisement with Attestation:* The PA
       constructs a CAP_ADV message containing its Intent Vector and
       functional descriptors.  The PA MUST attach a Verifiable
       Presentation (VP) issued by a trusted Domain Authority.  The VP
       binds the PA's public key to its authorized Semantic Namespace.
       _(REQ-R-02)_

   3.  *Step 3 - AG Validation:* The AG performs two verification steps
       in sequence:

       1.  (a) *Signature Verification*: The AG verifies the
           cryptographic signature of the attached VP.  If the signature
           is invalid, the registration MUST be rejected.

       2.  (b) *Namespace Scope Check*: The AG verifies that the
           advertised intent vector falls within the Semantic Namespace
           asserted by the VP.  If the vector is out of scope, the
           registration MUST be rejected.

       _(REQ-R-02, REQ-R-03)_





Yan, et al.              Expires 11 October 2026               [Page 13]

Internet-Draft     Intent-based Agent Routing Security        April 2026


   4.  *Step 4 - Routing Table Update and Audit:* Upon successful
       validation, the AG commits the PA's capability profile to the
       routing table and records a tamper-evident audit log entry.  The
       AG returns a registration acknowledgement to the PA. _(REQ-R-04)_

5.2.  Phase 2: Privacy-Preserving Resolution

   _Applicable requirements: REQ-Q-01, REQ-Q-02, REQ-Q-03, REQ-Q-04,
   REQ-D-03_

   This phase is triggered when a registered LA submits a semantic
   intent query.

   1.  *Step 5 - Intent Preparation and Minimization:* The LA generates
       the Intent Vector locally from the Task Intent.  The LA separates
       the query into two components: Routing Metadata (intent vector,
       domain constraints, budget) and Task Payload (sensitive data).
       Only the Routing Metadata is prepared for transmission to the AG.
       The Task Payload is retained locally. _(REQ-Q-02)_

   2.  *Step 6 - Signed Intent Submission:* The LA signs the Routing
       Metadata using the credentials established during identity
       registration, then transmits the signed intent request message to
       the AG over an encrypted channel. _(REQ-Q-01, REQ-D-03)_

   3.  *Step 7 - LA Authentication and Semantic Search:* The AG first
       verifies the LA's digital signature.  If verification fails, the
       AG MUST reject the query with AUTH_FAILED.  Upon successful
       verification, the AG performs semantic similarity matching
       against the routing table, applying trust-scope filtering to
       exclude agents with insufficient clearance or expired
       credentials.  Privacy-preserving matching (HE or TEE) SHOULD be
       applied when supported. _(REQ-Q-01, REQ-Q-03)_

   4.  *Step 8 - Signed Route Response:* The AG constructs a route
       response containing the selected PA's identity, endpoint URI, and
       public key.  The AG signs this response with its own private key
       and returns it to the LA. _(REQ-Q-04)_

5.3.  Phase 3: Verifiable Dispatch

   _Applicable requirements: REQ-D-01, REQ-D-02, REQ-D-03_

   This phase transfers the routing decision into a secure execution
   connection.  The AG does not participate in this phase beyond having
   issued the signed route response.





Yan, et al.              Expires 11 October 2026               [Page 14]

Internet-Draft     Intent-based Agent Routing Security        April 2026


   1.  *Step 9 - Route Response Verification:* The LA verifies the AG's
       digital signature on the route response.  If verification fails,
       the LA MUST abort the session and MUST NOT connect to the
       indicated endpoint.  This prevents route hijacking via man-in-
       the-middle tampering. _(REQ-D-01)_

   2.  *Step 10 - Direct Session Establishment:* Using the verified PA
       endpoint and public key, the LA establishes a direct, end-to-end
       encrypted session with the PA (e.g., TLS 1.3 or QUIC).  The AG is
       not involved in this session. _(REQ-D-02, REQ-D-03)_

   3.  *Step 11 - Task Payload Delivery:* The LA transmits the Task
       Payload directly to the PA within the encrypted session
       established in Step 10.  The AG has no access to the plaintext
       payload at any point. _(REQ-D-02)_

6.  Secure Interaction Flow

   This section presents the complete annotated message sequence for
   secure intent-based agent routing.  Each step in the diagram
   corresponds to the numbered steps in Section 5.  Security
   requirements satisfied at each step are indicated in brackets.

     [Partner Agent]          [Agent Gateway]             [Leader Agent]
          |                        |                            |
     --- PHASE 1: TRUSTED REGISTRATION ---------------------------
          |                        |                            |
    (1)  |--- mTLS ClientHello -->|                            |
          |<-- mTLS ServerHello ---|   [REQ-R-01, REQ-D-03]    |
          |                        |                            |
    (2)  |--- CAP_ADV             |                            |
          |   + Intent Vector      |                            |
          |   + VP (signed by DA) >|   [REQ-R-02]              |
          |                        |                            |
          |         (3a) Verify VP signature    [REQ-R-02]      |
          |         (3b) Namespace scope check  [REQ-R-03]      |
          |                        |                            |
    (4)  |<-- Registration ACK ---|                            |
          |           (Routing table updated + audit log)        |
          |                        |   [REQ-R-04]              |
          |                        |                            |
     --- PHASE 2: PRIVACY-PRESERVING RESOLUTION ------------------
          |                        |                            |
          |                        |  (5) Intent Minimization   |
          |                        |      [Routing Metadata     |
          |                        |       separated from       |
          |                        |       Task Payload]        |
          |                        |      [REQ-Q-02]            |



Yan, et al.              Expires 11 October 2026               [Page 15]

Internet-Draft     Intent-based Agent Routing Security        April 2026


          |                        |                            |
          |                        |<---- Intent Request         |
    (6)  |                        |     [Signed Vector Only]   |
          |                        |     [REQ-Q-01, REQ-D-03]  |
          |                        |                            |
          |         (7a) Verify LA signature    [REQ-Q-01]      |
          |         (7b) Semantic search +                      |
          |              trust-scope filtering  [REQ-Q-03]      |
          |                        |                            |
    (8)  |                        |--- Route Response -------->|
          |                        |    [PA ID + Endpoint +     |
          |                        |     AG Signature]          |
          |                        |    [REQ-Q-04]              |
          |                        |                            |
     --- PHASE 3: VERIFIABLE DISPATCH ---------------------------
          |                        |                            |
          |                        |  (9) Verify AG signature   |
          |                        |      [REQ-D-01]            |
          |                        |                            |
    (10) |<======== Direct TLS 1.3 / QUIC Session ==============>|
          |         [E2E Encrypted, AG not involved]            |
          |         [REQ-D-02, REQ-D-03]                       |
          |                        |                            |
    (11) |<======== Task Payload Transmission ================>|
          |         [Plaintext never exposed to AG]             |
          |         [REQ-D-02]                                  |
          |                        |                            |

                 Figure 2: Secure Interaction Flow Diagram

   *Requirement Coverage Summary:*




















Yan, et al.              Expires 11 October 2026               [Page 16]

Internet-Draft     Intent-based Agent Routing Security        April 2026


   +======+===================================+========================+
   | Step | Description                       | Requirements Satisfied |
   +======+===================================+========================+
   | 1    | mTLS session establishment        | REQ-R-01, REQ-D-03     |
   +------+-----------------------------------+------------------------+
   | 2    | CAP_ADV with VP submission        | REQ-R-02               |
   +------+-----------------------------------+------------------------+
   | 3a   | VP signature verification         | REQ-R-02               |
   +------+-----------------------------------+------------------------+
   | 3b   | Namespace scope check             | REQ-R-03               |
   +------+-----------------------------------+------------------------+
   | 4    | Routing table update + audit log  | REQ-R-04               |
   +------+-----------------------------------+------------------------+
   | 5    | Intent minimization               | REQ-Q-02               |
   +------+-----------------------------------+------------------------+
   | 6    | Signed intent request submission  | REQ-Q-01, REQ-D-03     |
   +------+-----------------------------------+------------------------+
   | 7a   | LA signature verification         | REQ-Q-01               |
   +------+-----------------------------------+------------------------+
   | 7b   | Semantic search + trust           | REQ-Q-03               |
   |      | filtering                         |                        |
   +------+-----------------------------------+------------------------+
   | 8    | Signed route response             | REQ-Q-04               |
   +------+-----------------------------------+------------------------+
   | 9    | AG signature verification by LA   | REQ-D-01               |
   +------+-----------------------------------+------------------------+
   | 10   | Direct E2E session establishment  | REQ-D-02, REQ-D-03     |
   +------+-----------------------------------+------------------------+
   | 11   | Task payload delivery             | REQ-D-02               |
   +------+-----------------------------------+------------------------+

                                  Table 2

7.  Conclusions

   Intent-based agent routing introduces a semantic control plane for
   which traditional transport-layer security is insufficient.  This
   document has defined a security architecture by analyzing the attack
   surfaces specific to each routing phase, establishing normative
   requirements mapped directly to those surfaces, and specifying a
   secure operational process with a fully annotated interaction flow.

   The attack surface identifiers, requirement identifiers, process
   steps, and flow diagram steps maintain strict correspondence
   throughout, enabling implementers to trace any security property from
   its threat origin to its operational realization.





Yan, et al.              Expires 11 October 2026               [Page 17]

Internet-Draft     Intent-based Agent Routing Security        April 2026


8.  IANA Considerations

   This memo includes no request to IANA.

9.  Security Considerations

   This document specifies comprehensive security requirements for
   intent-based agent routing systems.  The security considerations are
   fully addressed through the requirements and processes defined in
   Sections 3 through 6 of this document.  All security controls are
   mandatory for compliant implementations unless explicitly marked as
   SHOULD or MAY.

   Key security properties ensured by this specification include:

   *  Mutual authentication between all routing participants

   *  Cryptographic attestation of agent capabilities

   *  Semantic namespace enforcement to prevent capability poisoning

   *  Privacy-preserving intent matching mechanisms

   *  Cryptographically signed routing decisions

   *  End-to-end encrypted session establishment for task payload
      delivery

   *  Tamper-evident audit logging for routing table modifications

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, BCP 14, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", RFC 8174, BCP 14, May 2017,
              <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, August 2018,
              <https://www.rfc-editor.org/rfc/rfc8446>.






Yan, et al.              Expires 11 October 2026               [Page 18]

Internet-Draft     Intent-based Agent Routing Security        April 2026


   [RFC9000]  Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
              and Secure Transport", RFC 9000, May 2021,
              <https://www.rfc-editor.org/rfc/rfc9000>.

10.2.  Informative References

   [RFC6749]  Hardt, D., "The OAuth 2.0 Authorization Framework",
              RFC 6749, October 2012,
              <https://www.rfc-editor.org/rfc/rfc6749>.

   [DID-CORE] Sporny, M., Guy, A., Sabadello, M., and D. Reed,
              "Decentralized Identifiers (DIDs) v1.0", W3C
              Recommendation did-core, July 2022.

   [VC-DATA-MODEL]
              Sporny, M., Longley, D., and D. Chadwick, "Verifiable
              Credentials Data Model v1.1", W3C Recommendation vc-data-
              model-1.1, March 2022.

Acknowledgements

   This document is the product of research conducted at the Institute
   of Computing Technology, Chinese Academy of Sciences.

Authors' Addresses

   Yu Yan (editor)
   Institute of Computing Technology, Chinese Academy of Sciences
   Email: yanyu24z@ict.ac.cn


   Sheng Sun (editor)
   Institute of Computing Technology, Chinese Academy of Sciences
   Email: sunsheng@ict.ac.cn


   Qiangzhou Gao
   Huawei
   Email: gaoqiangzhou@huawei.com


   Min Liu (editor)
   Institute of Computing Technology, Chinese Academy of Sciences
   Email: liumin@ict.ac.cn


   Xinyi Zhang
   Computer Network Information Center, Chinese Academy of Sciences



Yan, et al.              Expires 11 October 2026               [Page 19]

Internet-Draft     Intent-based Agent Routing Security        April 2026


   Email: xyzhang@cnic.cn


















































Yan, et al.              Expires 11 October 2026               [Page 20]
