Deployment Scenarios and Gap Analysis for AI Agent Gateway
draft-dunbar-dmsc-gw-scenarios-gap-analysis-03
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) | |
|---|---|---|---|
| Authors | Linda Dunbar , YiFei Wang , Iman Schrock , Bing Liu | ||
| Last updated | 2026-08-06 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| 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-dunbar-dmsc-gw-scenarios-gap-analysis-03
Network Working Group L. Dunbar
Internet Draft Futurewei
Intended status: Informational Y. Wang
Expires: February 6, 2027 China Telcom
Iman Schrock
Emiliaprotocol AI
B. Liu
Huawei
August 6, 2026
Deployment Scenarios and Gap Analysis for AI Agent Gateway
draft-dunbar-dmsc-gw-scenarios-gap-analysis-03
Abstract
This document examines deployment scenarios for AI agent
collaboration and analyzes the circumstances under which AI
Agent Gateway functions provide operational or
interoperability benefits that cannot be achieved through
direct agent-to-agent communication alone. The document
considers both single-domain and multi-domain deployments,
identifies specific challenges associated with each
deployment model, evaluates the limitations of existing agent
communication mechanisms (including MCP and A2A) with respect
to those challenges, and demonstrates that gateway functions
are necessary in deployments involving multiple tenants,
multiple vendors, or multiple administrative domains.
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), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
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."
xxx, et al. Expires February 6, 2027 [Page 1]
Internet-Draft GW Deployment Scenario
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed
at http://www.ietf.org/shadow.html
This Internet-Draft will expire on February 6, 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
(http://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 Simplified BSD
License text as described in Section 4.e of the Trust Legal
Provisions and are provided without warranty as described in
the Simplified BSD License.
Table of Contents
1. Introduction..............................................3
1.1. What is AI Agent Gateway?............................4
2. Conventions and Definitions...............................5
3. Existing AI Agent Communication Ecosystem.................6
3.1. Model Context Protocol (MCP).........................6
3.2. Agent-to-Agent Communication (A2A)...................6
3.3. Agent Metadata and Capability Advertisement..........7
3.4. Observability and Operational Visibility.............8
3.5. Summary and Open Questions...........................8
4. Deployment Scenarios: Agent Collaboration in the UnionPay
Ecosystem...................................................11
4.1. Scenario Overview...................................11
4.2. Single-Domain Agent Deployment......................11
4.3. Multi-Vendor Intra-Domain Deployment................12
4.4. UnionPay Multi-Tenant Platform Deployment...........13
4.5. Cross-Organization Agent Collaboration..............15
4.6. Observations........................................17
Dunbar, et al. Expires Dec 6, 2027 [Page 2]
Internet-Draft GW Deployment Scenario
5. Deployment Scenarios: Embodied AI Agent Collaboration in
Telecom Operator Networks...................................17
5.1. Scenario Overview...................................17
5.2. Multi-Vendor Embodied Agent Collaboration within a
Campus or Factory........................................18
5.3. Mobility-Driven Embodied Agent Collaboration across
Cells and Edge Nodes.....................................19
5.4. Localized Authorization for High-Risk Physical
Operations...............................................20
5.5. Cross-Organization, Cross-Domain Multi-Gateway
Federation...............................................20
5.6. Observations........................................21
6. Analysis of AI Agent Gateway Functions...................21
6.1. Operational Onboarding and Reachability.............22
6.2. Capability Advertisement and Discovery..............22
6.3. Peer Agent Selection and Request Routing............23
6.4. Identity and Trust Establishment....................24
6.5. Policy Enforcement and Governance...................25
6.6. Observability and Operational Visibility............25
6.7. Gateway Synchronization and Information Exchange....26
6.8. Network-Aware Mobility and Reachability.............27
6.9. Action-Level Authorization for Physical-World
Operations...............................................28
7. Gap Analysis.............................................29
7.1. Operational Management..............................29
7.2. Policy-Controlled Capability Exposure...............30
7.3. Multi-Tenant and Multi-Vendor Deployments...........30
7.4. Cross-Organization Collaboration....................30
7.5. Gateway Synchronization and Information Exchange....31
7.6. Mobility and Network Context Awareness..............31
7.7. Physical-World Action Authorization.................32
7.8. Summary.............................................32
8. Security Considerations..................................33
9. Manageability Considerations.............................33
10. IANA Considerations.....................................33
11. References..............................................33
11.1. Normative References...............................33
11.2. Informative References.............................34
12. Acknowledgments.........................................34
Appendix A:.................................................34
1. Introduction
AI agents are increasingly deployed to collaborate across
organizational boundaries - discovering peer agents,
delegating tasks, and exchanging results to complete complex
Dunbar, et al. Expires Dec 6, 2027 [Page 3]
Internet-Draft GW Deployment Scenario
business workflows. Existing protocols such as MCP [MCP] and
A2A [A2A] address how agents communicate and describe their
capabilities. They do not address whether agents are
authorized to participate, which capabilities should be
visible to which parties, or how interactions are governed and
audited across organizations.
[I-D.men-rtgwg-agent-networking-in-digibank] describes this
challenge concretely in the context of digital banking. Use
cases such as IPO bank statement auditing and retail credit
processing require multiple specialized agents - operated by
different banks, sponsor institutions, and regulators - to
collaborate under strict authorization and audit requirements.
In these environments, the absence of a governance layer is
not a theoretical gap; it is an operational blocker.
This document analyzes those use cases to identify where AI
Agent Gateway (GW) functions are necessary and what gaps exist
that may benefit from standardization. Section 3 evaluates
existing mechanisms. Section 4 works through the deployment
scenarios. Section 5 analyzes the required gateway functions.
Section 6 presents the gap analysis.
1.1. What is AI Agent Gateway?
An AI Agent Gateway (GW) is an edge node serving as the
managed attachment anchor for AI agents in a provider-managed
or private network. It sits between agents or agent domains,
providing governance and intermediary functions that agent-to-
agent protocols alone do not address. These functions include:
onboarding and trust binding; policy-based access control and
request routing; for embodied agents, physical-world action
authorization; network-aware mobility management; group and
stream coordination across organizations; mediation between
business intent and concrete interaction mechanisms, including
handoff resolution; and observability and audit.
A GW operates on metadata, routing events, and authorization
decisions, but not on encrypted communication content.
Dunbar, et al. Expires Dec 6, 2027 [Page 4]
Internet-Draft GW Deployment Scenario
A GW is not required in every deployment. A single agent
calling a known peer may work fine with direct A2A
communication and a token, much like calling an external API
directly. A GW becomes valuable at scale, the same reason an
API gateway helps once an organization manages many APIs, by
providing common policy enforcement, access control,
coordination, mediation, and audit that individual agents
would otherwise each reimplement.
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.
The following acronyms and terms are used in this document:
AI Agent: A software entity that uses artificial intelligence
techniques to interpret context, make decisions,
and take actions toward achieving one or more
goals, possibly by interacting with users and by
invoking other agents, tools, or services.
Agent Gateway (GW): an edge node that serves as the managed
attachment anchor for AI agents within a
provider-managed or private network, sitting
between agents or agent domains to provide
governance and intermediary functions not
addressed by agent-to-agent communication
protocols alone.
Attachment Context: The set of properties describing an
agent's current network attachment (e.g.,
attachment point, domain, protocols).
Directory Service: A service or registry enabling discovery
of agents based on capabilities and returning
associated metadata such as AgentIDs, endpoints,
or Agent Cards.
Dunbar, et al. Expires Dec 6, 2027 [Page 5]
Internet-Draft GW Deployment Scenario
3. Existing AI Agent Communication Ecosystem
This section reviews the most relevant existing mechanisms
for AI agent communication and capability advertisement and
explicitly identifies the deployment challenges they do not
address. This analysis is essential for establishing why
gateway functions are needed in the deployment scenarios
described in Section 4.
3.1. Model Context Protocol (MCP)
MCP [MCP] provides a standardized mechanism for connecting
language-model applications with external tools, data
sources, and contextual information. MCP enables tool access
and integration between AI applications and supporting
services.
MCP does not address:
o Large-scale agent discovery in dynamic environments
o Inter-agent trust relationships across organizations
o Operational governance, lifecycle management, or
admission control
o Policy enforcement across multiple tenants or
administrative domains
o Communications across organizational boundaries with
audit requirements.
3.2. Agent-to-Agent Communication (A2A)
A2A [A2A] is an open protocol for communication and
interoperability between independent agentic applications.
A2A is hosted by the Linux Foundation and defines mechanisms
for agent discovery via Agent Cards, capability
advertisement, task delegation, and interaction negotiation.
A2A provides important building blocks. However, A2A
explicitly does not standardize the API for curated
registries, and its discovery mechanisms vary by deployment.
Specifically, A2A does not address the following deployment
requirements:
Dunbar, et al. Expires Dec 6, 2027 [Page 6]
Internet-Draft GW Deployment Scenario
o Operational onboarding: A2A defines how an agent
describes itself, but not whether an agent is approved to
participate in a managed deployment, who owns it, what
compliance checks it has undergone, or what lifecycle
state it is in.
o Policy-controlled visibility: A2A Agent Cards can be
published at well-known URIs or in registries, but A2A
does not define how to restrict which consumers can see
which capabilities. An agent's capabilities are either
public or require deployment-specific access control.
o Consistent cross-vendor policy enforcement: A2A does not
define how policies are enforced consistently across
agents from different vendors or how policies are
coordinated across administrative domains.
o Cross-organization trust binding: A2A supports
authentication, but does not define how requests are
bound to organizational identities, business
relationships, authorization context, or regulatory
compliance records.
3.3. Agent Metadata and Capability Advertisement
Agent metadata (including A2A Agent Cards) describes agent
identity, endpoints, supported protocols, authentication
requirements, and capabilities. Such metadata is foundational
for agent discovery and selection.
However, metadata alone is insufficient because:
o Sensitivity varies: Some capability information reveals
internal business functions, operational topology, or
available tools that should not be visible to all
potential consumers. Publishing a complete Agent Card to
all requesters is often inappropriate in enterprise or
financial deployments.
o Freshness is not guaranteed: Agent capabilities change as
tools are updated, models are replaced, policies change,
or tenants are created or deleted. No standard mechanism
exists for invalidating or versioning Agent Cards across
independently operated registries.
Dunbar, et al. Expires Dec 6, 2027 [Page 7]
Internet-Draft GW Deployment Scenario
o Authorization context is absent: An Agent Card describes
what an agent can do, but does not describe who is
authorized to invoke which capabilities under what
conditions and for what business purpose.
3.4. Observability and Operational Visibility
As agent deployments grow in complexity, operators require
visibility into agent interactions for monitoring,
troubleshooting, auditing, security analysis, and compliance.
Importantly, operational visibility does not require access
to encrypted communication content. Useful observability can
be derived from non-content information: request metadata,
routing events, authorization decisions, timing information,
error codes, and audit records.
Existing agent frameworks do not provide a standard mechanism
for collecting, correlating, and exposing such non-content
operational telemetry across agents from different vendors or
across organizational boundaries. This gap is particularly
significant in financial services environments subject to
regulatory audit requirements.
3.5. Summary and Open Questions
Existing agent communication mechanisms provide important
foundations for AI agent ecosystems. MCP provides a mechanism
for language-model applications to access external tools,
services, and context. A2A provides a mechanism for
independent agents to communicate, advertise capabilities,
and collaborate on tasks. Agent metadata mechanisms,
including Agent Cards, provide a way to describe agents and
their exposed capabilities.
These mechanisms address important parts of the agent
collaboration problem. In particular, they help answer
questions such as how an AI application invokes a tool, how
one agent communicates with another agent, and how an agent
can describe its capabilities to potential clients.
However, deployment scenarios introduce additional questions
that may not be fully answered by the communication protocol
alone. These questions become more significant as deployments
Dunbar, et al. Expires Dec 6, 2027 [Page 8]
Internet-Draft GW Deployment Scenario
scale from a small number of known agents to large, dynamic,
multi-vendor, multi-tenant, or multi-domain environments.
The following questions are particularly relevant to the
analysis in this document:
o How are agents discovered when the requesting agent does
not already know the target agent or its Agent Card
location?
o How is capability information distributed, synchronized,
and kept fresh across platforms, gateways, registries, or
domains?
o How can an operator verify that advertised capabilities,
endpoints, and policies are authentic and current?
o How should sensitive capability information be protected
from unauthorized discovery?
o How are local policies applied before an agent is exposed
to other agents, tenants, organizations, or domains?
o How are requests routed when agents move, scale
dynamically, or are reachable only through managed
infrastructure?
o How can operators observe, audit, and troubleshoot agent-
to-agent interactions without requiring agents to expose
internal state?
o Which of these functions are purely local deployment
choices, and which require interoperable behavior between
independently developed components?
These questions do not imply that a dedicated AI Agent
Gateway is required in every deployment. Consider a direct
analogy: an individual developer calling a well-known
external API (such as a weather service) can do so directly
using a token obtained through a straightforward onboarding
process; that token governs access, rate limits, and usage.
The API provider supplies its own observability. No gateway
is needed. Similarly, a single agent calling a known peer in
another domain may work well with direct A2A communication
and token-based access control, without any intermediary.
Gateway functions become operationally necessary as this
picture scales. A large organization managing many disparate
APIs finds it impractical for each one to independently
implement consistent security policy, access control, audit
logging, and usage monitoring. An API gateway provides a
common set of services that individual APIs can rely on
Dunbar, et al. Expires Dec 6, 2027 [Page 9]
Internet-Draft GW Deployment Scenario
without re-implementing them. The same logic applies to agent
deployments: as the number of agents, vendors, tenants, and
administrative domains grows, maintaining consistent
operational governance through direct agent-to-agent
communication alone becomes impractical. The core insight is
that some GW functions could in principle be layered into the
underlying agent protocols, but doing so becomes suboptimal
as deployments scale. Three functions stand out as
particularly difficult to absorb into A2A or MCP at scale: -
Network context is structurally unavailable to agents in
mobile deployments. Cell attachment, edge-node association,
and network slice state originate within the operator
network. No agent protocol extension can supply this
information because the agent does not have it; a network-
resident intermediary is structurally required in 5G/6G
deployments with mobile embodied agents. - Consistent policy
enforcement across heterogeneous vendors requires a shared
intermediary. Each agent could implement its own access
control, but ensuring identical tenant-isolation and
capability-visibility policy across agents from different
vendors, without a common enforcement point, creates
unacceptable redundancy and risk of policy divergence. -
Organizational authorization context requires infrastructure
outside any communication protocol. Binding an agent
interaction to a regulatory mandate, business agreement, or
cross-jurisdiction audit obligation requires PKI,
authorization token standards, and legal frameworks that
cannot be embedded in A2A or MCP without making those
protocols carry responsibilities far beyond their design
scope. In a small single-domain environment, direct agent-
to-agent communication and local configuration may be
sufficient. In larger single-domain deployments, gateway
functions may provide value by centralizing policy
enforcement, discovery, routing, and observability. In multi-
domain deployments, gateway functions may also be necessary
to mediate capability exchange, reachability, trust
establishment, and policy-controlled exposure across
administrative boundaries.
The following sections analyze deployment scenarios in which
these questions arise and evaluate whether gateway functions
may provide operational or interoperability benefits.
Dunbar, et al. Expires Dec 6, 2027 [Page 10]
Internet-Draft GW Deployment Scenario
4. Deployment Scenarios: Agent Collaboration in the UnionPay
Ecosystem
This section uses the IPO Bank Statement Auditing scenario
from [I-D.men-rtgwg-agent-networking-in-digibank] to analyze
where Agent Gateway functions become necessary. This scenario
is chosen because it spans multiple organizations, involves
distributed data, requires verifiable regulatory
authorization, and imposes cross-institution audit
obligations.
4.1. Scenario Overview
In an IPO auditing workflow, a Sponsor Institution must
verify bank transaction records of the prospective listed
company and its key personnel, which are dispersed across
many member banks in the UnionPay network. With the company's
authorization, the Sponsor Institution initiates requests
through the UnionPay platform, which routes them to each bank
and aggregates the results.
In an agentic realization of this workflow, specialized
agents - handling authorization, account discovery, statement
retrieval, compliance review, and audit report generation -
collaborate across organizational boundaries to complete the
audit. Each agent type may be operated by a different
organization or vendor.
4.2. Single-Domain Agent Deployment
Within a single bank, capability advertisement and discovery
- what A2A Agent Cards provide - answer questions such as
what an agent can do, how it can be reached, and what
authentication it requires. These are necessary but not
sufficient for operational management. As the number of
agents grows across business units and vendors, a different
set of questions arises: Is this agent approved to
participate? Who owns it? Has it passed required security and
compliance checks? Is it currently active or suspended? Which
consumers are permitted to invoke it? What audit records are
required for each invocation?
These questions cannot be answered by an Agent Card. Consider
what a bank must do before a Statement Retrieval Agent
becomes available for use within its ecosystem: verify
ownership, associate it with a responsible business unit,
Dunbar, et al. Expires Dec 6, 2027 [Page 11]
Internet-Draft GW Deployment Scenario
perform security and compliance review, determine which
capabilities may be exposed and to which consumers, and
define audit logging requirements. Subsequently, the agent
may need to be suspended during maintenance, have its
visibility restricted after a policy change, or be removed
from service if abnormal behavior is detected. None of these
actions are reflected in or triggered by capability metadata.
Some operational state is also inappropriate to publish in an
Agent Card at all, such as internal ownership, deployment
location, compliance status, tenant association, risk
classification, incident state, and policy bindings are
useful to an administrator but must not be visible to all
potential consumers. The gateway maintains this operational
state separately from discoverable capability metadata, and
controls what is exposed to whom.
Dynamic deployment compounds this further. Agents are
instantiated, upgraded, migrated, and retired over time.
Their endpoints, health status, and policy bindings change.
Without a managed control point tracking these lifecycle
events and keeping operational state consistent, stale or
unauthorized agents can remain reachable - a compliance and
security risk in a regulated financial environment.
The gateway addresses this by acting as the managed point for
onboarding, admission control, lifecycle management, policy
enforcement, health monitoring, and audit logging - without
needing to inspect encrypted agent communication content.
Even within a single domain, these functions are justified
when the deployment contains many agents, multiple business
units, sensitive capabilities, or regulatory compliance
requirements.
4.3. Multi-Vendor Intra-Domain Deployment
A large bank participating in the UnionPay ecosystem may
deploy agents developed by different vendors or attached to
different internal systems, such as customer management,
payment processing, account management, risk scoring, fraud
detection, and compliance review systems.
Although these agents may operate within a single
administrative domain, they may use different agent
frameworks, capability description formats, authentication
methods, lifecycle management systems, or operational tools.
Direct agent-to-agent communication may still be possible,
Dunbar, et al. Expires Dec 6, 2027 [Page 12]
Internet-Draft GW Deployment Scenario
but integration and management become more difficult as the
number and diversity of agents increase.
In this scenario, Agent Cards or similar metadata mechanisms
can help describe individual agents and their exposed
capabilities. However, capability descriptions alone do not
ensure consistent operational onboarding, policy enforcement,
access control, health monitoring, or audit logging across
agents supplied by different vendors.
For example, a compliance agent supplied by one vendor and a
risk assessment agent supplied by another vendor may expose
capability metadata in compatible formats, but the bank may
still need a common way to validate ownership, associate each
agent with internal policies, control which capabilities are
exposed, monitor health state, and produce audit records
across both systems.
AI Agent Gateway functions may provide value by offering a
common operational control point for heterogeneous agents.
Such functions may normalize capability exposure, apply local
policies, enforce access-control decisions, route requests to
approved agents, collect non-content operational telemetry,
and maintain lifecycle state across vendor-specific
implementations.
The gateway does not need to inspect encrypted agent-to-agent
communication content. Instead, it can operate on policy-
controlled metadata, routing events, authorization decisions,
health information, lifecycle state, and audit records.
Therefore, in a multi-vendor intra-domain deployment, the
primary value of gateway functions is to reduce integration
complexity and provide consistent operational governance
across heterogeneous agent systems, rather than to solve
inter-domain interoperability.
4.4. UnionPay Multi-Tenant Platform Deployment
UnionPay provides an interconnection platform used by many
participating banks, payment institutions, merchants, service
providers, and other authorized participants. In a future
agentic service environment, the platform may need to support
agents associated with different organizations, business
roles, and tenants.
Dunbar, et al. Expires Dec 6, 2027 [Page 13]
Internet-Draft GW Deployment Scenario
For example, a participating bank may operate account inquiry
agents, statement retrieval agents, credit assessment agents,
or compliance agents. UnionPay may operate platform-level
agents for routing, settlement support, risk monitoring, or
service coordination. Sponsor institutions, auditors,
merchants, or other authorized parties may operate agents
that request services from the platform or from participating
banks.
In this deployment model, the key challenge is not only
whether agents can communicate. The platform also needs to
control which agents are allowed to participate, which
capabilities are visible to which tenants, and which requests
are permitted under applicable business rules, authorization
status, and regulatory constraints.
Agent Cards and similar metadata mechanisms can describe
individual agents and their capabilities. However, in a
multi-tenant platform, capability metadata may need to be
filtered or exposed differently depending on the requesting
party. For example, an auditing agent may be allowed to
discover a bank's statement retrieval capability after proper
authorization, while a merchant agent or unrelated tenant
should not see or invoke the same capability.
AI Agent Gateway functions may provide value by supporting
policy-controlled capability exposure, tenant isolation,
request routing, authorization enforcement, health
monitoring, lifecycle management, and audit logging. These
functions can help the platform expose agent capabilities in
a controlled manner without requiring every agent to directly
understand the policies, trust relationships, and visibility
rules for every tenant.
Operational onboarding is also important in this scenario.
Before an agent becomes available through the UnionPay
platform, the platform may need to verify the agent's owning
organization, associate the agent with a tenant or business
role, validate required security and compliance attributes,
and bind the agent to policies that determine how its
capabilities may be exposed or invoked.
The gateway does not need to inspect encrypted agent-to-agent
communication content. Instead, it can operate on policy-
controlled metadata, routing events, authorization decisions,
health information, lifecycle state, tenant context, and
audit records.
Dunbar, et al. Expires Dec 6, 2027 [Page 14]
Internet-Draft GW Deployment Scenario
Therefore, in a UnionPay multi-tenant platform deployment,
the primary value of AI Agent Gateway functions is to provide
controlled exposure, tenant isolation, policy enforcement,
and operational governance across agents operated by
different participants in a shared platform environment.
4.5. Cross-Organization Agent Collaboration
Cross-organization agent collaboration occurs when agents
operated by different organizations need to participate in a
shared business process. In the UnionPay ecosystem, this may
involve UnionPay, participating banks, sponsor institutions,
auditors, merchants, payment institutions, or other
authorized service providers.
The IPO bank statement auditing scenario provides a
representative example. A sponsor institution or auditor may
operate an auditing agent that needs to request transaction
records from multiple banks through the UnionPay ecosystem.
Each bank may operate its own account inquiry agents,
statement retrieval agents, authorization agents, and
compliance agents. UnionPay may provide platform-level
functions for routing, policy coordination, authorization
verification, or service orchestration.
In this deployment model, each organization remains
responsible for its own agents, security policies,
operational practices, and compliance obligations. Direct
agent-to-agent communication across organizations may be
possible in some cases, but it introduces questions that are
less visible in a single-domain deployment. For example, an
agent in one organization may need to determine which
external agents are authorized to receive requests, which
capabilities may be exposed to a particular counterparty,
whether the requesting party has valid authorization, and how
audit records should be produced across organizational
boundaries.
Agent Cards or similar metadata mechanisms can describe the
capabilities and endpoints of external agents. However,
cross-organization collaboration also requires policy-
controlled exposure of that information. A bank may not want
all of its internal agents or capabilities to be visible to
every external party. Instead, it may expose only selected
capabilities to UnionPay, to specific sponsor institutions,
Dunbar, et al. Expires Dec 6, 2027 [Page 15]
Internet-Draft GW Deployment Scenario
or to authorized auditors under defined business agreements
and user consent.
AI Agent Gateway functions may provide value by mediating
this controlled exposure. A gateway can help determine which
capability information is visible to which external parties,
validate requests against local policy, route authorized
requests to internal agents, and maintain audit records for
compliance and dispute resolution. This allows each
organization to retain local control while enabling
collaboration with other organizations.
Trust establishment is another important consideration. In a
cross-organization deployment, one organization may not
directly know or trust every external agent. Gateway
functions may help bind agent interactions to organizational
identities, business relationships, authorization context,
and applicable policy. For example, a bank may accept
requests from a UnionPay-mediated auditing workflow only when
the request is associated with a recognized sponsor
institution, a valid authorization, and an approved business
purpose.
The gateway does not need to inspect encrypted agent-to-agent
communication content. Instead, it can operate on policy-
controlled metadata, routing events, authorization decisions,
organizational identity information, lifecycle state, and
audit records. This distinction is important because
financial agent communications may contain sensitive
personal, corporate, or transaction data that should remain
protected.
Therefore, in cross-organization agent collaboration, the
primary value of AI Agent Gateway functions is to support
controlled capability exposure, trust establishment, policy
enforcement, request routing, and auditability across
organizational boundaries. This scenario provides a stronger
interoperability motivation than purely single-domain
deployment because independently operated systems may need
common mechanisms to exchange metadata, express policy
constraints, validate counterparties, and coordinate
authorized agent interactions..
Dunbar, et al. Expires Dec 6, 2027 [Page 16]
Internet-Draft GW Deployment Scenario
4.6. Observations
The UnionPay ecosystem demonstrates that AI Agent Gateway
functions may provide value across multiple deployment
models.
Within a single administrative domain, gateway functions
primarily address operational management, governance, policy
enforcement, and observability.
Across multiple organizations, gateway functions may
additionally support capability discovery, trust
establishment, controlled exposure of services, and
interoperability among independently operated agent systems.
These observations do not imply that a dedicated gateway is
required in every deployment. Rather, they suggest that
gateway functions become increasingly valuable as deployments
grow in scale, involve multiple vendors, support multiple
tenants, or span organizational boundaries.
5. Deployment Scenarios: Embodied AI Agent Collaboration in
Telecom Operator Networks
This section identifies scenario where Agent Gateway
functions become necessary as telecom operator networks
support large-scale access by embodied AI Agents.
This scenario is chosen because it isolate the properties
that distinguish embodied agents from data-handling agents -
direct physical-world consequence and continuous network-side
mobility - while also covering the progression from a single
administrative domain to collaboration across organizations
and operator networks: multi-vendor device collaboration
within a campus or enterprise site, mobility-driven
collaboration across cells and edge nodes, authorization for
high-risk physical operations, and cross-domain gateway
federation.
5.1. Scenario Overview
A telecom operator's private network and edge computing
infrastructure increasingly serve as the connectivity and
management substrate for embodied AI Agents deployed by an
enterprise customer - robots, AGVs, robotic arms, and
Dunbar, et al. Expires Dec 6, 2027 [Page 17]
Internet-Draft GW Deployment Scenario
inspection drones performing physical tasks at a factory,
campus, or comparable site. These agents are supplied by
multiple equipment vendors, move within and beyond the
boundaries of the site as their tasks require, and in some
cases must hand off responsibility to agents operated by a
different organization, potentially attached to a different
operator's network.
In an agentic realization of this deployment, specialized
agents - handling device onboarding, task dispatch and
capability discovery, mobility and reachability tracking,
action-level authorization, and cross-organization handoff -
collaborate within and across administrative boundaries to
complete physical-world tasks. Each agent type may be
supplied by a different vendor, operated by a different
business unit, or owned by a different enterprise.
5.2. Multi-Vendor Embodied Agent Collaboration within a Campus
or Factory
In a smart factory, port, or comparable enterprise site,
robots, AGVs, robotic arms, and cameras are typically
supplied by different vendors but attach to the same
operator-provided private network (5G private network or edge
cloud). Each device may expose capability metadata through a
mechanism such as an A2A Agent Card, describing what it can
do, how it can be reached, and what authentication it
requires. This does not answer the questions an operating
site actually needs answered: who owns this device, has it
passed admission review, is it currently active, which
requesting agents are permitted to invoke it, and what record
must be kept of each invocation. These questions are
independent of which vendor supplied the device; they are
state that the operator's private network, as the common
point of attachment, must maintain regardless of vendor.
Beyond this, devices from different vendors do not natively
understand each other's protocols, identity models, or
capability formats. Without a common mediation layer,
integration cost recurs with every new device class added to
the site. AI agent gateway is well positioned to serve as the
attachment anchor for this heterogeneous device population,
since every device, irrespective of vendor, ultimately
attaches through the same gateway-mediated point in network.
AI Agent Gateway functions may provide value in this scenario
by performing device onboarding and identity binding
Dunbar, et al. Expires Dec 6, 2027 [Page 18]
Internet-Draft GW Deployment Scenario
independent of vendor-specific implementation, normalizing
heterogeneous capability descriptions into a common
representation, enforcing site-level access policy uniformly
across vendors, and maintaining a single lifecycle and audit
record across an otherwise fragmented device population. This
allows cross-vendor collaboration to be governed at the
network layer rather than requiring each pair of agents to
separately negotiate trust and capability exposure.
5.3. Mobility-Driven Embodied Agent Collaboration across Cells
and Edge Nodes
Delivery robot fleets and inspection drones are not fixed to
a single site; they move continuously across a city, crossing
cell coverage areas, edge nodes, and potentially network
slice domains. Their location, attachment point, available
edge compute, and connectivity quality change over time in a
way that agents running in a fixed data-center deployment
never encounter. An Agent Card can describe what an agent is
capable of, but not where it currently is, which edge node it
is attached to, or whether current network conditions meet a
task's latency requirement - information that determines
whether the agent is even a viable candidate for a given task
at a given moment.
This scenario most directly demonstrates a capability
specific to the telecom network: location, slice-level
service guarantees, and edge resource availability are
information that originates natively within the operator's
network and cannot be obtained through any agent-to-agent
protocol alone.
AI Agent Gateway functions may provide value in this scenario
by maintaining each agent's current reachability, attachment
point, and edge association as it moves; combining this
mobility state with slice or QoS context to determine which
agents currently satisfy a task's network requirements;
supporting session continuity and task handoff as an agent's
underlying network attachment changes; and using this
combined network and capability context to drive agent
selection and request routing. None of these functions can be
derived from capability metadata alone, since they depend on
information that resides in the network rather than in the
agent.
Dunbar, et al. Expires Dec 6, 2027 [Page 19]
Internet-Draft GW Deployment Scenario
5.4. Localized Authorization for High-Risk Physical Operations
A robotic arm performing a task, a drone entering a
restricted flight zone, a vehicle changing its planned route
these operations have consequences in the physical world;
they are not ordinary API invocations. Whether such an
operation may proceed depends on conditions that an Agent
Card cannot express: whether the current location falls
within an authorized zone, whether the operation falls within
an approved time window, whether human supervisory approval
has been obtained, whether the current risk level permits the
action, and whether the action complies with applicable site
or industry regulatory requirements.
This implies that "whether two agents may communicate" and
"whether a specific action may be executed" are distinct
levels of trust decision, and the latter requires a finer-
grained, more dynamic authorization mechanism, bound to both
identity and compliance status and to controlled capability
exposure.
AI Agent Gateway functions may provide value in this scenario
by evaluating each high-risk action request individually
rather than authorizing communication once at the session
level; binding action-level decisions to current location,
time window, risk classification, and any required human
approval state; restricting visibility of high-risk
capabilities to requesters that meet defined authorization
criteria; and recording an auditable decision trail for every
executed or denied action. This draws an explicit separation
between communication-layer trust and action-layer trust, a
distinction not yet systematically addressed in existing
treatments of agent interoperability.
5.5. Cross-Organization, Cross-Domain Multi-Gateway Federation
In smart-port operations, cross-city logistics, and joint
emergency dispatch, the scope of embodied agent collaboration
extends beyond a single enterprise or a single operator's
network. Cargo handled within a port may be transferred to a
fleet operated by a separate logistics enterprise,
potentially attached to a different operator's network; a
cross-region emergency response may require equipment under
different government agencies and different operator
jurisdictions to form a collaborative relationship on short
notice. In these cases, no single gateway can enforce policy
Dunbar, et al. Expires Dec 6, 2027 [Page 20]
Internet-Draft GW Deployment Scenario
beyond its own domain, and no single gateway can cover the
full collaboration chain alone.
This is the only one of the four scenarios that genuinely
requires a gateway-to-gateway protocol: one domain's gateway
must convey identity, capability, reachability,
authorization, and audit information to another domain's
gateway, rather than reaching across to directly manage
agents inside a domain it does not control.
AI Agent Gateway functions may provide value in this scenario
by exchanging selective identity, capability, and
reachability information with a peer gateway in another
domain; validating inbound requests against locally defined
trust relationships and business agreements rather than
against the requesting agent's own claims; mediating
controlled, counterparty-specific exposure of capabilities
and operational state across the domain boundary; and
maintaining an audit record that spans the handoff even
though each domain's internal agent activity remains
independently governed. These functions depend on
coordination between gateways rather than on the policy of
any single administrative entity.
5.6. Observations
Across these four scenarios, embodied agents introduce two
requirements not well addressed in deployments built around
stationary, software-only agents: action-level authorization
for requests with direct physical-world consequences, and
network-aware reachability management as agents move across
coverage areas and edge nodes. A general specification of
Agent Gateway functions should account for both, in addition
to the cross-organization trust and operational governance
requirements already established for non-embodied scenarios.
6. Analysis of AI Agent Gateway Functions
The deployment scenarios in Section 4 establish that gateway
functions are necessary in large-scale, multi-tenant, and
cross-organization environments. This section analyzes the
specific gateway functions required and describes what each
must provide.
Dunbar, et al. Expires Dec 6, 2027 [Page 21]
Internet-Draft GW Deployment Scenario
6.1. Operational Onboarding and Reachability
Operational onboarding is the process by which an agent is
admitted into a managed deployment. This is distinct from
publishing an Agent Card. Onboarding establishes:
o Ownership: which organization and business unit is
accountable for the agent
o Compliance status: whether the agent has undergone
required security and compliance review
o Lifecycle state: whether the agent is approved, active,
suspended, or retired
o Policy bindings: which policies govern how the agent may
be invoked and by whom
o Audit requirements: what records must be produced for
each invocation
Reachability management is the ongoing function of tracking
whether an onboarded agent is currently available, what its
current endpoint is, and whether it is operating within
expected parameters. As agents are dynamically instantiated,
scaled, migrated, or retired, reachability information must
be kept current and consistent across the gateway functions
that depend on it.
6.2. Capability Advertisement and Discovery
[I-D.men-rtgwg-agent-networking-in-digibank] characterizes
the Agent Gateway's role along three dimensions that are
directly relevant to capability advertisement and discovery:
o Communication hub for intelligent collaboration: the
gateway facilitates coordinated work among multiple
agents by implementing unified communication protocols
and context management, ensuring different agents can
execute complex business processes in an orderly and
efficient manner.
o Foundation for security and compliance: functioning as a
centralized access control node, the gateway
authenticates identities, checks permissions, and audits
operations for all agents, ensuring every action complies
with financial regulatory requirements.
Dunbar, et al. Expires Dec 6, 2027 [Page 22]
Internet-Draft GW Deployment Scenario
o Simplification and adaptation layer: the gateway
encapsulates intricate APIs, data sources, and business
systems into standardized services, allowing agents to
invoke required functions without needing to understand
backend technical details, thereby significantly reducing
integration complexity.
These three roles map directly onto the capability
advertisement and discovery function. The gateway does not
merely publish what agents can do (the Agent Card function).
It controls who can discover those capabilities (security and
compliance role), routes discovery queries to the appropriate
agents (communication hub role), and normalizes capability
descriptions across heterogeneous vendor implementations
(simplification layer role).
Gateways extend the capability advertisement function of A2A
Agent Cards by providing policy-controlled discovery. Rather
than publishing capabilities to all requesters uniformly, a
gateway filters the set of advertised capabilities based on
the identity, authorization context, and business
relationship of the requesting party. This controlled
exposure is essential in financial deployments where some
capabilities are public, others restricted to specific
business partners, and others available only under specific
regulatory authorizations.
In deployments where the underlying agents control physical
equipment, this normalization extends beyond software API
surfaces to vendor-specific device control and telemetry
interfaces, which is the primary integration burden in the
multi-vendor campus scenario in Section 5.2.
6.3. Peer Agent Selection and Request Routing
When multiple agents advertise compatible capabilities, a
requesting agent must select an appropriate peer and route
the request. In the UnionPay ecosystem, this selection may
depend on:
o Authorization context: the request must be routed to an
agent whose owning organization is authorized to provide
the requested information under the applicable
authorization.
Dunbar, et al. Expires Dec 6, 2027 [Page 23]
Internet-Draft GW Deployment Scenario
o Business relationship: the selected agent must be
associated with the correct counterparty institution.
o Operational health: the selected agent must be in active
lifecycle state and currently reachable.
o Tenant boundary: in multi-tenant deployments, the request
must be routed within the correct tenant scope.
This function is substantially more complex than what A2A
peer discovery provides. A2A can locate agents that match
capability criteria, but does not have visibility into
authorization context, business relationships, or operational
health state. The gateway, having onboarded and monitored
agents, has the necessary context for policy-aware routing.
6.4. Identity and Trust Establishment
In cross-organization deployments, trust cannot be
established by authentication alone. The gateway function for
trust establishment must bind agent interactions to:
o Agent identity: cryptographic verification of the agent's
identity.
o Organizational identity: verification that the agent is
operated by the claimed organization.
o Authorization context: verification that the specific
request is covered by a valid authorization (e.g., a
court order, regulatory mandate, or business agreement).
o Policy compliance: verification that the request complies
with local policies and applicable regulations.
This binding is the core differentiator between A2A
communication and gateway-mediated communication in regulated
financial environments. An agent communicating via A2A can
authenticate itself but cannot present organizational
authorization context in a standardized, machine-verifiable
form. The gateway provides the trust infrastructure that
makes organizational authorization context a first-class
element of agent interactions.
For embodied agents, agent identity verification may
additionally need to bind to the identity of the underlying
physical device, since admission and trust decisions are made
at the device level rather than only at the software-agent
level.
Dunbar, et al. Expires Dec 6, 2027 [Page 24]
Internet-Draft GW Deployment Scenario
6.5. Policy Enforcement and Governance
Policy enforcement is the function of evaluating whether a
request is permitted before it is routed to the target agent.
Policy enforcement may consider:
o Access control: is the requesting agent permitted to
invoke this capability?
o Tenant isolation: does the request cross a tenant
boundary that is not permitted?
o Rate limits and quotas: has the requesting agent or
organization exceeded its allowed invocation rate?
o Business rules: does the request comply with applicable
business agreements?
o Safety policy: does the request comply with site-level
safety constraints that must be enforced uniformly
regardless of which vendor's equipment is involved.
o Regulatory constraints: does the request comply with
applicable data handling regulations?
Centralizing policy enforcement in the gateway significantly
simplifies the requirements placed on individual agents.
Rather than requiring each agent to implement the full policy
set for every possible counterparty, the gateway provides a
common enforcement point. This is particularly important in
multi-vendor environments where agents may be unable to
interoperate on policy models.
6.6. Observability and Operational Visibility
The gateway collects non-content operational telemetry as a
natural byproduct of its other functions: routing events,
authorization decisions, health checks, lifecycle state
transitions, and audit records are all available to the
gateway without requiring inspection of encrypted agent
communications.
In the UnionPay context, this observability function must
support:
o Regulatory audits: producing records demonstrating that
data accesses were authorized, compliant, and traceable
Dunbar, et al. Expires Dec 6, 2027 [Page 25]
Internet-Draft GW Deployment Scenario
o Operational troubleshooting: identifying which agent or
gateway function caused a failure in a multi-step
workflow
o Anomaly detection: identifying unusual patterns in
request rates, capability invocations, or routing
decisions that may indicate security incidents
o Cross-tenant separation: ensuring that observability
records for different tenants are separated and
accessible only to authorized parties.
6.7. Gateway Synchronization and Information Exchange
In multi-domain deployments - such as the cross-organization
collaboration scenario in Section 4.5 - multiple gateways
must cooperate. Each bank may operate its own gateway, and
UnionPay may operate a platform-level gateway. For the IPO
auditing workflow to function, these gateways must be able
to:
o Exchange capability metadata: the UnionPay gateway must
know which statement retrieval capabilities are available
at each bank gateway, subject to the bank's visibility
policies.
o Propagate reachability updates: if a bank agent is
suspended or its endpoint changes, other gateways must be
notified.
o Coordinate authorization context: when an auditing
request carries a valid authorization, this authorization
context must be conveyed to the receiving gateway in a
verifiable form.
o Produce correlated audit records: the audit trail for a
cross-organization request must span gateways while
maintaining chain of custody.
The authorization context exchanged across gateways may
include human-approval evidence, carried inline or by
reference. Evidence used for a specific action should
identify the approving subject or role, the material action
parameters, the applicable scope, and the validity or status
conditions. It should be bound to a canonical representation
or digest of the action request.
Dunbar, et al. Expires Dec 6, 2027 [Page 26]
Internet-Draft GW Deployment Scenario
The receiving gateway evaluates the evidence under its own
trust anchors and policy. It does not treat the sending
gateway's allow-or-deny result as proof that the action is
authorized. If a material action parameter changes, the
evidence no longer covers the request. A shared action digest
may correlate the evidence, forwarded request, and local
enforcement decisions across audit records, but does not by
itself establish authorization or policy sufficiency
No existing standard addresses gateway-to-gateway information
exchange for agent ecosystems. This represents the most
significant interoperability gap identified in this document
and is a strong candidate for standardization work.
6.8. Network-Aware Mobility and Reachability
In addition to operational onboarding function, for embodied
agents that move across cell coverage areas, edge nodes, and
network slice domains, to select and route to a mobile agent
it additionally requires network-side context:
o Location and attachment context: the agent's current
geographic position, the cell or access point it is
attached to, and the edge computing node currently
serving it.
o Network quality context: current latency, bandwidth, and
reliability characteristics of the agent's active
connection, including any applicable network slice or QoS
guarantee.
o Continuity context: whether an in-progress task or
session can be maintained as the agent's underlying
network attachment changes, and what handoff is required
if it cannot.
This information originates within the telecom network itself
rather than within the agent, and therefore cannot be
obtained through capability advertisement alone. A gateway
function that maintains this context, in addition to the
lifecycle and ownership state established at onboarding, can
determine not only whether a candidate agent is reachable,
but whether it is currently the most suitable candidate for a
given task under present network conditions. This function
has no close counterpart in deployments where agents remain
at a fixed network location.
Dunbar, et al. Expires Dec 6, 2027 [Page 27]
Internet-Draft GW Deployment Scenario
6.9. Action-Level Authorization for Physical-World Operations
The trust establishment function binds an agent interaction
to verified agent identity, organizational identity,
authorization context, and policy compliance. For embodied
agents whose invocations produce direct physical-world
effects, a request that is properly authenticated and
authorized to be sent may still need to be evaluated again,
individually, before the physical action it requests is
permitted to execute.
Action-level authorization may consider:
o Spatial constraints: whether the requested action falls
within a zone the requesting agent or operation is
currently authorized to operate in.
o Temporal constraints: whether the action falls within an
approved time window.
o Human approval state: whether supervisory approval has
been obtained where required.
o Risk classification: whether the current risk level
associated with the action and its context permits
execution without additional review.
Among the conditions listed above, human approval state has a
different evidence property from spatial, temporal, and risk
conditions. The Gateway can evaluate spatial, temporal, and
risk conditions using local policy, network context, site
configuration, or operational state. Human approval, however,
represents an action by another party. Therefore, when strong
auditability is required, Gateway may need to verify approval
evidence that was created outside the Gateway, bound to the
specific action being authorized, and recorded separately
from the Gateway's own allow-or-deny decision.
Before permitting a physical-world effect, the gateway should
derive or verify an identifier for the exact requested action
and compare it with any required external approval evidence.
The gateway should refuse the action when the evidence is
missing, unverifiable, expired, revoked, stale, or bound to a
materially different action. Evidence verification and the
gateway's local allow-or-deny decision should be recorded
separately.
Dunbar, et al. Expires Dec 6, 2027 [Page 28]
Internet-Draft GW Deployment Scenario
Where evidence is single-use, reservation and consumption
should be atomic. An indeterminate outcome should not be
silently retried as though the authorization remained unused.
This distinction reinforces the separation between
communication-level trust and action-level authorization.
Communication-level trust determines whether an agent may
participate in an exchange; action-level authorization
determines whether a specific instruction may take effect in
the physical world. Treating them as a single authorization
decision is insufficient once agent invocations carry
physical consequences.
7. Gap Analysis
Section 3.5 established that existing mechanisms (MCP, A2A,
Agent Cards) do not address several key deployment
requirements. Sections 4 and 5 demonstrated, through concrete
scenarios, that these gaps result in real operational and
interoperability problems. This section consolidates the gap
analysis and identifies which gaps are candidates for
standardization.
7.1. Operational Management
Operational management encompasses agent onboarding,
lifecycle management, health monitoring, capability exposure
control, audit logging, and compliance reporting. These
functions are currently left to deployment-specific
implementations.
The gap: there is no standard model for representing agent
lifecycle state, ownership, compliance status, policy
bindings, physical location, maintenance state, safety
certification, or operational health in a form that is
interoperable across agent platforms, vendors, and
administrative domains. When agents from different vendors
are deployed in the same managed environment, each vendor's
agent management model must be translated to the others'
models, creating integration complexity that scales poorly.
Standardization candidate: a common information model for
agent operational state that is sufficient to support
admission control, lifecycle management, health monitoring,
and audit logging across heterogeneous implementations.
Dunbar, et al. Expires Dec 6, 2027 [Page 29]
Internet-Draft GW Deployment Scenario
7.2. Policy-Controlled Capability Exposure
Agent Cards and metadata mechanisms describe what an agent
can do but do not describe who is allowed to discover or
invoke those capabilities under what conditions.
The gap: there is no standard mechanism for expressing,
distributing, and enforcing capability visibility policies.
In multi-tenant and cross-organization deployments, each pair
of interacting parties must implement ad-hoc access control
for capability discovery, which prevents scalable agent
ecosystem development.
Standardization candidate: a standard mechanism for policy-
controlled capability exposure, including a way for an agent
or gateway to express visibility constraints on its
capabilities and for a requesting gateway to apply those
constraints consistently.
7.3. Multi-Tenant and Multi-Vendor Deployments
The gap: there is no standard approach for tenant-aware agent
discovery, routing, and policy enforcement. Each multi-tenant
platform must implement its own tenant isolation model,
making it difficult for agents or gateways from different
vendors to interoperate in a shared multi-tenant environment.
Standardization candidate: a common model for tenant context
in agent interactions, including how tenant identity is
expressed in capability queries, routing decisions, and
policy enforcement.
7.4. Cross-Organization Collaboration
The gap: there is no standard mechanism for binding agent
interactions to organizational identity, authorization
context, and business relationships in a form that is
machine-verifiable, cross-jurisdiction compliant, and
auditable. This gap is the principal barrier to scalable
cross-organization agent collaboration in regulated
industries.
Dunbar, et al. Expires Dec 6, 2027 [Page 30]
Internet-Draft GW Deployment Scenario
The consequences of this gap are significant: without
standard trust binding mechanisms, each pair of collaborating
organizations must establish custom integration, negotiate
custom audit record formats, and implement custom
authorization verification. In the UnionPay ecosystem, which
has thousands of participating institutions, this approach is
not scalable.
Standardization candidate: a standard mechanism for
organizational trust context in agent interactions, including
representation of organizational identity, authorization
context, and applicable business relationships. This is the
highest-priority standardization candidate identified in this
document.
7.5. Gateway Synchronization and Information Exchange
The gap: there is no standard mechanism for gateway-to-
gateway exchange of capability metadata, reachability
information, authorization context, or audit records. When
independently operated gateways need to cooperate - as in the
cross-organization IPO auditing scenario - each deployment
must implement custom integration.
Standardization candidate: a standard protocol for gateway-
to-gateway information exchange, including at minimum:
capability metadata distribution with policy-controlled
visibility, reachability update propagation, authorization
context conveyance, and correlated audit record production.
7.6. Mobility and Network Context Awareness
The deployment scenario of mobility-driven embodied agent
collaboration demonstrated that selecting and routing
requests to a mobile embodied agent depends on location,
attachment, and network-quality information that originates
within the operator's network rather than within the agent.
The gap: there is no standard mechanism for representing or
exchanging an agent's current network attachment context,
such as location, edge association, connectivity quality, and
applicable slice or QoS state, in a form gateway functions
can consistently use for agent selection, routing, and
session continuity. Existing capability metadata mechanisms
Dunbar, et al. Expires Dec 6, 2027 [Page 31]
Internet-Draft GW Deployment Scenario
describe what an agent can do, not where it currently is or
under what network conditions it is reachable.
Standardization candidate: a common representation for an
agent's dynamic network context, sufficient to support
mobility-aware reachability tracking, agent selection, and
task continuity as agents move across coverage areas, edge
nodes, and network domains.
7.7. Physical-World Action Authorization
The deployment scenario of localized authorization for high-
risk physical operations demonstrated that, for embodied
agents, communication-level trust establishment is not
sufficient to govern requests whose execution produces direct
physical-world consequences
The gap: there is no standard mechanism for expressing or
evaluating action-level authorization conditions, such as
spatial constraints, time windows, human approval state, and
risk classification, separately from the communication-level
trust established for the requesting agent. Without such a
mechanism, a request that is properly authenticated and
authorized to be sent may still execute a physical action
that the current context does not support.
Standardization candidate: a mechanism neutral
interoperability profile for carrying and verifying action
bound authorization evidence at a gateway. The profile may
define action binding, evidence status and freshness,
independent trust-anchor evaluation, refusal behavior, replay
protection, and single-use consumption requirements, while
leaving identity systems, policy languages, gateway
transport, and evidence-generation mechanisms outside its
scope.
7.8. Summary
The analysis in this section does not conclude that AI Agent
Gateways are required in all deployments. Small-scale
deployments may operate successfully using direct agent-to-
Dunbar, et al. Expires Dec 6, 2027 [Page 32]
Internet-Draft GW Deployment Scenario
agent communication, Agent Cards, local configuration, or
existing discovery mechanisms.
However, as deployments become larger, involve multiple
vendors or tenants, require stronger operational governance,
or span organizational boundaries, additional gateway
functions may provide value. Potential gaps include
operational onboarding, lifecycle and health-state
management, policy-controlled capability exposure, tenant-
aware discovery, trust coordination, auditability, and
gateway-to-gateway information exchange, network and mobility
context, and physical-world action authorization.
These gaps are most visible in managed deployments where
independently developed agents, platforms, catalogs, or
gateways need to exchange operational information or apply
consistent policy behavior across deployment boundaries..
8. Security Considerations
TBD.
9. Manageability Considerations
TBD
10. IANA Considerations
TBD
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Dunbar, et al. Expires Dec 6, 2027 [Page 33]
Internet-Draft GW Deployment Scenario
11.2. Informative References
[MCP] Model Context Protocol, "Model Context Protocol
Specification",
https://modelcontextprotocol.io/specification/
[A2A] Agent2Agent Protocol, "Agent2Agent Protocol
Documentation", https://a2a-protocol.org/.
12. Acknowledgments
Acknowledgements to Joe Clarke for their extensive review and
suggestions.
This document was prepared using 2-Word-v2.0.template.dot.
Appendix A:
Authors' Addresses
Linda Dunbar
Futurewei
Email: ldunbar@futurewei.com
YiFei Wang
China Telecom
wangyf85@chinatelecom.cn
Iman Schrock
Emilia Protocol AI
team@emiliaprotocol.ai
Bing Liu
Huawei
leo.liubing@huawei.com
Contributors' Addresses
Dunbar, et al. Expires Dec 6, 2027 [Page 34]