| Internet-Draft | Dynamic Attestation for SEAT | November 2025 |
| Jiang & Wang | Expires 17 May 2026 | [Page] |
This document describes a use case for conveying remote attestation information in association with Transport Layer Security (TLS) sessions in the context of AI agent communication. It focuses on long-lived secure channel sessions where an AI agent runtime posture, covering the platform Trusted Computing Base (TCB), agent manifest (models, tools and policies) and committed runtime context, can change frequently and unpredictably. The document highlights requirements for dynamic attestation so that relying parties can base authorization decisions on the current runtime posture of the communicating agent.¶
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 17 May 2026.¶
Copyright (c) 2025 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.¶
Many deployed systems involve relatively static workloads, where software and configuration change primarily at onboarding or planned maintenance events. In contrast, AI agents may alter effective behavior by updating their models, tools, and policies on timescales that are not necessarily aligned with TLS session establishment or traditional maintenance cycles. Such updates may occur while long-lived TLS sessions remain open, or between sessions that are resumed or quickly re-established, raising security and privacy concerns about authorizing sensitive actions based on stale assumptions.¶
Remote attestation (RA), as described in the Remote Attestation Procedures (RATS) architecture [RFC9334], allows a relying party to obtain information about the software and hardware state of a remote endpoint and to assess whether that state satisfies local policy. When combined with a secure channel protocol such as TLS 1.3 [RFC8446], attestation information can be bound to a specific, authenticated session so that authorization decisions reflect the peer's current runtime posture (e.g., platform TCB plus an agent manifest covering model, tools and policy), rather than only the state at connection establishment.¶
This document describes a use case for dynamic attestation in AI agent communication scenarios and outlines requirements for obtaining fresh, channel-bound attestation information without unnecessarily disrupting existing connections, allowing relying parties to base authorization on agent state at the time of use.¶
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 RFC 8174 [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document uses the terminology defined in the RATS architecture [RFC9334] and in TLS 1.3 [RFC8446], including "Attestation", "Relying Party", "Evidence" and "Attestation Results".¶
Trusted Computing Base (TCB) of a device, is used to refer to security-relevant components: hardware, firmware, software, and their respective configurations.¶
Runtime posture denotes the set of attestation-relevant claims about the communicating endpoint at the time of use, sufficient for a relying party to appraise policy. Its exact composition is deployment- specific and may include claims about the platform, execution environment, configuration, or context.¶
Goal: Support remote attestation for AI agent communication over secure channel sessions where the software and configuration on at least one endpoint can change on timescales that are not aligned with connection establishment or traditional maintenance cycles (for example, while long-lived sessions remain open or between sessions that are resumed), while the endpoint continues to exchange traffic with multiple network peers.¶
Use case: AI Agent Runtime Attestation. An AI agent service communicates with other network nodes over TLS 1.3, invoking tools that can access sensitive data or change network state. The agent's model, tools, and policies may be updated dynamically according to operator policy, and these updates are not guaranteed to align with TLS session boundaries or a fixed maintenance schedule. Peers therefore need assurance that, at the time of a high-impact operation, the agent runs on an acceptable platform and uses an approved combination of model, code, and policy.¶
Requirement 1 (fresh, channel-bound attestation): Before executing a high-impact operation over an existing secure channel, a peer MUST be able to obtain fresh attestation evidences that are cryptographically bound to that session and that reflect both the platform and the current agent-level state relevant to authorization, as determined by local policy.¶
Requirement 2 (dynamic attestation): The mechanism used to obtain such attestation evidences SHOULD support lightweight, dynamic attestation without necessarily requiring a full new TLS handshake, so that changes to the runtime posture become visible to relying parties when required by local policy.¶
Any mechanism that supports dynamic attestation for AI agent communication should ensure that attestation evidences are strongly bound to the TLS session for which they are intended, so that they cannot be replayed or relayed to another session or endpoint.¶
Because the agent software stack can change rapidly, attestation evidences should be sufficiently fresh for the relying party's policy. Implementations should provide a way to limit the validity period of evidences for a given session and to trigger attestation when that period expires or when relevant changes are detected.¶
This document has no IANA actions.¶