Internet-Draft                                           AI/Agent WG
Intended status: standards-track                             March 2026
Expires: September 02, 2026


         Agent Behavior Verification Protocol (ABVP) for Runtime Compliance Validation
         draft-ai-agent-behavior-verification-protocol-00

Abstract

   This document defines the Agent Behavior Verification Protocol
   (ABVP), a standardized framework for continuously validating that
   deployed AI agents operate according to their declared policies
   and specifications. As autonomous agents become increasingly
   prevalent in critical systems, there is a growing gap between
   stated agent capabilities and actual runtime behavior
   verification. ABVP provides mechanisms for real-time behavior
   monitoring, policy compliance validation, and cryptographic
   attestation of agent actions against predefined behavioral
   specifications. The protocol defines a verification architecture
   that includes behavior witnesses, compliance checkers, and
   attestation chains to ensure agents maintain fidelity to their
   declared operational parameters. ABVP integrates with existing
   agent accountability frameworks while providing specific
   mechanisms for runtime verification, behavioral drift detection,
   and compliance reporting. This specification addresses the
   critical need for trustworthy agent deployment by enabling
   operators to continuously verify agent behavior matches stated
   policies throughout the agent lifecycle.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   This document is intended to have standards-track status.
   Distribution of this memo is unlimited.

Table of Contents

   1.  Introduction  ................................................  3
   2.  Terminology  .................................................  4
   3.  Problem Statement  ...........................................  5
   4.  Agent Behavior Verification Architecture  ....................  6
   5.  Behavior Specification Format  ...............................  7
   6.  Runtime Verification Protocol  ...............................  8
   7.  Compliance Reporting and Attestation  ........................  9
   8.  Security Considerations  .....................................  10
   9.  IANA Considerations  .........................................  11

1.  Introduction

   The proliferation of autonomous AI agents in critical
   infrastructure, financial systems, and decision-making processes
   has created an urgent need for continuous verification that these
   agents operate according to their declared policies and behavioral
   specifications. Traditional approaches to agent deployment rely on
   pre-deployment testing and static policy validation, which fail to
   address the dynamic nature of agent behavior in production
   environments. As agents adapt, learn, and respond to changing
   conditions, their actual runtime behavior may diverge
   significantly from their original specifications, creating
   security vulnerabilities, compliance violations, and operational
   risks that remain undetected until system failures occur.

   Existing agent accountability frameworks primarily focus on post-
   hoc analysis and audit trails, providing limited capability for
   real-time behavior verification and immediate detection of policy
   violations. This reactive approach is insufficient for autonomous
   systems that make critical decisions with limited human oversight,
   where behavioral drift or policy violations can have immediate and
   severe consequences. Current verification methodologies also lack
   standardized protocols for expressing behavioral constraints in
   machine-verifiable formats, making it difficult to establish
   consistent compliance validation across diverse agent
   implementations and deployment environments.

   The gap between declared agent capabilities and actual runtime
   behavior verification represents a fundamental trust problem in
   autonomous systems deployment. Organizations deploying AI agents
   face significant challenges in ensuring that agents continue to
   operate within specified parameters throughout their operational
   lifecycle, particularly as agents encounter novel situations not
   covered in initial testing scenarios. This verification gap
   undermines confidence in agent reliability and limits the adoption
   of autonomous systems in high-stakes environments where behavioral
   compliance is critical for safety, security, and regulatory
   compliance.

   The Agent Behavior Verification Protocol (ABVP) addresses these
   challenges by providing a standardized framework for continuous
   runtime verification of agent behavior against declared
   specifications. ABVP enables real-time monitoring of agent
   actions, automated compliance checking against behavioral
   policies, and cryptographic attestation of verification results to
   establish trust chains for agent operation validation. The
   protocol is designed to integrate with existing agent
   architectures while providing mechanisms for detecting behavioral
   drift, validating policy adherence, and generating verifiable
   evidence of agent compliance throughout the operational lifecycle.
   This specification defines the core protocol mechanisms, message
   formats, and verification procedures necessary to implement
   trustworthy agent behavior validation in production deployments.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
   in this document are to be interpreted as described in RFC 2119
   [RFC2119].

   Agent: An autonomous software entity that performs actions or
   makes decisions according to defined policies and specifications.
   In the context of ABVP, an agent is a system whose runtime
   behavior requires continuous verification against its declared
   operational parameters and behavioral constraints.

   Behavior Specification: A formally defined set of policies,
   constraints, and operational parameters that describe the expected
   and permitted actions of an agent. A behavior specification MUST
   be machine-readable and verifiable, containing sufficient detail
   to enable automated compliance checking during agent runtime
   operation.

   Behavior Witness: A system component or external entity that
   observes and records agent actions for verification purposes. A
   behavior witness MUST provide cryptographically signed
   attestations of observed agent behavior and MAY operate
   independently of the agent being monitored to ensure verification
   integrity.

   Compliance Validation: The process of evaluating agent runtime
   behavior against its declared behavior specification to determine
   conformance. Compliance validation encompasses real-time
   monitoring, policy checking, and the generation of verification
   results that attest to agent adherence to specified behavioral
   constraints.

   Verification Attestation: A cryptographically signed statement
   that asserts the compliance status of an agent's behavior relative
   to its specification during a defined time period. Verification
   attestations MUST include sufficient detail to enable third-party
   validation and SHOULD reference the specific behavior
   specification version and verification criteria used in the
   assessment.

   Behavioral Drift: The phenomenon where an agent's actual runtime
   behavior gradually diverges from its declared specification over
   time, either due to learning adaptations, environmental changes,
   or system degradation. ABVP mechanisms MUST be capable of
   detecting behavioral drift and reporting deviations from
   established behavioral baselines.

3.  Problem Statement

   The proliferation of autonomous AI agents in critical
   infrastructure, financial systems, and safety-critical
   applications has created an urgent need for continuous
   verification that deployed agents operate within their declared
   behavioral boundaries. Current agent deployment practices rely
   primarily on pre-deployment testing and static policy
   declarations, creating a significant verification gap between an
   agent's stated capabilities and constraints and its actual runtime
   behavior. This gap becomes particularly problematic as agents
   adapt their behavior through learning mechanisms, interact with
   dynamic environments, or experience gradual behavioral drift due
   to model degradation or adversarial influences.

   Traditional software verification approaches are insufficient for
   autonomous agents because agent behavior is often non-
   deterministic, context-dependent, and may evolve over time through
   machine learning processes. Unlike conventional software systems
   where behavior can be predicted from code analysis, agent systems
   exhibit emergent behaviors that arise from complex interactions
   between training data, environmental inputs, and decision-making
   algorithms. The absence of standardized mechanisms for expressing
   machine-verifiable behavioral specifications further complicates
   runtime verification, as operators lack a common framework for
   defining what constitutes compliant agent behavior and how
   compliance can be automatically validated.

   The security and trust implications of unverified agent behavior
   are substantial, particularly in scenarios where agents operate
   with elevated privileges or make decisions affecting human safety
   or economic systems. Behavioral drift, where an agent's actions
   gradually deviate from intended policies, may go undetected for
   extended periods without continuous verification mechanisms.
   Similarly, adversarial attacks that subtly modify agent behavior
   to achieve malicious objectives could remain unnoticed in systems
   that lack real-time compliance monitoring. The inability to
   provide cryptographic attestations of agent behavior compliance
   also prevents the establishment of trust chains necessary for
   multi-agent systems or cross-organizational agent interactions.

   Current accountability frameworks for AI systems focus primarily
   on explainability and audit trails but do not provide mechanisms
   for real-time verification of behavioral compliance against
   formally specified policies. This creates operational risks where
   agents may violate their declared constraints without immediate
   detection, potentially causing system failures, security breaches,
   or regulatory violations. The lack of standardized verification
   protocols also prevents interoperability between different agent
   verification systems and limits the ability to establish industry-
   wide trust frameworks for autonomous agent deployment.

4.  Agent Behavior Verification Architecture

   The ABVP architecture consists of four primary components that
   work together to provide continuous runtime verification of agent
   behavior: Agent Runtime Environments (AREs), Behavior Verification
   Nodes (BVNs), Attestation Authorities (AAs), and Verification
   Clients (VCs). Agent Runtime Environments host the deployed agents
   and MUST implement behavior monitoring capabilities that capture
   relevant behavioral data and forward it to designated Behavior
   Verification Nodes. These environments MUST provide secure
   isolation between the agent execution context and the monitoring
   subsystem to prevent agents from interfering with their own
   verification processes. The ARE MUST also implement a trusted
   communication channel to BVNs using protocols such as TLS 1.3
   [RFC8446] or QUIC [RFC9000] to ensure behavior data integrity
   during transmission.

   Behavior Verification Nodes serve as the core verification engines
   within the ABVP architecture and MUST implement the runtime
   verification protocol defined in Section 6. Each BVN maintains a
   repository of behavior specifications for agents under its
   verification authority and continuously processes behavioral
   evidence received from AREs. BVNs MUST validate incoming behavior
   data against the appropriate specifications and generate
   compliance assessments in real-time. Multiple BVNs MAY collaborate
   in a distributed verification network to provide redundancy and
   prevent single points of failure. When operating in a distributed
   configuration, BVNs MUST implement consensus mechanisms to ensure
   consistent verification results across the network. BVNs MUST also
   implement rate limiting and resource management to handle high-
   volume verification requests without compromising verification
   quality.

   Attestation Authorities provide cryptographic attestation services
   for verified behavior compliance and MUST maintain secure key
   management infrastructure capable of generating unforgeable
   attestations. AAs receive compliance reports from BVNs and MUST
   verify the authenticity and integrity of these reports before
   issuing attestations. The AA MUST implement a hierarchical trust
   model where attestations can be validated through a chain of trust
   extending to a root certificate authority. AAs SHOULD implement
   hardware security modules (HSMs) or equivalent trusted execution
   environments to protect attestation signing keys from compromise.
   Multiple AAs MAY participate in cross-attestation relationships to
   provide attestation redundancy and prevent single points of trust
   failure.

   Verification Clients represent entities that consume ABVP
   attestations to make trust decisions about agent behavior and MAY
   include system operators, regulatory bodies, or other automated
   systems. VCs MUST implement attestation verification capabilities
   including certificate chain validation and revocation checking as
   specified in Section 7. The architecture MUST support both real-
   time verification queries and batch verification processes to
   accommodate different operational requirements. VCs SHOULD
   implement local attestation caching with appropriate cache
   invalidation mechanisms to reduce verification latency while
   maintaining attestation freshness. The ABVP architecture MUST
   provide clear separation of duties between verification components
   to prevent conflicts of interest and ensure independent
   verification processes.

   The communication between architectural components MUST follow the
   protocol specifications defined in Section 6, with all inter-
   component communications authenticated and encrypted. The
   architecture MUST support both synchronous and asynchronous
   verification modes to accommodate different agent deployment
   scenarios and performance requirements. Components MUST implement
   appropriate logging and audit trail capabilities to support
   forensic analysis and compliance reporting. The overall
   architecture SHOULD be designed for horizontal scalability to
   support large-scale agent deployments while maintaining
   verification performance and reliability.

5.  Behavior Specification Format

   This section defines the standardized format for expressing agent
   behavioral policies and constraints within the ABVP framework. The
   behavior specification format enables machine-readable policy
   declarations that can be automatically verified during agent
   runtime. All behavior specifications MUST be expressed in a
   structured format that supports both human readability and
   automated processing by verification systems.

   The core behavior specification is structured as a JSON document
   conforming to the ABVP Behavior Schema. Each specification MUST
   contain a policy declaration section, verification parameters, and
   compliance thresholds. The policy declaration section includes
   behavioral constraints expressed as logical predicates, allowed
   action sets, and resource utilization bounds. Verification
   parameters specify the monitoring frequency, sampling rates, and
   attestation requirements for each declared behavior. Compliance
   thresholds define the acceptable deviation ranges and tolerance
   levels for measured behaviors compared to declared specifications.

   Behavioral constraints within the specification are expressed
   using a formal constraint language based on temporal logic
   predicates. Each constraint MUST specify a behavioral property
   (such as "response_time_bound" or "resource_utilization_limit"),
   an operator (such as "less_than", "equals", or "within_range"),
   and target values or ranges. Complex behavioral policies MAY be
   constructed using logical operators (AND, OR, NOT) to combine
   multiple constraints. The specification format supports
   hierarchical constraint groupings to represent different
   operational modes or contextual behavior variations.

   The behavior specification includes a verification requirements
   section that defines how each behavioral constraint should be
   monitored and validated. This section MUST specify the required
   verification frequency, acceptable measurement methods, and
   cryptographic attestation parameters for each constraint.
   Verification requirements MAY include sampling strategies for
   performance-sensitive constraints and continuous monitoring
   directives for safety-critical behaviors. The specification format
   also supports conditional verification rules that adjust
   monitoring parameters based on agent operational context or
   detected behavioral patterns.

   Each behavior specification MUST include metadata sections
   containing versioning information, validity periods, and
   specification dependencies. The metadata enables proper
   specification lifecycle management and ensures compatibility
   between agent deployments and verification infrastructure.
   Specifications SHOULD include digital signatures from authorized
   policy authors to ensure specification integrity and authenticity.
   The format supports specification inheritance and composition,
   allowing complex agent policies to be built from validated
   behavioral specification components while maintaining verification
   traceability throughout the composition hierarchy.

6.  Runtime Verification Protocol

   The Runtime Verification Protocol defines the message exchange
   patterns and procedures that enable continuous monitoring and
   validation of agent behavior against declared specifications. The
   protocol operates on a request-response model where Verification
   Requesters initiate compliance checks, Behavior Monitors observe
   agent actions, and Compliance Checkers evaluate adherence to
   behavioral specifications. All protocol participants MUST
   implement the core verification message set defined in this
   section, and MAY implement optional extensions for specialized
   verification scenarios. The protocol is designed to operate over
   existing transport mechanisms including HTTP/2 [RFC7540],
   WebSocket [RFC6455], or dedicated secure channels established
   through TLS 1.3 [RFC8446].

   Verification sessions are initiated through a VERIFICATION_REQUEST
   message that specifies the agent identifier, behavioral
   specification reference, verification scope, and temporal
   parameters for the compliance check. The requesting entity MUST
   include a cryptographically secure session identifier, timestamp
   bounds for the verification window, and references to the specific
   behavioral constraints to be validated. Behavior Monitors respond
   with MONITORING_DATA messages containing timestamped observations
   of agent actions, decision traces, and relevant contextual
   information captured during the specified verification window.
   These messages MUST include integrity protection through digital
   signatures and SHOULD include privacy-preserving mechanisms when
   agent actions contain sensitive information.

   Compliance evaluation proceeds through COMPLIANCE_CHECK messages
   exchanged between Verification Requesters and designated
   Compliance Checkers. Each compliance check message MUST reference
   the behavioral specification being evaluated, include the
   monitoring data to be assessed, and specify the verification
   algorithms or rules to be applied. Compliance Checkers process the
   monitoring data against the behavioral constraints and generate
   COMPLIANCE_RESULT messages indicating whether the observed
   behavior satisfies the specified requirements. Results MUST
   include binary compliance indicators, detailed violation reports
   when non-compliance is detected, and confidence metrics indicating
   the reliability of the compliance assessment.

   The protocol includes mechanisms for handling streaming
   verification scenarios where agent behavior must be validated
   continuously rather than in discrete sessions. Streaming
   verification employs persistent connections where MONITORING_DATA
   messages are transmitted in near real-time as agent actions occur,
   enabling immediate detection of behavioral deviations. Compliance
   Checkers maintain running assessments of behavioral compliance and
   generate COMPLIANCE_ALERT messages when violations are detected or
   when behavioral patterns indicate potential drift from specified
   policies. All streaming verification sessions MUST implement flow
   control mechanisms to prevent resource exhaustion and SHOULD
   include adaptive sampling techniques to manage verification
   overhead in high-throughput scenarios.

   Attestation generation occurs through ATTESTATION_REQUEST messages
   that trigger the creation of cryptographic proofs of compliance
   assessment results. These requests MUST specify the compliance
   results to be attested, the cryptographic algorithms to be used
   for attestation generation, and any additional claims or
   assertions to be included in the attestation. The resulting
   ATTESTATION_RESPONSE messages contain digitally signed
   attestations that bind compliance results to specific agents, time
   periods, and behavioral specifications through tamper-evident
   cryptographic structures. Attestations MUST include sufficient
   information to enable independent verification of compliance
   claims and SHOULD reference the complete verification audit trail
   to support forensic analysis when behavioral violations occur.

7.  Compliance Reporting and Attestation

   Compliance reporting in ABVP provides a standardized mechanism for
   documenting and cryptographically attesting to agent behavior
   verification results. A compliance report MUST contain the agent
   identifier, verification period, evaluated behavior
   specifications, compliance status for each specification, and
   supporting evidence including behavioral observations and
   verification computations. Reports MUST be generated at
   configurable intervals or upon detection of compliance violations,
   with emergency reports triggered immediately when critical policy
   violations occur. The reporting format MUST support both human-
   readable summaries and machine-processable structured data to
   enable automated compliance monitoring and audit trail generation.

   Cryptographic attestation ensures the integrity and non-
   repudiation of compliance reports through digital signatures and
   hash chain mechanisms. Each compliance report MUST be digitally
   signed by the generating Compliance Checker using keys certified
   within the ABVP trust framework. Attestations MUST include a
   timestamp from a trusted time source, the hash of the previous
   attestation to form a verification chain, and sufficient
   cryptographic binding to prevent tampering or replay attacks. The
   attestation format SHOULD follow established standards such as RFC
   8392 (CWT) or RFC 7519 (JWT) to ensure interoperability with
   existing security infrastructures.

   Trust chain establishment requires a hierarchical certification
   authority structure where Compliance Checkers obtain certificates
   from trusted ABVP Certificate Authorities. Root certificates for
   ABVP trust anchors MUST be distributed through secure channels and
   updated using standard certificate management practices as defined
   in RFC 5280. Verification entities MUST validate the complete
   certificate chain from the signing Compliance Checker to a trusted
   root before accepting attestations. Certificate revocation MUST be
   supported through standard mechanisms such as Certificate
   Revocation Lists (CRLs) or Online Certificate Status Protocol
   (OCSP) as specified in RFC 5280 and RFC 6960 respectively.

   The compliance reporting protocol defines specific message formats
   for distributing attestations to interested parties including
   agent operators, regulatory authorities, and other verification
   systems. Compliance reports MAY be distributed through push
   mechanisms to subscribed entities or pulled on-demand through
   standardized query interfaces. Report distribution MUST preserve
   attestation integrity while allowing for appropriate access
   control based on the sensitivity of the reported agent behaviors.
   Long-term storage and archival of compliance reports SHOULD
   implement tamper-evident logging mechanisms to support forensic
   analysis and regulatory compliance requirements.

8.  Security Considerations

   The ABVP verification infrastructure introduces several security
   considerations that must be addressed to ensure the integrity and
   trustworthiness of agent behavior verification. The protocol's
   reliance on continuous monitoring and attestation creates
   potential attack vectors that could compromise the verification
   process itself. Attackers may attempt to subvert verification
   mechanisms to mask non-compliant agent behavior or to falsely
   indicate compliance violations where none exist. The verification
   system MUST be designed with the assumption that both the
   monitored agents and the verification infrastructure may be
   targets of sophisticated adversaries seeking to undermine
   behavioral compliance validation.

   Attestation integrity represents a critical security requirement
   for ABVP implementations. Verification attestations MUST be
   cryptographically signed using mechanisms that provide non-
   repudiation and tamper detection capabilities. The attestation
   chain MUST be anchored in a trusted root of trust, such as
   hardware security modules or trusted platform modules, to prevent
   forgery of compliance attestations. Implementations SHOULD employ
   time-stamping mechanisms to prevent replay attacks where old
   attestations are reused to mask current non-compliance. The
   cryptographic algorithms used for attestation signing MUST conform
   to current best practices for digital signatures and SHOULD
   support algorithm agility to enable updates as cryptographic
   standards evolve. Key management for attestation signing MUST
   follow established security practices, including regular key
   rotation and secure key storage.

   The distributed nature of ABVP verification creates additional
   security challenges related to verification node compromise and
   Byzantine behavior among verification participants. Verification
   nodes may be compromised by attackers seeking to manipulate
   compliance reporting or inject false verification results.
   Implementations MUST employ consensus mechanisms or threshold-
   based verification approaches to detect and mitigate the impact of
   compromised verification nodes. The protocol SHOULD include
   mechanisms for verification node authentication and authorization
   to prevent unauthorized participants from joining verification
   networks. Network communications between verification components
   MUST be encrypted and authenticated to prevent eavesdropping and
   man-in-the-middle attacks. Implementations SHOULD implement rate
   limiting and anomaly detection to identify potential denial-of-
   service attacks against verification infrastructure.

   Behavioral specification tampering and specification substitution
   attacks pose significant threats to the ABVP framework's
   effectiveness. Attackers may attempt to modify behavioral
   specifications to make non-compliant behavior appear compliant or
   to introduce specifications that are impossible to verify
   accurately. Behavioral specifications MUST be cryptographically
   protected through digital signatures and integrity checking
   mechanisms. The protocol MUST include versioning and change
   tracking for behavioral specifications to detect unauthorized
   modifications. Verification systems SHOULD implement specification
   validation to detect specifications that contain logical
   inconsistencies or verification bypasses. Access controls for
   specification modification MUST follow principle of least
   privilege and include audit logging of all specification changes.

   The ABVP verification process may inadvertently expose sensitive
   information about agent operations, internal state, or the systems
   being monitored. Verification data collection MUST be designed to
   minimize information disclosure while maintaining verification
   effectiveness. Implementations SHOULD employ privacy-preserving
   techniques such as zero-knowledge proofs or selective disclosure
   mechanisms where appropriate to limit exposure of sensitive
   operational details. Verification logs and attestations MUST be
   protected against unauthorized access and SHOULD include data
   retention policies that balance verification auditability with
   privacy requirements. The protocol MUST consider the implications
   of cross-border data flows when verification infrastructure spans
   multiple jurisdictions with different privacy regulations.

   Side-channel attacks and covert channels represent additional
   security considerations for ABVP implementations. The verification
   process itself may create observable patterns that could be
   exploited by attackers to infer information about agent behavior
   or verification outcomes. Timing-based side channels in
   verification operations MAY reveal information about the
   complexity or results of compliance checking. Implementations
   SHOULD consider countermeasures such as constant-time operations
   and traffic analysis resistance where appropriate. The protocol
   design MUST consider how verification metadata and communication
   patterns might be used to build profiles of agent behavior that
   could compromise operational security or reveal sensitive system
   characteristics.

9.  IANA Considerations

   This document requires the registration of several new namespaces
   and protocol parameters with the Internet Assigned Numbers
   Authority (IANA). These registrations are necessary to ensure
   global uniqueness and interoperability of ABVP implementations
   across different vendors and deployment environments.

   IANA SHALL establish a new registry titled "Agent Behavior
   Verification Protocol (ABVP) Parameters" under the "Structured
   Syntax Suffixes" registry group. This registry SHALL contain three
   sub-registries: "Behavior Specification Schema Types",
   "Verification Message Types", and "Attestation Format
   Identifiers". The registration policy for all ABVP parameter sub-
   registries SHALL follow the "Specification Required" policy as
   defined in RFC 8126, with the additional requirement that all
   registrations include a reference to a publicly available
   specification document and demonstrate interoperability with at
   least one existing ABVP implementation.

   The "Behavior Specification Schema Types" sub-registry SHALL
   maintain identifiers for standardized behavior specification
   formats as defined in Section 5. Each registration MUST include a
   unique identifier string, a human-readable description, a
   reference specification, and version information. Initial
   registrations SHALL include "abvp-policy-v1" for the base policy
   specification format and "abvp-constraints-v1" for behavioral
   constraint specifications. The "Verification Message Types" sub-
   registry SHALL contain identifiers for protocol messages defined
   in Section 6, including verification requests, compliance reports,
   and attestation messages. Registration entries MUST specify the
   message identifier, purpose, required parameters, and applicable
   verification contexts.

   The "Attestation Format Identifiers" sub-registry SHALL maintain
   identifiers for cryptographic attestation formats used in
   compliance reporting as specified in Section 7. Each registration
   MUST include the attestation format identifier, cryptographic
   algorithm requirements, trust model specifications, and
   interoperability considerations. IANA SHALL reserve the identifier
   prefix "abvp-" for protocol-specific attestation formats and MAY
   delegate sub-namespace management to recognized standards bodies
   for domain-specific attestation requirements. All registry entries
   MUST include contact information for the registrant and SHALL be
   subject to periodic review to ensure continued relevance and
   security adequacy.

Author's Address

   Generated by IETF Draft Analyzer
   2026-03-01
