Agent Gateway Policy Control Model

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

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 when, and only when, they appear in all capitals, as shown here.

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.

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

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.

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

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.

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.

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

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

Reference Model The reference model is shown below. | 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.

Core Policy Classes This section defines the four core policy classes.

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.

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

Invocation and Token Control Invocation and Token Control governs gateway-visible application-layer resources. Such policies MAY include:

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.

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.

Supporting Management Models This section defines the three supporting management models.

Subject and Attachment Binding Model The Subject and Attachment Binding model relates gateway-recognized policy matching attributes to gateway-local and network-visible selectors.

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.

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:

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.

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

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

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.

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.

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;
policy conflict; and
unsupported capability.

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.

Binding Change Handling When a binding changes, the corresponding applied policy state may need to be updated. An implementation SHOULD support the following sequence:

derive the new effective binding;
create or update the corresponding enforcement instance;
verify activation of the new enforcement state;
withdraw stale enforcement state; and
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.

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

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.

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. For example: 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.

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.

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.

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

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.

Configuration Data Configuration data includes:

policy subjects;
agent group membership;
static gateway attachment bindings;
policy profiles; and
policy assignments.

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.

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.

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.

YANG Module This section defines the YANG module for Agent Gateway policy control. The tree diagram follows the notation defined in .

YANG Module Definition WG List: "; 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"; } /* * 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."; } 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."; } 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 { 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; 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 "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."; } 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 { 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 { 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."; } 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."; 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."; } 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 { 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."; } } 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 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 "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 { 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; 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 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."; 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."; } 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 "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 { 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; } 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; } } } } /* * 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."; 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."; } } } ]]>

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.

IANA Considerations TBD.