| Internet-Draft | Agent Gateway Policy | July 2026 |
| Zhao, et al. | Expires 7 January 2027 | [Page] |
This document defines an operational policy control model for operator-managed Agent Gateways. The model describes how an operator can control and observe interactions that are admitted, mediated, routed, proxied, or otherwise handled by an Agent Gateway.¶
The model does not govern an agent's internal behavior, reasoning, planning, prompts, memory, tools, runtime, or lifecycle. Instead, it uses agent-related identifiers, groups, tenants, task classes, and service levels as gateway-recognized policy matching attributes. Those attributes allow an operator-managed Agent Gateway to identify the interactions to which a policy applies.¶
The model defines four core policy classes: Interaction Access Control, QoS and Flow Control, Invocation and Token Control, and Path Selection. It further defines three supporting management capabilities: Subject and Attachment Binding, Applied Policy State and Telemetry, and Policy Lifecycle and Failure Handling.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 7 January 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
This section defines the four core policy classes.¶
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 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.¶
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 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.¶
This section defines the three supporting management models.¶
The Subject and Attachment Binding model relates gateway-recognized policy matching attributes to gateway-local and network-visible selectors.¶
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.¶
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.¶
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.¶
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.¶
The Policy Lifecycle and Failure Handling model defines how policies move from configuration to effective enforcement, and how failures are reported.¶
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.¶
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:¶
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.¶
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.¶
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:¶
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 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.¶
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 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 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.¶
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.¶
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 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 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.¶
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.¶
This section defines the YANG module for Agent Gateway policy control.¶
The tree diagram follows the notation defined in [RFC8340].¶
module: ietf-agent-gateway-policy
+--rw agent-gateway-policy
+--rw policy-subjects
| +--rw subject* [subject-id]
| +--rw subject-id string
| +--rw subject-type identityref
| +--rw tenant-id? string
| +--rw administrative-domain? string
| +--rw service-level? string
| +--rw task-class? string
| +--rw enabled? boolean
| +--rw description? string
|
+--rw agent-groups
| +--rw group* [group-id]
| +--rw group-id -> /policy-subjects/subject/subject-id
| +--rw member-subject* -> /policy-subjects/subject/subject-id
| +--rw membership-origin? identityref
| +--rw description? string
|
+--rw static-bindings
| +--rw binding* [binding-id]
| +--rw binding-id string
| +--rw subject-id -> /policy-subjects/subject/subject-id
| +--rw selectors
| | +--rw gateway-id? string
| | +--rw gateway-session-id? string
| | +--rw interface? string
| | +--rw source-prefix* inet:ip-prefix
| | +--rw destination-prefix* inet:ip-prefix
| | +--rw transport-protocol? uint8
| | +--rw source-port? inet:port-number
| | +--rw destination-port? inet:port-number
| | +--rw tunnel-id? string
| | +--rw network-instance? string
| | +--rw slice-id? string
| | +--rw flow-label? uint32
| | +--rw dscp? uint8
| +--rw valid-until? yang:date-and-time
|
+--rw policy-profiles
| +--rw profile* [profile-id]
| +--rw profile-id string
| +--rw enforcement-scope identityref
| +--rw precedence? uint32
| +--rw (core-policy-parameters)?
| | +--:(interaction-access-control)
| | | +--rw access-control
| | | +--rw default-action? identityref
| | | +--rw rule* [rule-id]
| | | +--rw rule-id string
| | | +--rw source-subject-id? -> /policy-subjects/subject/subject-id
| | | +--rw destination-subject-id? -> /policy-subjects/subject/subject-id
| | | +--rw action identityref
| | +--:(qos-flow-control)
| | | +--rw flow-control
| | | +--rw bandwidth-limit-kbps? uint64
| | | +--rw packet-rate-limit-pps? uint64
| | | +--rw burst-size-bytes? uint64
| | | +--rw dscp? uint8
| | | +--rw referenced-qos-policy? instance-identifier
| | +--:(invocation-token-control)
| | | +--rw invocation-control
| | | +--rw request-rate-limit? uint64
| | | +--rw token-rate-limit? uint64
| | | +--rw concurrent-limit? uint32
| | | +--rw interval? uint32
| | | +--rw exceed-action? identityref
| | +--:(path-selection)
| | +--rw path-selection
| | +--rw path-profile-id? string
| | +--rw preferred-path-type? identityref
| | +--rw routing-policy? instance-identifier
| | +--rw network-instance? string
| | +--rw slice-id? string
| +--rw telemetry-options
| | +--rw enable-packet-counters? boolean
| | +--rw enable-request-counters? boolean
| | +--rw enable-token-counters? boolean
| +--rw description? string
|
+--rw policy-assignments
| +--rw assignment* [assignment-id]
| +--rw assignment-id string
| +--rw source-subject-id -> /policy-subjects/subject/subject-id
| +--rw destination-subject-id? -> /policy-subjects/subject/subject-id
| +--rw profile-id -> /policy-profiles/profile/profile-id
| +--rw enabled? boolean
| +--rw valid-from? yang:date-and-time
| +--rw valid-until? yang:date-and-time
|
+--ro effective-bindings
| +--ro binding* [binding-id]
| +--ro binding-id string
| +--ro subject-id string
| +--ro selectors
| +--ro origin identityref
| +--ro verification-state identityref
| +--ro evidence-ref? string
| +--ro created-at? yang:date-and-time
| +--ro last-refreshed-at? yang:date-and-time
| +--ro expires-at? yang:date-and-time
|
+--ro applied-policies
| +--ro applied-policy* [applied-policy-id]
| +--ro applied-policy-id string
| +--ro assignment-id string
| +--ro binding-id* string
| +--ro effective-enforcement-scope identityref
| +--ro enforcement-point-id? string
| +--ro enforcement-point-type? string
| +--ro referenced-policy? instance-identifier
| +--ro enforcement-status identityref
| +--ro generation? uint64
| +--ro activated-at? yang:date-and-time
| +--ro last-updated-at? yang:date-and-time
| +--ro failure-reason? identityref
| +--ro failure-description? string
| +--ro statistics
| +--ro matched-packets? yang:counter64
| +--ro matched-bytes? yang:counter64
| +--ro permitted-requests? yang:counter64
| +--ro denied-requests? yang:counter64
| +--ro rate-limited-requests? yang:counter64
| +--ro consumed-tokens? yang:counter64
|
+---n binding-changed
+---n policy-status-changed
+---n policy-enforcement-failed
+---n quota-threshold-crossed
¶
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: <mailto:opsawg@ietf.org>";
description
"This module defines an operator-facing management model for
Agent Gateway policy control.
The model controls and observes interactions mediated by an
operator-managed Agent Gateway. Agent identifiers, agent
groups, tenants, service levels, and task classes are
gateway-recognized policy matching attributes; they do not
establish a management relationship with an agent.
The model is organized around four core policy classes and
three supporting management models. The four core policy
classes are interaction access control, QoS and flow control,
invocation and token control, and path selection. The
supporting management models are subject and attachment
binding, applied policy state and telemetry, and policy
lifecycle and failure handling.
This module does not define governance or control of an
agent's internal behavior, lifecycle, reasoning, planning,
prompt construction, memory, tool selection, or runtime
implementation.";
revision 2026-07-06 {
description
"Initial revision.";
reference
"RFC XXXX: Agent Gateway Policy Control Model";
}
/*
* 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 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.¶
TBD.¶