Agent Gateway Policy Control Model
draft-zhao-opsawg-agent-gateway-policy-01
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 | Jing Zhao , Ran Pang , Shuai Zhang | ||
| Last updated | 2026-07-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-zhao-opsawg-agent-gateway-policy-01
OPSAWG J. Zhao, Ed.
Internet-Draft R. Pang
Intended status: Standards Track S. Zhang
Expires: 7 January 2027 China Unicom
6 July 2026
Agent Gateway Policy Control Model
draft-zhao-opsawg-agent-gateway-policy-01
Abstract
This document defines an operational policy control model for
operator-managed Agent Gateways. The model describes how an operator
can control and observe interactions that are admitted, mediated,
routed, proxied, or otherwise handled by an Agent Gateway.
The model does not govern an agent's internal behavior, reasoning,
planning, prompts, memory, tools, runtime, or lifecycle. Instead, it
uses agent-related identifiers, groups, tenants, task classes, and
service levels as gateway-recognized policy matching attributes.
Those attributes allow an operator-managed Agent Gateway to identify
the interactions to which a policy applies.
The model defines four core policy classes: Interaction Access
Control, QoS and Flow Control, Invocation and Token Control, and Path
Selection. It further defines three supporting management
capabilities: Subject and Attachment Binding, Applied Policy State
and Telemetry, and Policy Lifecycle and Failure Handling.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 7 January 2027.
Zhao, et al. Expires 7 January 2027 [Page 1]
Internet-Draft Agent Gateway Policy July 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
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Operational Scenarios . . . . . . . . . . . . . . . . . . . . 4
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Operators Control the Gateway, Not the Agent Runtime . . 5
4.2. Agent Identity and Network Selectors Differ . . . . . . . 5
4.3. Agent-Level Policies Need Gateway Bindings . . . . . . . 6
4.4. Gateway-Local and Network Enforcement Are Different . . . 6
4.5. Configuration Alone Is Insufficient . . . . . . . . . . . 6
5. Agent Gateway Policy Control Framework . . . . . . . . . . . 7
6. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 8
7. Core Policy Classes . . . . . . . . . . . . . . . . . . . . . 9
7.1. Interaction Access Control . . . . . . . . . . . . . . . 9
7.2. QoS and Flow Control . . . . . . . . . . . . . . . . . . 10
7.3. Invocation and Token Control . . . . . . . . . . . . . . 10
7.4. Path Selection . . . . . . . . . . . . . . . . . . . . . 11
8. Supporting Management Models . . . . . . . . . . . . . . . . 11
8.1. Subject and Attachment Binding Model . . . . . . . . . . 11
8.1.1. Policy Subjects . . . . . . . . . . . . . . . . . . . 12
8.1.2. Agent Groups . . . . . . . . . . . . . . . . . . . . 12
8.1.3. Gateway Attachment Bindings . . . . . . . . . . . . . 13
8.2. Applied Policy State and Telemetry Model . . . . . . . . 14
8.3. Policy Lifecycle and Failure Handling Model . . . . . . . 15
8.3.1. Enforcement Status . . . . . . . . . . . . . . . . . 16
8.3.2. Failure Reasons . . . . . . . . . . . . . . . . . . . 16
8.3.3. Conflict Handling . . . . . . . . . . . . . . . . . . 17
8.3.4. Binding Change Handling . . . . . . . . . . . . . . . 17
9. Policy Profiles and Assignments . . . . . . . . . . . . . . . 17
10. Enforcement Selection and Mapping . . . . . . . . . . . . . . 19
10.1. Mapping Agent Policies to Network Policies . . . . . . . 19
10.2. Gateway-Local Enforcement . . . . . . . . . . . . . . . 20
10.3. Network Enforcement . . . . . . . . . . . . . . . . . . 21
Zhao, et al. Expires 7 January 2027 [Page 2]
Internet-Draft Agent Gateway Policy July 2026
11. Relationship to Existing Mechanisms . . . . . . . . . . . . . 21
12. Management Data Model . . . . . . . . . . . . . . . . . . . . 22
12.1. Configuration Data . . . . . . . . . . . . . . . . . . . 22
12.2. Operational State . . . . . . . . . . . . . . . . . . . 23
12.3. Notifications . . . . . . . . . . . . . . . . . . . . . 23
13. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 23
13.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 24
13.2. YANG Module Definition . . . . . . . . . . . . . . . . . 26
14. Security Considerations . . . . . . . . . . . . . . . . . . . 54
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 54
16.1. Normative References . . . . . . . . . . . . . . . . . . 54
16.2. Informative References . . . . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55
1. Introduction
AI agents increasingly interact with other agents, tools, models,
services, and enterprise resources. In many deployments, these
interactions are admitted, mediated, routed, observed, or rejected by
an Agent Gateway.
An Agent Gateway may be operated by a network operator, service
provider, cloud provider, or enterprise administrator. The operator
can configure the gateway, observe its state, integrate it with
security and operations systems, and connect it to network
enforcement mechanisms. The operator will commonly not control the
internal implementation or lifecycle of each agent using the gateway.
This distinction defines the purpose of this document: * The operator
manages the Agent Gateway and the gateway's treatment of
interactions. * The operator does not manage or govern the internal
behavior of the agents using the gateway. * Agent-related information
is used to match policy to an interaction visible to the gateway; it
is not used to establish a management relationship with an agent.
For example, an operator may need to prevent an external interaction
from reaching a critical internal agent, limit a trial service to a
defined number of model invocations, apply differentiated treatment
to premium traffic, or steer a latency-sensitive interaction to an
assured path. These are operational controls on the managed gateway
and its associated enforcement mechanisms. They are not controls on
how an agent reasons, plans, selects a tool, or produces a response.
The word "model" in this document refers to an _operational policy
control model_. The model describes policy intent, the information
needed to match that intent to gateway-mediated interactions, the
available enforcement scopes, and the operational state that an
Zhao, et al. Expires 7 January 2027 [Page 3]
Internet-Draft Agent Gateway Policy July 2026
operator needs to observe. A future YANG data model may represent
these concepts, but this document is not limited to YANG or to any
one implementation technology.
2. 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.
3. Operational Scenarios
This section illustrates the operational problem addressed by the
framework. The examples are not protocol specifications.
* Protection of Critical Internal Agents: An enterprise may operate
internal agents that can access sensitive systems, business
processes, or data. The enterprise may allow interactions from
approved internal agents while preventing interactions from
external, untrusted, or trial agents.
* Differentiated Network Treatment: A provider may offer a premium
service level for latency-sensitive agent interactions. The
provider may want traffic associated with that service level to
receive a defined QoS treatment or to use an assured private path.
* Differentiated Network Treatment: A provider may offer a premium
service level for latency-sensitive agent interactions. The
provider may want traffic associated with that service level to
receive a defined QoS treatment or to use an assured private path.
* Tenant Separation and Accounting: A multi-tenant Agent Gateway may
serve independent enterprises or business units. The operator may
need separate access permissions, resource limits, counters, and
audit records for each tenant.
4. Problem Statement
Existing network management mechanisms are effective at configuring
packet, flow, interface, topology, or service policies. Agent-based
systems introduce policy expressions that are closer to the agent,
tenant, service-level, task, or invocation abstraction. An operator
may want to configure policies such as "Agent Group A can access
Agent Group B", "Agent A is limited to 10 Mbit/s", or "high-priority
agents use a private path". These policies are meaningful to
operators, but they are not directly executable by most network
Zhao, et al. Expires 7 January 2027 [Page 4]
Internet-Draft Agent Gateway Policy July 2026
devices.
The problem is not that existing network policy mechanisms are
missing. The problem is that Agent Gateway policy control needs a
standard way to represent:
* the agent-related subject to which a policy applies;
* the gateway attachment state that relates the subject to
executable selectors;
* the policy class and requested enforcement scope;
* whether enforcement is performed at the gateway, in the network,
or both;
* which existing policy object is referenced, when applicable;
* whether the policy has actually become active; and
* what operational counters or failures are associated with the
policy.
The following issues motivate this document.
4.1. Operators Control the Gateway, Not the Agent Runtime
An operator can operate an Agent Gateway under its administrative
control. The operator can configure the gateway, observe gateway
state, and integrate the gateway with network controllers, OSS, BSS,
telemetry, and security systems.
The operator normally does not control the internal implementation of
each agent. Therefore, a standard policy model that attempts to
govern the internal agent runtime, reasoning process, prompt
construction, or planning logic is less likely to be deployable in
operator-managed environments.
This document therefore scopes policy control to the Agent Gateway
and its associated enforcement mechanisms.
4.2. Agent Identity and Network Selectors Differ
An operator may express policy using an agent identifier, agent
group, tenant, or service level. A network enforcement point
typically enforces policy using selectors such as source address,
destination address, transport port, interface, tunnel, VPN instance,
network slice, routing instance, DSCP, or flow label.
Zhao, et al. Expires 7 January 2027 [Page 5]
Internet-Draft Agent Gateway Policy July 2026
A direct one-to-one mapping between an agent and an IP address or
port is often invalid. An agent may move, reconnect, scale out,
share an address with other agents, or be represented by a proxy,
service mesh, sidecar, or gateway.
An implementation MUST NOT assume that an agent is permanently
equivalent to an IP address, transport port, tunnel, VPN instance,
network slice, or gateway session.
4.3. Agent-Level Policies Need Gateway Bindings
A policy such as "limit Agent A to 10 Mbit/s" can only be enforced if
the policy control component can determine the current gateway
attachment or network selectors associated with Agent A. The mapping
can be configured, learned during authentication, derived from
session establishment, provided by a registry, supplied by a
controller, or observed locally by the gateway.
A policy model therefore needs to represent binding creation,
validation, refresh, expiration, withdrawal, and verification state.
4.4. Gateway-Local and Network Enforcement Are Different
Some policies require gateway-local enforcement because the required
context is visible only at the Agent Gateway. Examples include
authenticated agent sessions, agent-to-agent invocation context,
request-rate limits, model-token usage, concurrent invocations, and
application-layer allow/deny decisions.
Other policies can be applied through network mechanisms when
suitable selectors are available. Examples include ACLs, bandwidth
limits, QoS marking, traffic treatment, VPN steering, slice
selection, and routing policy.
The model MUST distinguish gateway-local enforcement from network
enforcement.
4.5. Configuration Alone Is Insufficient
Operators need to know not only what policy was configured, but
whether the policy has actually been applied. Applied policy state
is needed to determine:
* which policy assignments apply to a subject;
* which bindings were used;
* which enforcement scope was selected;
Zhao, et al. Expires 7 January 2027 [Page 6]
Internet-Draft Agent Gateway Policy July 2026
* which enforcement points were used;
* whether the policy is pending, active, partially active, stale,
failed, or withdrawn;
* why enforcement failed; and
* what counters are associated with the applied policy.
5. Agent Gateway Policy Control Framework
The Agent Gateway policy control model is organized around four core
policy classes and three supporting management models.
The four core policy classes define the types of gateway-mediated
interaction policies that can be configured and enforced at an
operator-managed Agent Gateway:
* Interaction Access Control;
* QoS and Flow Control;
* Invocation and Token Control; and
* Path Selection.
The three supporting management models define how these policies are
associated with gateway-recognized matching attributes, how they are
applied to gateway-local or network enforcement mechanisms, and how
the resulting enforcement state is observed:
* Subject and Attachment Binding;
* Applied Policy State and Telemetry; and
* Policy Lifecycle and Failure Handling.
The four core policy classes describe what policy functions are
provided. The three supporting management models describe how those
policies are made operable, including subject resolution, binding
validation, enforcement selection, applied state, counters, failure
reporting, and lifecycle updates.
An implementation is not required to support all four core policy
classes. For every supported core policy class, the implementation
MUST expose the corresponding gateway-recognized subject association,
effective enforcement scope, applied policy state, and lifecycle
status.
Zhao, et al. Expires 7 January 2027 [Page 7]
Internet-Draft Agent Gateway Policy July 2026
An implementation that supports network enforcement MUST expose the
validated attachment binding or other evidence used to derive the
network selectors. An implementation that supports only gateway-
local enforcement is not required to create network selectors.
6. Reference Model
The reference model is shown below.
+----------------------+ +----------------------------------+
| Operator / OSS / | ----> | Operator-Managed Agent Gateway |
| Controller | | |
+----------------------+ | Policy Control Component |
| Gateway-Local Enforcement |
| - Interaction access control |
| - Session admission |
| - Invocation and token control |
| - Audit and counters |
+----------------------------------+
^ |
| v
gateway-mediated interactions associated network
| enforcement
+----------------------+ +----------------------+
| Agents / Tools / | | ACL / QoS / TE / |
| Models / Services | | VPN / Slice / |
+----------------------+ | Traffic Steering |
+----------------------+
The policy control component controls the Agent Gateway's handling of
gateway-mediated interactions. It MAY be implemented inside the
Agent Gateway, in a controller associated with the gateway, or as a
combination of both. This document does not require a specific
implementation placement.
The Agent Gateway or policy control component MAY interact with
identity providers, authorization systems, agent registries, DNS or
service discovery systems, telemetry collectors, audit systems,
network controllers, OSS, and BSS systems. Such systems may provide
input to the policy process, but this document does not define their
protocols.
The reference model assumes that the operator manages the Agent
Gateway or the policy control component. It does not assume that the
operator controls the internal runtime behavior of each agent.
Zhao, et al. Expires 7 January 2027 [Page 8]
Internet-Draft Agent Gateway Policy July 2026
7. Core Policy Classes
This section defines the four core policy classes.
7.1. Interaction Access Control
Interaction Access Control determines whether an interaction mediated
by an Agent Gateway is permitted, denied, or rejected.
An access-control policy MAY be expressed between a source subject
and a destination subject. The subjects are gateway-recognized
policy matching attributes and MAY identify an individual agent, an
agent group, a tenant, a task class, a service level, or an
administrative domain.
A destination subject MAY represent another agent, an agent group, a
tool, a model, a service, an API, or another gateway-visible
resource.
An interaction access-control policy MAY represent:
* a whitelist rule;
* a blacklist rule;
* a default-permit or default-deny rule;
* a rule based on agent identifier;
* a rule based on agent group membership;
* a rule based on tenant or administrative domain;
* a rule based on service level or task class; or
* a rule based on gateway attachment context.
Interaction Access Control governs the handling of an interaction at
the Agent Gateway. It does not imply management authority over
either endpoint of that interaction. It SHOULD be enforced at the
Agent Gateway when the required context is visible at the gateway.
If suitable validated network selectors are available, the same
policy assignment MAY also reference existing network ACL mechanisms.
This document does not redefine ACL semantics. It defines how an
interaction access-control assignment is bound to gateway-local or
network enforcement state.
Zhao, et al. Expires 7 January 2027 [Page 9]
Internet-Draft Agent Gateway Policy July 2026
7.2. QoS and Flow Control
QoS and Flow Control governs network-visible resource treatment for
traffic associated with a gateway-recognized policy matching
attribute.
Such policies MAY include:
* bandwidth limit;
* packet-rate limit;
* burst size;
* DSCP marking;
* traffic class;
* queue or scheduling treatment;
* shaping or policing behavior; or
* a reference to an existing QoS or traffic policy object.
When an operator configures a policy such as:
Limit Agent A to 10 Mbit/s.
the policy control component resolves Agent A to current gateway
attachment bindings and applies the corresponding flow-control policy
using the available selectors. The resulting enforcement state is
reported as applied policy state.
A QoS or flow-control policy MUST NOT be reported as active for per-
agent network enforcement unless the selected network selectors can
identify the relevant agent traffic at the required granularity.
This policy class is intended for network-visible resources. It is
not intended to represent token quotas, prompt budgets, model-compute
budgets, or other application-layer resources unless an explicit
deployment-specific mapping is configured.
7.3. Invocation and Token Control
Invocation and Token Control governs gateway-visible application-
layer resources.
Such policies MAY include:
Zhao, et al. Expires 7 January 2027 [Page 10]
Internet-Draft Agent Gateway Policy July 2026
* request-rate limit;
* model-invocation-rate limit;
* token-rate limit;
* token-quota limit;
* concurrent-invocation limit;
* session limit; and
* exceed action.
Token-rate and invocation-rate controls are normally gateway-local
controls. They SHOULD be enforced at the Agent Gateway, model
gateway, API gateway, or another application-layer enforcement point.
Token-rate limits MUST NOT be automatically represented as packet-
level network policies unless an explicit deployment-specific mapping
is configured by the operator.
7.4. Path Selection
Path Selection influences the path or service treatment used by
traffic associated with a gateway-recognized policy matching
attribute.
Such policies MAY be expressed in terms of an individual agent, agent
group, tenant, service level, or task class. The applied policy
state MAY refer to existing mechanisms such as routing policy,
traffic engineering, Segment Routing policy, VPN service, private
path, local breakout, or network slice.
This document does not define path computation, forwarding behavior,
or routing protocol extensions. It specifies how a policy assignment
is associated with path-selection enforcement state.
8. Supporting Management Models
This section defines the three supporting management models.
8.1. Subject and Attachment Binding Model
The Subject and Attachment Binding model relates gateway-recognized
policy matching attributes to gateway-local and network-visible
selectors.
Zhao, et al. Expires 7 January 2027 [Page 11]
Internet-Draft Agent Gateway Policy July 2026
8.1.1. Policy Subjects
A policy subject is a gateway-recognized policy matching attribute
that identifies the entity or class of entities to which an Agent
Gateway policy applies. A policy subject does not establish a
management relationship with the represented entity.
A policy subject MAY represent:
* an individual agent;
* an agent group;
* a tenant;
* an administrative domain;
* a task class;
* a service level; or
* another implementation-defined subject type.
A policy subject MUST have a locally unique subject identifier within
the Agent Gateway policy control system.
A policy subject SHOULD include a subject type. The subject type
indicates whether the subject represents an agent, agent group,
tenant, administrative domain, task class, service level, or another
implementation-defined type.
This document does not define how an agent identifier is issued,
authenticated, globally scoped, or resolved. A deployment MAY obtain
such information from identity systems, registries, DNS-based
mechanisms, authorization systems, attestation systems, or gateway-
local onboarding mechanisms.
An implementation MUST NOT use an unauthenticated or unverified agent
identifier as the sole basis for security-sensitive enforcement
unless explicitly allowed by operator policy.
8.1.2. Agent Groups
An agent group is a gateway-recognized policy matching attribute that
represents multiple agents or other policy matching attributes.
Agent group membership MAY be:
Zhao, et al. Expires 7 January 2027 [Page 12]
Internet-Draft Agent Gateway Policy July 2026
* statically configured by the operator;
* learned from an external identity or inventory system;
* resolved dynamically by the Agent Gateway;
* derived from tenant, service-level, or task-class metadata; or
* implementation-specific.
When group membership is provided by an external system, the
implementation SHOULD expose whether the membership state is
configured, externally learned, dynamically resolved, or stale.
Agent groups are used by interaction access-control policies, QoS
policies, invocation-control policies, and path-selection policies.
Telemetry is a supporting management function that may be enabled for
any supported core policy class.
8.1.3. Gateway Attachment Bindings
A gateway attachment binding associates a gateway-recognized policy
matching attribute with one or more selectors that can be used for
gateway-local or network enforcement.
A binding MAY include:
* gateway identifier;
* gateway session identifier;
* ingress or egress interface;
* source or destination IP prefix;
* source or destination transport port;
* transport protocol;
* tunnel identifier;
* VPN instance;
* network slice;
* routing instance;
* DSCP value;
Zhao, et al. Expires 7 January 2027 [Page 13]
Internet-Draft Agent Gateway Policy July 2026
* IPv6 flow label; or
* another locally significant identifier.
A binding MAY be statically configured, dynamically learned, locally
observed, or externally supplied. Dynamic bindings may be derived
from authentication, session establishment, registration, metadata
synchronization, controller state, service-mesh state, or local
observation.
A binding MUST have a validity context. The validity context MUST
include enough information for an implementation to determine whether
the binding is valid, stale, expired, or unverified.
An implementation MUST NOT use an expired binding for active network
enforcement unless the applied policy state is explicitly reported as
stale, partially active, or failed.
An implementation MUST NOT claim per-agent network enforcement unless
the available selectors can distinguish the relevant agent from other
agents sharing the same network-visible attributes.
8.2. Applied Policy State and Telemetry Model
The Applied Policy State and Telemetry model records the effective
result of applying a policy assignment through selected enforcement
mechanisms.
Applied policy state MUST identify:
* the related policy assignment;
* the effective enforcement scope;
* the enforcement status; and
* the enforcement point or enforcement-point class.
Applied policy state SHOULD identify:
* related gateway attachment bindings;
* referenced network policy object, when applicable;
* activation time;
* generation or version;
Zhao, et al. Expires 7 January 2027 [Page 14]
Internet-Draft Agent Gateway Policy July 2026
* failure reason, when applicable; and
* operational counters.
Applied policy state is not the same as the configured assignment.
The assignment expresses operator intent. Applied policy state
records what has actually been applied.
An implementation MUST expose applied policy state indicating whether
a policy assignment is pending, active, partially active, stale,
failed, or withdrawn.
Telemetry associated with applied policy state MAY include:
* matched packets;
* matched bytes;
* permitted requests;
* denied requests;
* rate-limited requests;
* consumed tokens;
* active sessions;
* selected path;
* binding changes; and
* enforcement failures.
Counters SHOULD be associated with applied policy state rather than
only with the original policy assignment. This enables the operator
to determine which binding and enforcement point produced a
measurement.
8.3. Policy Lifecycle and Failure Handling Model
The Policy Lifecycle and Failure Handling model defines how policies
move from configuration to effective enforcement, and how failures
are reported.
Zhao, et al. Expires 7 January 2027 [Page 15]
Internet-Draft Agent Gateway Policy July 2026
8.3.1. Enforcement Status
The following enforcement status values are defined:
* pending: the policy has been selected for enforcement but
enforcement has not been confirmed;
* active: the policy has been successfully applied to the intended
enforcement scope;
* partially-active: the policy has been applied to some, but not
all, required enforcement points or bindings;
* stale: the policy depends on attachment binding information that
is no longer current;
* failed: the policy could not be applied; and
* withdrawn: the policy has been removed or deactivated.
An implementation MUST maintain enforcement status for each applied
policy.
An implementation SHOULD update enforcement status when the
corresponding assignment, binding, enforcement point, or referenced
policy object changes.
8.3.2. Failure Reasons
When policy enforcement fails, the implementation MUST expose a
failure reason.
The failure reason MUST allow the operator to distinguish at least
the following categories:
* subject-resolution failure;
* binding unavailable;
* binding expired;
* unsupported selector;
* referenced policy missing;
* enforcement-point unreachable;
* policy programming failure;
Zhao, et al. Expires 7 January 2027 [Page 16]
Internet-Draft Agent Gateway Policy July 2026
* policy conflict; and
* unsupported capability.
8.3.3. Conflict Handling
Conflicts may occur when multiple policy assignments apply to the
same subject or enforcement scope.
An implementation MUST apply a deterministic conflict resolution
procedure. The procedure MAY be based on precedence, policy class,
administrative state, validity period, or implementation-defined
local policy.
The selected result SHOULD be visible in operational state.
8.3.4. Binding Change Handling
When a binding changes, the corresponding applied policy state may
need to be updated.
An implementation SHOULD support the following sequence:
1. derive the new effective binding;
2. create or update the corresponding enforcement instance;
3. verify activation of the new enforcement state;
4. withdraw stale enforcement state; and
5. record any failure or partial enforcement.
For access-control and isolation policies, fail-closed behavior
SHOULD be supported when a required binding is unavailable or stale.
For resource-control or observation policies, degraded or best-effort
behavior MAY be acceptable according to operator policy.
9. Policy Profiles and Assignments
A policy profile is a reusable operator-defined policy object. It
describes the requested enforcement scope and exactly one core policy
parameter set.
A policy profile MUST contain exactly one core policy parameter set.
The selected parameter set determines whether the profile represents
Interaction Access Control, QoS and Flow Control, Invocation and
Token Control, or Path Selection.
Zhao, et al. Expires 7 January 2027 [Page 17]
Internet-Draft Agent Gateway Policy July 2026
A policy profile MUST identify a requested enforcement scope. The
requested enforcement scope is one of:
* gateway-local;
* network; or
* gateway-and-network.
A policy profile MAY include telemetry options that apply to the
selected core policy class. Telemetry and accounting are supporting
management functions; they are not an additional core policy class.
A policy profile MAY reference existing network policy objects, such
as ACLs, QoS policies, routing policies, VPN services, traffic-
engineering policies, Segment Routing policies, or network-slice
profiles. This document does not change the semantics of such
referenced objects.
A policy assignment associates a policy profile with a source policy
subject and, when applicable, a destination policy subject.
A policy assignment MAY include:
* assignment identifier;
* source subject;
* destination subject;
* policy profile;
* precedence;
* administrative state;
* validity period; and
* conflict-handling behavior.
A policy assignment is expressed at the gateway-recognized
abstraction level. It does not need to contain the current IP
address, port, tunnel, interface, network slice, or gateway session
of the subject.
A policy assignment MUST reference a valid policy subject.
A policy assignment MUST reference a valid policy profile.
Zhao, et al. Expires 7 January 2027 [Page 18]
Internet-Draft Agent Gateway Policy July 2026
When a destination subject is present, the assignment applies to
interactions from the source subject to the destination subject.
This is commonly used for interaction access-control policies.
10. Enforcement Selection and Mapping
Enforcement selection determines whether a policy assignment is
applied through gateway-local enforcement, network enforcement, or
both.
Enforcement selection MAY depend on:
* policy class;
* requested enforcement scope;
* available gateway attachment bindings;
* selector availability;
* enforcement-point capabilities;
* trust in the binding;
* required enforcement granularity;
* operator configuration; and
* local policy.
An implementation MUST distinguish gateway-local enforcement from
network enforcement in applied policy state.
If the requested enforcement scope cannot be satisfied, the
implementation MUST NOT report the policy as active for that scope.
The implementation MAY report the applied policy state as pending,
partially active, stale, or failed, depending on the failure
condition.
If network enforcement is not possible but gateway-local enforcement
is possible, the implementation MAY apply the policy at the gateway
and report the effective enforcement scope accordingly.
10.1. Mapping Agent Policies to Network Policies
When network enforcement is selected, the policy control component
maps agent-related policy assignments to network selectors derived
from gateway attachment bindings.
Zhao, et al. Expires 7 January 2027 [Page 19]
Internet-Draft Agent Gateway Policy July 2026
For example:
Operator policy:
Limit Agent A to 10 Mbit/s.
Resolved binding:
agent-id = agent-a
gateway-session-id = session-123
source-prefix = 192.0.2.18/32
source-port = 45020
interface = access-interface-17
Network enforcement:
Apply traffic policy rate-limit-10m to traffic matching the
resolved selectors.
The mapping is dynamic and deployment-specific. This document
defines the management model for representing the binding and applied
state; it does not define a new network policy language.
10.2. Gateway-Local Enforcement
Gateway-local enforcement is appropriate when the policy depends on
information that is visible at the gateway but not visible at the
network layer.
Examples include:
* authenticated agent session;
* agent-to-agent invocation context;
* tool or model invocation context;
* request counters;
* token counters;
* concurrent invocation counts; and
* application-layer access-control decisions.
Application-layer controls such as request-rate limits, token-rate
limits, and concurrent invocation limits SHOULD be enforced at an
Agent Gateway or application-layer enforcement point.
Zhao, et al. Expires 7 January 2027 [Page 20]
Internet-Draft Agent Gateway Policy July 2026
10.3. Network Enforcement
Network enforcement is appropriate when the policy can be expressed
using selectors and enforcement capabilities supported by a network
enforcement point.
Examples include:
* ACLs;
* QoS policies;
* flow-control policies;
* routing policies;
* traffic-engineering policies;
* VPN steering; and
* network-slice selection.
When a policy is applied through network enforcement, the applied
policy state SHOULD identify the referenced network policy object,
enforcement point, and related bindings.
This document does not redefine the semantics of any referenced
network policy object.
11. Relationship to Existing Mechanisms
This document complements Agent Gateway architecture and agent-aware
networking work. Agent Gateway architecture documents describe
gateway functions such as discovery, protocol mediation, routing,
security, model access, tool access, and network connectivity. This
document focuses on the policy control model that allows operator-
defined agent-related policies to be resolved into current gateway
attachments, selected for gateway-local or network enforcement, and
exposed as applied policy state.
This document does not replace existing network policy models.
Existing ACL, QoS, routing, VPN, traffic-engineering, and network-
slice models define technology-specific policy semantics. The model
in this document defines the Agent Gateway policy layer that binds
agent-related policy subjects to those enforcement mechanisms.
Zhao, et al. Expires 7 January 2027 [Page 21]
Internet-Draft Agent Gateway Policy July 2026
This document also does not define how agents themselves are operated
or governed. It assumes that an operator-managed gateway can mediate
and control interactions that pass through it.
12. Management Data Model
This document defines management data for Agent Gateway policy
control. The management model includes configuration data,
operational state, and notifications.
The managed objects are:
* policy subjects;
* agent groups;
* static attachment bindings;
* policy profiles;
* policy assignments;
* effective attachment bindings;
* applied policies;
* operational counters;
* failure state; and
* notifications.
The YANG module in (#yang-module) provides the normative data model
for these objects.
12.1. Configuration Data
Configuration data includes:
* policy subjects;
* agent group membership;
* static gateway attachment bindings;
* policy profiles; and
* policy assignments.
Zhao, et al. Expires 7 January 2027 [Page 22]
Internet-Draft Agent Gateway Policy July 2026
A policy subject configuration identifies the gateway-recognized
policy matching attribute to which policies can apply.
A static attachment binding configuration associates a subject with
selectors known by the operator.
A policy profile configuration defines reusable policy parameters
and, when applicable, references to existing gateway-local or network
policy objects.
A policy assignment configuration associates a policy profile with a
source matching attribute and, optionally, a destination matching
attribute.
12.2. Operational State
Operational state includes:
* effective attachment bindings;
* applied policies;
* enforcement status;
* failure reasons;
* operational counters; and
* last update timestamps.
Operational state MUST allow an operator to determine whether a
configured assignment has actually been applied.
12.3. Notifications
The management model defines notifications for significant changes in
policy state.
An implementation SHOULD support notifications for binding changes,
policy enforcement failures, quota threshold crossing, and policy
status changes when the corresponding functions are implemented.
13. YANG Module
This section defines the YANG module for Agent Gateway policy
control.
The tree diagram follows the notation defined in [RFC8340].
Zhao, et al. Expires 7 January 2027 [Page 23]
Internet-Draft Agent Gateway Policy July 2026
13.1. Tree Diagram
module: ietf-agent-gateway-policy
+--rw agent-gateway-policy
+--rw policy-subjects
| +--rw subject* [subject-id]
| +--rw subject-id string
| +--rw subject-type identityref
| +--rw tenant-id? string
| +--rw administrative-domain? string
| +--rw service-level? string
| +--rw task-class? string
| +--rw enabled? boolean
| +--rw description? string
|
+--rw agent-groups
| +--rw group* [group-id]
| +--rw group-id -> /policy-subjects/subject/subject-id
| +--rw member-subject* -> /policy-subjects/subject/subject-id
| +--rw membership-origin? identityref
| +--rw description? string
|
+--rw static-bindings
| +--rw binding* [binding-id]
| +--rw binding-id string
| +--rw subject-id -> /policy-subjects/subject/subject-id
| +--rw selectors
| | +--rw gateway-id? string
| | +--rw gateway-session-id? string
| | +--rw interface? string
| | +--rw source-prefix* inet:ip-prefix
| | +--rw destination-prefix* inet:ip-prefix
| | +--rw transport-protocol? uint8
| | +--rw source-port? inet:port-number
| | +--rw destination-port? inet:port-number
| | +--rw tunnel-id? string
| | +--rw network-instance? string
| | +--rw slice-id? string
| | +--rw flow-label? uint32
| | +--rw dscp? uint8
| +--rw valid-until? yang:date-and-time
|
+--rw policy-profiles
| +--rw profile* [profile-id]
| +--rw profile-id string
| +--rw enforcement-scope identityref
| +--rw precedence? uint32
Zhao, et al. Expires 7 January 2027 [Page 24]
Internet-Draft Agent Gateway Policy July 2026
| +--rw (core-policy-parameters)?
| | +--:(interaction-access-control)
| | | +--rw access-control
| | | +--rw default-action? identityref
| | | +--rw rule* [rule-id]
| | | +--rw rule-id string
| | | +--rw source-subject-id? -> /policy-subjects/subject/subject-id
| | | +--rw destination-subject-id? -> /policy-subjects/subject/subject-id
| | | +--rw action identityref
| | +--:(qos-flow-control)
| | | +--rw flow-control
| | | +--rw bandwidth-limit-kbps? uint64
| | | +--rw packet-rate-limit-pps? uint64
| | | +--rw burst-size-bytes? uint64
| | | +--rw dscp? uint8
| | | +--rw referenced-qos-policy? instance-identifier
| | +--:(invocation-token-control)
| | | +--rw invocation-control
| | | +--rw request-rate-limit? uint64
| | | +--rw token-rate-limit? uint64
| | | +--rw concurrent-limit? uint32
| | | +--rw interval? uint32
| | | +--rw exceed-action? identityref
| | +--:(path-selection)
| | +--rw path-selection
| | +--rw path-profile-id? string
| | +--rw preferred-path-type? identityref
| | +--rw routing-policy? instance-identifier
| | +--rw network-instance? string
| | +--rw slice-id? string
| +--rw telemetry-options
| | +--rw enable-packet-counters? boolean
| | +--rw enable-request-counters? boolean
| | +--rw enable-token-counters? boolean
| +--rw description? string
|
+--rw policy-assignments
| +--rw assignment* [assignment-id]
| +--rw assignment-id string
| +--rw source-subject-id -> /policy-subjects/subject/subject-id
| +--rw destination-subject-id? -> /policy-subjects/subject/subject-id
| +--rw profile-id -> /policy-profiles/profile/profile-id
| +--rw enabled? boolean
| +--rw valid-from? yang:date-and-time
| +--rw valid-until? yang:date-and-time
|
+--ro effective-bindings
| +--ro binding* [binding-id]
Zhao, et al. Expires 7 January 2027 [Page 25]
Internet-Draft Agent Gateway Policy July 2026
| +--ro binding-id string
| +--ro subject-id string
| +--ro selectors
| +--ro origin identityref
| +--ro verification-state identityref
| +--ro evidence-ref? string
| +--ro created-at? yang:date-and-time
| +--ro last-refreshed-at? yang:date-and-time
| +--ro expires-at? yang:date-and-time
|
+--ro applied-policies
| +--ro applied-policy* [applied-policy-id]
| +--ro applied-policy-id string
| +--ro assignment-id string
| +--ro binding-id* string
| +--ro effective-enforcement-scope identityref
| +--ro enforcement-point-id? string
| +--ro enforcement-point-type? string
| +--ro referenced-policy? instance-identifier
| +--ro enforcement-status identityref
| +--ro generation? uint64
| +--ro activated-at? yang:date-and-time
| +--ro last-updated-at? yang:date-and-time
| +--ro failure-reason? identityref
| +--ro failure-description? string
| +--ro statistics
| +--ro matched-packets? yang:counter64
| +--ro matched-bytes? yang:counter64
| +--ro permitted-requests? yang:counter64
| +--ro denied-requests? yang:counter64
| +--ro rate-limited-requests? yang:counter64
| +--ro consumed-tokens? yang:counter64
|
+---n binding-changed
+---n policy-status-changed
+---n policy-enforcement-failed
+---n quota-threshold-crossed
13.2. YANG Module Definition
module ietf-agent-gateway-policy {
yang-version 1.1;
namespace
"urn:ietf:params:xml:ns:yang:ietf-agent-gateway-policy";
prefix agp;
import ietf-yang-types {
prefix yang;
Zhao, et al. Expires 7 January 2027 [Page 26]
Internet-Draft Agent Gateway Policy July 2026
reference
"RFC 6991: Common YANG Data Types";
}
import ietf-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types";
}
organization
"IETF Operations and Management Area Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: <mailto:opsawg@ietf.org>";
description
"This module defines an operator-facing management model for
Agent Gateway policy control.
The model controls and observes interactions mediated by an
operator-managed Agent Gateway. Agent identifiers, agent
groups, tenants, service levels, and task classes are
gateway-recognized policy matching attributes; they do not
establish a management relationship with an agent.
The model is organized around four core policy classes and
three supporting management models. The four core policy
classes are interaction access control, QoS and flow control,
invocation and token control, and path selection. The
supporting management models are subject and attachment
binding, applied policy state and telemetry, and policy
lifecycle and failure handling.
This module does not define governance or control of an
agent's internal behavior, lifecycle, reasoning, planning,
prompt construction, memory, tool selection, or runtime
implementation.";
revision 2026-07-06 {
description
"Initial revision.";
reference
"RFC XXXX: Agent Gateway Policy Control Model";
}
/*
Zhao, et al. Expires 7 January 2027 [Page 27]
Internet-Draft Agent Gateway Policy July 2026
* Identities
*/
identity subject-type-base {
description
"Base identity for policy subject types.";
}
identity subject-agent {
base subject-type-base;
description
"A policy subject representing an individual agent.";
}
identity subject-agent-group {
base subject-type-base;
description
"A policy subject representing a group of agents.";
}
identity subject-tenant {
base subject-type-base;
description
"A policy subject representing a tenant.";
}
identity subject-administrative-domain {
base subject-type-base;
description
"A policy subject representing an administrative domain.";
}
identity subject-task-class {
base subject-type-base;
description
"A policy subject representing a task class.";
}
identity subject-service-level {
base subject-type-base;
description
"A policy subject representing a service level.";
}
identity membership-origin-base {
description
"Base identity for agent group membership origin.";
}
Zhao, et al. Expires 7 January 2027 [Page 28]
Internet-Draft Agent Gateway Policy July 2026
identity membership-configured {
base membership-origin-base;
description
"Group membership is configured locally.";
}
identity membership-external {
base membership-origin-base;
description
"Group membership is supplied by an external system.";
}
identity membership-dynamic {
base membership-origin-base;
description
"Group membership is dynamically resolved.";
}
identity enforcement-scope-base {
description
"Base identity for enforcement scope.";
}
identity scope-gateway-local {
base enforcement-scope-base;
description
"Enforcement performed at the Agent Gateway or a related
application-layer enforcement point.";
}
identity scope-network {
base enforcement-scope-base;
description
"Enforcement performed through network mechanisms.";
}
identity scope-gateway-and-network {
base enforcement-scope-base;
description
"Enforcement performed both at the gateway and through
network mechanisms.";
}
identity policy-action-base {
description
"Base identity for policy actions.";
}
Zhao, et al. Expires 7 January 2027 [Page 29]
Internet-Draft Agent Gateway Policy July 2026
identity action-permit {
base policy-action-base;
description
"Permit the interaction or traffic.";
}
identity action-deny {
base policy-action-base;
description
"Deny the interaction or traffic.";
}
identity action-reject {
base policy-action-base;
description
"Reject the request or interaction.";
}
identity action-degrade {
base policy-action-base;
description
"Apply degraded treatment.";
}
identity action-queue {
base policy-action-base;
description
"Queue the request or interaction.";
}
identity action-notify-only {
base policy-action-base;
description
"Generate notification but do not block.";
}
identity action-terminate-session {
base policy-action-base;
description
"Terminate the related session.";
}
identity preferred-path-type-base {
description
"Base identity for preferred path type.";
}
identity path-private {
Zhao, et al. Expires 7 January 2027 [Page 30]
Internet-Draft Agent Gateway Policy July 2026
base preferred-path-type-base;
description
"Prefer a private or dedicated path.";
}
identity path-public-internet {
base preferred-path-type-base;
description
"Prefer public Internet access.";
}
identity path-low-latency {
base preferred-path-type-base;
description
"Prefer a low-latency path.";
}
identity path-low-cost {
base preferred-path-type-base;
description
"Prefer a low-cost path.";
}
identity binding-origin-base {
description
"Base identity for the origin of an attachment binding.";
}
identity binding-configured {
base binding-origin-base;
description
"The binding is statically configured.";
}
identity binding-learned {
base binding-origin-base;
description
"The binding is dynamically learned.";
}
identity binding-observed {
base binding-origin-base;
description
"The binding is locally observed by the Agent Gateway.";
}
identity binding-external {
base binding-origin-base;
Zhao, et al. Expires 7 January 2027 [Page 31]
Internet-Draft Agent Gateway Policy July 2026
description
"The binding is supplied by an external system.";
}
identity verification-state-base {
description
"Base identity for binding verification state.";
}
identity verify-verified {
base verification-state-base;
description
"The binding has been verified.";
}
identity verify-unverified {
base verification-state-base;
description
"The binding has not been verified.";
}
identity verify-stale {
base verification-state-base;
description
"The binding is stale.";
}
identity verify-expired {
base verification-state-base;
description
"The binding has expired.";
}
identity enforcement-status-base {
description
"Base identity for enforcement status.";
}
identity status-pending {
base enforcement-status-base;
description
"The policy has been selected for enforcement but enforcement
has not been confirmed.";
}
identity status-active {
base enforcement-status-base;
description
Zhao, et al. Expires 7 January 2027 [Page 32]
Internet-Draft Agent Gateway Policy July 2026
"The policy has been successfully applied.";
}
identity status-partially-active {
base enforcement-status-base;
description
"The policy has been partially applied.";
}
identity status-stale {
base enforcement-status-base;
description
"The applied policy depends on stale binding information.";
}
identity status-failed {
base enforcement-status-base;
description
"Policy enforcement has failed.";
}
identity status-withdrawn {
base enforcement-status-base;
description
"The applied policy has been withdrawn.";
}
identity failure-reason-base {
description
"Base identity for enforcement failure reasons.";
}
identity fail-subject-unresolved {
base failure-reason-base;
description
"The policy subject could not be resolved.";
}
identity fail-binding-unavailable {
base failure-reason-base;
description
"A required binding is unavailable.";
}
identity fail-binding-expired {
base failure-reason-base;
description
"A required binding has expired.";
Zhao, et al. Expires 7 January 2027 [Page 33]
Internet-Draft Agent Gateway Policy July 2026
}
identity fail-unsupported-selector {
base failure-reason-base;
description
"A required selector is not supported by the enforcement point.";
}
identity fail-referenced-policy-missing {
base failure-reason-base;
description
"A referenced policy object is missing.";
}
identity fail-enforcement-point-unreachable {
base failure-reason-base;
description
"The enforcement point cannot be reached.";
}
identity fail-policy-programming-failed {
base failure-reason-base;
description
"Programming the enforcement point failed.";
}
identity fail-policy-conflict {
base failure-reason-base;
description
"The policy conflicts with another policy.";
}
identity fail-capability-unsupported {
base failure-reason-base;
description
"A required capability is not supported.";
}
/*
* Groupings
*/
grouping selector-set {
description
"A set of gateway or network selectors that may be used for
policy enforcement.";
leaf gateway-id {
Zhao, et al. Expires 7 January 2027 [Page 34]
Internet-Draft Agent Gateway Policy July 2026
type string;
description
"Agent Gateway identifier.";
}
leaf gateway-session-id {
type string;
description
"Gateway session identifier.";
}
leaf interface {
type string;
description
"A locally significant interface identifier.";
}
leaf-list source-prefix {
type inet:ip-prefix;
description
"Source IP prefixes associated with the binding.";
}
leaf-list destination-prefix {
type inet:ip-prefix;
description
"Destination IP prefixes associated with the binding.";
}
leaf transport-protocol {
type uint8;
description
"IP transport protocol number.";
}
leaf source-port {
type inet:port-number;
description
"Source transport port.";
}
leaf destination-port {
type inet:port-number;
description
"Destination transport port.";
}
leaf tunnel-id {
Zhao, et al. Expires 7 January 2027 [Page 35]
Internet-Draft Agent Gateway Policy July 2026
type string;
description
"A locally significant tunnel identifier.";
}
leaf network-instance {
type string;
description
"A locally significant network instance, routing instance,
or VPN identifier.";
}
leaf slice-id {
type string;
description
"A locally significant network slice identifier.";
}
leaf flow-label {
type uint32 {
range "0..1048575";
}
description
"IPv6 flow label value.";
}
leaf dscp {
type uint8 {
range "0..63";
}
description
"DSCP value.";
}
}
grouping access-control-parameters {
description
"Gateway-mediated interaction access-control policy parameters.";
leaf default-action {
type identityref {
base policy-action-base;
}
default "action-deny";
description
"Default action for the access-control profile.";
}
Zhao, et al. Expires 7 January 2027 [Page 36]
Internet-Draft Agent Gateway Policy July 2026
list rule {
key "rule-id";
description
"Access-control rule.";
leaf rule-id {
type string;
description
"Rule identifier.";
}
leaf source-subject-id {
type leafref {
path "/agp:agent-gateway-policy/agp:policy-subjects"
+ "/agp:subject/agp:subject-id";
require-instance false;
}
description
"Optional source gateway-recognized policy matching
attribute for the rule.";
}
leaf destination-subject-id {
type leafref {
path "/agp:agent-gateway-policy/agp:policy-subjects"
+ "/agp:subject/agp:subject-id";
require-instance false;
}
description
"Optional destination gateway-recognized policy matching
attribute for the rule.";
}
leaf action {
type identityref {
base policy-action-base;
}
mandatory true;
description
"Rule action.";
}
}
}
grouping flow-control-parameters {
description
"QoS and flow-control policy parameters.";
Zhao, et al. Expires 7 January 2027 [Page 37]
Internet-Draft Agent Gateway Policy July 2026
leaf bandwidth-limit-kbps {
type uint64;
units "kilobits per second";
description
"Bandwidth limit.";
}
leaf packet-rate-limit-pps {
type uint64;
units "packets per second";
description
"Packet-rate limit.";
}
leaf burst-size-bytes {
type uint64;
units "bytes";
description
"Burst size.";
}
leaf dscp {
type uint8 {
range "0..63";
}
description
"DSCP value to mark or match.";
}
leaf referenced-qos-policy {
type instance-identifier {
require-instance false;
}
description
"Reference to an existing QoS or traffic policy object.";
}
}
grouping invocation-control-parameters {
description
"Gateway-local invocation and token control parameters.";
leaf request-rate-limit {
type uint64;
description
"Maximum number of requests in the measurement interval.";
}
Zhao, et al. Expires 7 January 2027 [Page 38]
Internet-Draft Agent Gateway Policy July 2026
leaf token-rate-limit {
type uint64;
description
"Maximum number of model tokens in the measurement interval.";
}
leaf concurrent-limit {
type uint32;
description
"Maximum number of concurrent invocations or sessions.";
}
leaf interval {
type uint32;
units "seconds";
description
"Measurement interval.";
}
leaf exceed-action {
type identityref {
base policy-action-base;
}
description
"Action when the limit is exceeded.";
}
}
grouping path-selection-parameters {
description
"Path-selection policy parameters.";
leaf path-profile-id {
type string;
description
"Identifier of a locally defined path profile.";
}
leaf preferred-path-type {
type identityref {
base preferred-path-type-base;
}
description
"Preferred path type.";
}
leaf routing-policy {
type instance-identifier {
Zhao, et al. Expires 7 January 2027 [Page 39]
Internet-Draft Agent Gateway Policy July 2026
require-instance false;
}
description
"Reference to an existing routing or traffic-engineering
policy object.";
}
leaf network-instance {
type string;
description
"Network instance, routing instance, or VPN to use.";
}
leaf slice-id {
type string;
description
"Network slice identifier.";
}
}
grouping telemetry-options {
description
"Telemetry options that apply to the selected core policy
class. Telemetry and accounting are supporting management
functions, not an additional core policy class.";
leaf enable-packet-counters {
type boolean;
default "false";
description
"Enable packet and byte counters when available.";
}
leaf enable-request-counters {
type boolean;
default "false";
description
"Enable request counters when available.";
}
leaf enable-token-counters {
type boolean;
default "false";
description
"Enable token counters when available.";
}
}
Zhao, et al. Expires 7 January 2027 [Page 40]
Internet-Draft Agent Gateway Policy July 2026
grouping applied-policy-statistics {
description
"Operational counters associated with an applied policy.";
leaf matched-packets {
type yang:counter64;
description
"Number of packets matched by the applied policy.";
}
leaf matched-bytes {
type yang:counter64;
description
"Number of bytes matched by the applied policy.";
}
leaf permitted-requests {
type yang:counter64;
description
"Number of permitted requests.";
}
leaf denied-requests {
type yang:counter64;
description
"Number of denied requests.";
}
leaf rate-limited-requests {
type yang:counter64;
description
"Number of rate-limited requests.";
}
leaf consumed-tokens {
type yang:counter64;
description
"Number of consumed model tokens.";
}
}
/*
* Data nodes
*/
container agent-gateway-policy {
description
"Top-level container for operator-facing Agent Gateway policy
Zhao, et al. Expires 7 January 2027 [Page 41]
Internet-Draft Agent Gateway Policy July 2026
control.";
container policy-subjects {
description
"Configured gateway-recognized policy matching attributes.";
list subject {
key "subject-id";
description
"A gateway-recognized policy matching attribute.";
leaf subject-id {
type string;
description
"Locally unique identifier for a gateway-recognized
policy matching attribute.";
}
leaf subject-type {
type identityref {
base subject-type-base;
}
mandatory true;
description
"Type of the policy matching attribute.";
}
leaf tenant-id {
type string;
description
"Tenant identifier associated with the subject.";
}
leaf administrative-domain {
type string;
description
"Administrative domain associated with the subject.";
}
leaf service-level {
type string;
description
"Service level associated with the subject.";
}
leaf task-class {
type string;
description
Zhao, et al. Expires 7 January 2027 [Page 42]
Internet-Draft Agent Gateway Policy July 2026
"Task class associated with the subject.";
}
leaf enabled {
type boolean;
default "true";
description
"Administrative state of the subject.";
}
leaf description {
type string;
description
"Textual description of the subject.";
}
}
}
container agent-groups {
description
"Configured or learned agent groups.";
list group {
key "group-id";
description
"An agent group.";
leaf group-id {
type leafref {
path "/agp:agent-gateway-policy/agp:policy-subjects"
+ "/agp:subject/agp:subject-id";
}
description
"Identifier of the policy subject that represents this
agent group.";
}
leaf-list member-subject {
type leafref {
path "/agp:agent-gateway-policy/agp:policy-subjects"
+ "/agp:subject/agp:subject-id";
}
description
"Member gateway-recognized policy matching attributes.";
}
leaf membership-origin {
type identityref {
Zhao, et al. Expires 7 January 2027 [Page 43]
Internet-Draft Agent Gateway Policy July 2026
base membership-origin-base;
}
default "membership-configured";
description
"Origin of the group membership.";
}
leaf description {
type string;
description
"Textual description of the group.";
}
}
}
container static-bindings {
description
"Statically configured gateway attachment bindings.";
list binding {
key "binding-id";
description
"A static gateway attachment binding.";
leaf binding-id {
type string;
description
"Binding identifier.";
}
leaf subject-id {
type leafref {
path "/agp:agent-gateway-policy/agp:policy-subjects"
+ "/agp:subject/agp:subject-id";
}
mandatory true;
description
"Policy matching attribute associated with the binding.";
}
container selectors {
description
"Selectors associated with the binding.";
uses selector-set;
}
leaf valid-until {
type yang:date-and-time;
Zhao, et al. Expires 7 January 2027 [Page 44]
Internet-Draft Agent Gateway Policy July 2026
description
"Time until which the binding is valid.";
}
}
}
container policy-profiles {
description
"Configured policy profiles.";
list profile {
key "profile-id";
description
"A reusable policy profile.";
leaf profile-id {
type string;
description
"Policy profile identifier.";
}
leaf enforcement-scope {
type identityref {
base enforcement-scope-base;
}
mandatory true;
description
"Requested enforcement scope.";
}
leaf precedence {
type uint32;
default "0";
description
"Policy precedence. Higher values indicate higher
precedence.";
}
choice core-policy-parameters {
mandatory true;
description
"Selects exactly one core policy class and its
parameters.";
case interaction-access-control {
container access-control {
description
"Gateway-mediated interaction access-control
Zhao, et al. Expires 7 January 2027 [Page 45]
Internet-Draft Agent Gateway Policy July 2026
parameters.";
uses access-control-parameters;
}
}
case qos-flow-control {
container flow-control {
description
"QoS and flow-control parameters.";
uses flow-control-parameters;
}
}
case invocation-token-control {
container invocation-control {
description
"Gateway-local invocation and token-control
parameters.";
uses invocation-control-parameters;
}
}
case path-selection {
container path-selection {
description
"Path-selection parameters.";
uses path-selection-parameters;
}
}
}
container telemetry-options {
description
"Telemetry options for the selected core policy class.";
uses telemetry-options;
}
leaf description {
type string;
description
"Textual description of the policy profile.";
}
}
}
container policy-assignments {
description
"Configured policy assignments.";
Zhao, et al. Expires 7 January 2027 [Page 46]
Internet-Draft Agent Gateway Policy July 2026
list assignment {
key "assignment-id";
description
"A policy assignment.";
leaf assignment-id {
type string;
description
"Policy assignment identifier.";
}
leaf source-subject-id {
type leafref {
path "/agp:agent-gateway-policy/agp:policy-subjects"
+ "/agp:subject/agp:subject-id";
}
mandatory true;
description
"Source gateway-recognized policy matching attribute.";
}
leaf destination-subject-id {
type leafref {
path "/agp:agent-gateway-policy/agp:policy-subjects"
+ "/agp:subject/agp:subject-id";
require-instance false;
}
description
"Optional destination gateway-recognized policy matching
attribute.";
}
leaf profile-id {
type leafref {
path "/agp:agent-gateway-policy/agp:policy-profiles"
+ "/agp:profile/agp:profile-id";
}
mandatory true;
description
"Referenced policy profile.";
}
leaf enabled {
type boolean;
default "true";
description
"Administrative state of the assignment.";
}
Zhao, et al. Expires 7 January 2027 [Page 47]
Internet-Draft Agent Gateway Policy July 2026
leaf valid-from {
type yang:date-and-time;
description
"Start time of assignment validity.";
}
leaf valid-until {
type yang:date-and-time;
description
"End time of assignment validity.";
}
}
}
container effective-bindings {
config false;
description
"Operational state for effective gateway attachment bindings.";
list binding {
key "binding-id";
description
"An effective gateway attachment binding.";
leaf binding-id {
type string;
description
"Binding identifier.";
}
leaf subject-id {
type string;
description
"Gateway-recognized policy matching attribute associated
with the binding.";
}
container selectors {
description
"Selectors associated with the binding.";
uses selector-set;
}
leaf origin {
type identityref {
base binding-origin-base;
}
description
Zhao, et al. Expires 7 January 2027 [Page 48]
Internet-Draft Agent Gateway Policy July 2026
"Origin of the binding.";
}
leaf verification-state {
type identityref {
base verification-state-base;
}
description
"Verification state of the binding.";
}
leaf evidence-ref {
type string;
description
"Reference to evidence supporting the binding.";
}
leaf created-at {
type yang:date-and-time;
description
"Creation time.";
}
leaf last-refreshed-at {
type yang:date-and-time;
description
"Last refresh time.";
}
leaf expires-at {
type yang:date-and-time;
description
"Expiration time.";
}
}
}
container applied-policies {
config false;
description
"Operational state for applied policies.";
list applied-policy {
key "applied-policy-id";
description
"An applied policy state entry.";
leaf applied-policy-id {
Zhao, et al. Expires 7 January 2027 [Page 49]
Internet-Draft Agent Gateway Policy July 2026
type string;
description
"Applied policy identifier.";
}
leaf assignment-id {
type string;
description
"Policy assignment that produced this applied policy.";
}
leaf-list binding-id {
type string;
description
"Attachment bindings used by this applied policy.";
}
leaf effective-enforcement-scope {
type identityref {
base enforcement-scope-base;
}
description
"Effective enforcement scope.";
}
leaf enforcement-point-id {
type string;
description
"Identifier of the enforcement point.";
}
leaf enforcement-point-type {
type string;
description
"Type of the enforcement point.";
}
leaf referenced-policy {
type instance-identifier {
require-instance false;
}
description
"Reference to the applied or referenced policy object.";
}
leaf enforcement-status {
type identityref {
base enforcement-status-base;
Zhao, et al. Expires 7 January 2027 [Page 50]
Internet-Draft Agent Gateway Policy July 2026
}
mandatory true;
description
"Enforcement status.";
}
leaf generation {
type uint64;
description
"Generation or version number.";
}
leaf activated-at {
type yang:date-and-time;
description
"Time at which the applied policy became active.";
}
leaf last-updated-at {
type yang:date-and-time;
description
"Last update time.";
}
leaf failure-reason {
type identityref {
base failure-reason-base;
}
description
"Failure reason.";
}
leaf failure-description {
type string;
description
"Additional diagnostic text.";
}
container statistics {
description
"Counters associated with the applied policy.";
uses applied-policy-statistics;
}
}
}
}
/*
Zhao, et al. Expires 7 January 2027 [Page 51]
Internet-Draft Agent Gateway Policy July 2026
* Notifications
*/
notification binding-changed {
description
"A gateway attachment binding has changed.";
leaf binding-id {
type string;
description
"Binding identifier.";
}
leaf subject-id {
type string;
description
"Policy subject identifier.";
}
}
notification policy-status-changed {
description
"The status of an applied policy has changed.";
leaf applied-policy-id {
type string;
description
"Applied policy identifier.";
}
leaf assignment-id {
type string;
description
"Policy assignment identifier.";
}
leaf enforcement-status {
type identityref {
base enforcement-status-base;
}
description
"New enforcement status.";
}
}
notification policy-enforcement-failed {
description
"Policy enforcement has failed.";
Zhao, et al. Expires 7 January 2027 [Page 52]
Internet-Draft Agent Gateway Policy July 2026
leaf applied-policy-id {
type string;
description
"Applied policy identifier.";
}
leaf assignment-id {
type string;
description
"Policy assignment identifier.";
}
leaf failure-reason {
type identityref {
base failure-reason-base;
}
description
"Failure reason.";
}
}
notification quota-threshold-crossed {
description
"A request, invocation, or token quota threshold has been crossed.";
leaf applied-policy-id {
type string;
description
"Applied policy identifier.";
}
leaf assignment-id {
type string;
description
"Policy assignment identifier.";
}
leaf threshold-type {
type string;
description
"Threshold type.";
}
}
}
Zhao, et al. Expires 7 January 2027 [Page 53]
Internet-Draft Agent Gateway Policy July 2026
14. Security Considerations
Security considerations will be expanded in future revisions.
The following aspects require particular attention:
* authenticity of agent identifiers used as policy subjects;
* authorization of policy configuration changes;
* protection of gateway attachment binding state;
* prevention of stale or forged binding use;
* protection of applied policy state and counters;
* fail-closed behavior for access-control and isolation policies;
* privacy of agent identifiers, token counters, and interaction
logs;
* secure communication between the Agent Gateway and network
enforcement points; and
* auditability of policy changes and enforcement failures.
An implementation MUST protect the management interface according to
existing secure management practices, including authentication,
authorization, integrity protection, and confidentiality.
15. IANA Considerations
TBD.
16. References
16.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Zhao, et al. Expires 7 January 2027 [Page 54]
Internet-Draft Agent Gateway Policy July 2026
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>.
16.2. Informative References
[RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair,
"YANG Data Model for Network Access Control Lists (ACLs)",
RFC 8519, DOI 10.17487/RFC8519, March 2019,
<https://www.rfc-editor.org/info/rfc8519>.
[RFC9067] Qu, Y., Tantsura, J., Lindem, A., and X. Liu, "A YANG Data
Model for Routing Policy", RFC 9067, DOI 10.17487/RFC9067,
October 2021, <https://www.rfc-editor.org/info/rfc9067>.
[RFC9899] Gonzalez de Dios, O., Barguil, S., Boucadair, M., and Q.
Wu, "Extensions to the YANG Data Model for Access Control
Lists (ACLs)", RFC 9899, DOI 10.17487/RFC9899, December
2025, <https://www.rfc-editor.org/info/rfc9899>.
Authors' Addresses
Jing Zhao (editor)
China Unicom
Beijing
China
Email: zhaoj501@chinaunicom.cn
Zhao, et al. Expires 7 January 2027 [Page 55]
Internet-Draft Agent Gateway Policy July 2026
Ran Pang
China Unicom
Beijing
China
Email: pangran@chinaunicom.cn
Shuai Zhang
China Unicom
Beijing
China
Email: zhangs366@chinaunicom.cn
Zhao, et al. Expires 7 January 2027 [Page 56]