Agent Gateway Policy Control Model

Introduction AI agents are increasingly used to interact with other agents, invoke tools, access models, consume network resources, and consume compute or model resources. In operator-managed deployments, such interactions may traverse an Agent Gateway that is controlled by a network operator, service provider, or enterprise administrator. The central assumption of this document is that the operator can manage the Agent Gateway, but does not normally manage the internal behavior of each agent. The operator may not control an agent's reasoning process, planning logic, prompt construction, model-output filtering, local runtime, tool-selection algorithm, or software implementation. These aspects may be controlled by application providers, enterprise tenants, device owners, model providers, or other systems. Nevertheless, the operator can operate and control the Agent Gateway. The Agent Gateway can admit or reject sessions, identify authenticated or registered agent contexts, mediate interactions, apply request controls, limit resource usage, select paths, classify traffic, mark traffic, and expose operational state. Therefore, a policy control model scoped to the Agent Gateway can be useful and deployable.

Design Objective The objective of this document is to define an operator-facing policy control model for interactions mediated by an Agent Gateway. The operator manages the Agent Gateway and its associated enforcement mechanisms, rather than the internal behavior or lifecycle of an agent. Agent identifiers, agent groups, tenants, task classes, and service levels are used as gateway-recognized policy matching attributes that allow the operator to identify relevant interactions at the gateway. A policy defined by this document applies only to gateway-visible or network-visible effects of an interaction that is admitted, mediated, or otherwise handled by an operator-managed Agent Gateway. Such effects include interaction authorization, session admission, invocation limits, token limits, traffic treatment, and traffic steering. This model does not establish a management relationship with an agent. It does not define control of an agent's reasoning, planning, prompt construction, memory, tool-selection logic, runtime implementation, or lifecycle. Operator policies are often expressed in terms of agent-related matching attributes, for example:

permit Agent Group A to communicate with Agent Group B;
deny external agents from invoking critical internal agents;
limit Agent A to 10 Mbit/s;
limit trial agents to 100 model invocations per hour;
limit model-token consumption for a tenant;
send high-priority agent traffic through a private path; or
send low-priority agent traffic through public Internet access.

The enforcement mechanisms available to the operator are usually not agent-internal mechanisms. They are gateway-local controls, such as session admission, request filtering, invocation-rate control, token-rate control, and audit, or network mechanisms, such as ACLs, QoS policies, traffic policies, routing policies, VPN instances, traffic-engineering policies, or network slices. This document defines the policy control layer that connects these two views: Operator policy using gateway-recognized matching attributes | v Agent Gateway policy assignment | v Subject and attachment binding | v Gateway-local or network enforcement selection | v Applied policy state, telemetry, and lifecycle handling 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 three supporting management models are:

Subject and Attachment Binding;
Applied Policy State and Telemetry; and
Policy Lifecycle and Failure Handling.

The four core policy classes define what kinds of gateway-mediated interaction policies can be applied at the Agent Gateway. The three supporting models define how the policy matching attribute is identified, how it is associated with gateway or network selectors, how enforcement is observed, and how failures or lifecycle changes are reported. The purpose of this document is to define a management and policy control model for Agent Gateway operation. It does not redefine ACL, QoS, routing, VPN, traffic-engineering, network-slice, identity, DNS, service-discovery, or agent-runtime semantics.

Scope This document applies only to interactions that are admitted, mediated, or otherwise handled by an operator-managed Agent Gateway. It does not apply policy directly to an agent that is not represented by a gateway-visible context or a validated attachment binding. This document is in scope for:

policy control of operator-managed Agent Gateways;
gateway-recognized policy matching attributes, including locally known agent identifiers, agent groups, tenants, task classes, service levels, and administrative domains;
gateway attachment bindings that relate such matching attributes to gateway sessions or network selectors;
agent-to-agent, agent-to-tool, agent-to-model, and agent-to-service interaction access control enforced at the gateway or through referenced network mechanisms;
QoS and flow-control policies for traffic associated with gateway-recognized matching attributes;
invocation-rate and token-rate policies enforced at the gateway or model-gateway layer;
path-selection and traffic-steering policies for traffic associated with gateway-recognized matching attributes;
applied policy state, enforcement status, counters, failure reasons, and notifications; and
a YANG data model for configuration and operational state.

This document is out of scope for:

controlling the internal reasoning, planning, or decision-making logic of an agent;
defining how an agent identity is globally registered, named, or resolved;
defining DNS, service-discovery, or agent-registry protocols;
defining prompt governance, model-output filtering, agent memory management, or tool-selection algorithms;
redefining ACL, QoS, routing, VPN, traffic-engineering, or network-slice semantics;
defining inter-domain agent-policy exchange protocols; and
defining the full architecture of an Agent Gateway.

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.

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

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. Example: source-subject = external-agents destination-subject = critical-agents policy-class = interaction-access-control default-action = deny enforcement-scope = gateway-and-network

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. Example: source-subject = agent-a policy-class = qos-flow-control enforcement-scope = network bandwidth-limit-kbps = 10000

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. Example: source-subject = trial-agents policy-class = invocation-control enforcement-scope = gateway-local request-rate-limit = 100 requests per hour token-rate-limit = 100000 tokens per hour exceed-action = reject

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. Examples: source-subject = high-priority-agents policy-class = path-selection enforcement-scope = network path-profile = private-line and: source-subject = low-priority-agents policy-class = path-selection enforcement-scope = network path-profile = public-internet

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

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 ``` 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; 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: opsawg@ietf.org"; description "This module defines an operator-facing management model for Agent Gateway policy control. 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."; grouping access-control-parameters { description "Gateway-mediated interaction access-control policy parameters."; grouping flow-control-parameters { description "QoS and flow-control policy parameters."; grouping invocation-control-parameters { description "Gateway-local invocation and token control parameters."; grouping path-selection-parameters { description "Path-selection policy parameters."; 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."; grouping applied-policy-statistics { description "Operational counters associated with an applied policy."; /* * Data nodes */ container agent-gateway-policy { description "Top-level container for operator-facing Agent Gateway policy control."; /* * Notifications */ notification binding-changed { description "A gateway attachment binding has changed."; notification policy-status-changed { description "The status of an applied policy has changed."; notification policy-enforcement-failed { description "Policy enforcement has failed."; notification quota-threshold-crossed { description "A request, invocation, or token quota threshold has been crossed.";

Operational Considerations

Gateway Ownership and Trust Boundary The policy model is useful when the Agent Gateway is operated by a trusted operator, service provider, or enterprise administrator. The operator should clearly define the trust boundary between agents, the gateway, external identity systems, model providers, and network enforcement points.

Binding Freshness Attachment bindings are central to policy enforcement. Operators should configure suitable binding lifetimes according to deployment requirements. Short lifetimes reduce stale-policy risk but increase update overhead. Long lifetimes reduce update overhead but increase the risk of incorrect enforcement after agent movement.

Policy Conflict Conflicts may occur when multiple policy assignments apply to the same subject. An implementation MUST apply deterministic conflict resolution. The result of conflict resolution SHOULD be visible in operational state.

Fail-Open and Fail-Closed Behavior Different policy classes may require different failure behavior. For interaction access-control and isolation policies, fail-closed behavior SHOULD be supported. For resource-control or observation policies, degraded or best-effort operation MAY be acceptable according to operator policy.

Shared Attachments Multiple agents may share the same address, port, connection, proxy, tunnel, or gateway session. In such cases, the operator must not assume that network-layer enforcement can distinguish individual agents. When per-agent distinction is required but cannot be represented by network selectors, gateway-local enforcement SHOULD be used.

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.