[Rats] [Use Case] RATS for Hardware-Enforced State Management in Autonomous Agents (AIGA)
Edward Aylward <aylward.edward@gmail.com> Tue, 13 January 2026 18:57 UTC
Return-Path: <aylward.edward@gmail.com>
X-Original-To: rats@mail2.ietf.org
Delivered-To: rats@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 6B382A72A645 for <rats@mail2.ietf.org>; Tue, 13 Jan 2026 10:57:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFCwJxMswuWp for <rats@mail2.ietf.org>; Tue, 13 Jan 2026 10:57:38 -0800 (PST)
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id E2407A72A63A for <rats@ietf.org>; Tue, 13 Jan 2026 10:57:38 -0800 (PST)
Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-b8710c9cddbso407374066b.2 for <rats@ietf.org>; Tue, 13 Jan 2026 10:57:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768330658; x=1768935458; darn=ietf.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=nUhsdPnm4Z75V9OeNqjKVTmTu+ea/eLRZk9a3nwlPLg=; b=NvEZPX2zyecoOFptZGFJoQOEyTr9BJhSeQvqe8Wvs/S+JvFQ/yibQsObkgOwnNnvx7 ml65WTXxYaG/EhfbO3e2tTGKvWGs5Dbnqin2PMZxCpZqD/aAn0LcRBkibpaBfUFXVd3K z0Ml+b+frOGFUfNfZBAFiLbUrJ5wBbLilqLb/q5LoGmR8kSj6Zf0HGooQZ9agu+5wdVV VPHiaXlFSHO88+oKPPvBjWFc2dfTqTUPHaevz4cSBnk9I7m+0qGjwmCJOmyOfD1xHvoT SlR1qzuNLJhtWZX0q6K3YY+rvkGwaZY/M5PIQvbytjtdy7+Z0UN6dSLen7mFcmsmnsJM v44w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768330658; x=1768935458; h=to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=nUhsdPnm4Z75V9OeNqjKVTmTu+ea/eLRZk9a3nwlPLg=; b=oBhA4rmSO9IMnr7rlmsadbOteuCCFAi9mgHjT50fhLvyDdPXhsrAW3G0Vejj4bPDMX SaUnKVxI3KW4K9IpCmOVTESSR+/UJ7j/OQqMRXJqSXUYUfvCDKc7cuU664RJ0An4wL1I G3ccl+rpqOhqzO9nBNbIoS7ElM4wzoxDT9jS90J3jC/p1MD/ksA03GSxqTrTLohVMM0a elgvgsxxVuolT9pg7B1xcd4wJ63UxS5KvYDl4ZaZ2fDy0UgRQE377lbhueTc+gbRvPa0 O9MmuoSSN+px8+otxB4Cz2xvM1raKObw7JrFKUbGugu1xvqRuHDZFcztHvfxSgtpQ8eb of2w==
X-Gm-Message-State: AOJu0YxA0d25D8kLX2HNXjElMibcYyZhpdP/p+ME8YC5njtFDZIdv7KQ 1lbp2GN07vmdnSdahDztLzJ6Je2aVdd3NimJ/6dI4DT9k9rOhlkMC5VG03CUei1HlaRQY7XM3wM dkdqlSChdQ95/pgK1HFYcbTeBgwskOrg+cpKSC+s=
X-Gm-Gg: AY/fxX5xPcZ37GivJ/m2pokWRvOoXbD4XwtPruuLtPJomkyxN3l/Zelu0IzoAuJ3swP BW65nV+3S/UT9OJCRBSOYTEzWX9j6Bxm3uLi91rVgR6jOYjNQJ9UN9OZ0MWf1TDGFDFyyYvVUCw KwsPQRSByRZq+EXAyUDaF83Y6UjUt1bFrX63k/VazJVweuI0Z5c0a5p3H1ie/T1ZK4Nii7vk/kO CzShP7yr8pc4Xa/CezORyYsirA7sLqENqt1MtlVCDgDUu55oQpTGG7GApoEpgn6SHU8h8TJQ6X+ 6jkR8nyl4YDmqEw0K8YVfxbWVS7H
X-Received: by 2002:a17:907:84d:b0:b73:544d:b963 with SMTP id a640c23a62f3a-b8760fce1admr13610366b.13.1768330657361; Tue, 13 Jan 2026 10:57:37 -0800 (PST)
MIME-Version: 1.0
From: Edward Aylward <aylward.edward@gmail.com>
Date: Tue, 13 Jan 2026 10:56:58 -0800
X-Gm-Features: AZwV_QgjDQxziP6A4aQjr8y7yrTdt24-EP0255asI90xV-hErpRyvWUzjKh3LfE
Message-ID: <CAL6-Gb-O7LEifnA1iT5hHC78_svdDSyoje7G6E6X0yb6yRhTHw@mail.gmail.com>
To: rats@ietf.org
Content-Type: multipart/alternative; boundary="000000000000ad721f0648499090"
Message-ID-Hash: BW4KGSFEZB6EFUYWT3DCMH6VKKXIZPK6
X-Message-ID-Hash: BW4KGSFEZB6EFUYWT3DCMH6VKKXIZPK6
X-MailFrom: aylward.edward@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-rats.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Rats] [Use Case] RATS for Hardware-Enforced State Management in Autonomous Agents (AIGA)
List-Id: Remote ATtestation procedureS <rats.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/qItQjD96EoFKjZA_fk0yiLQBf2A>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Owner: <mailto:rats-owner@ietf.org>
List-Post: <mailto:rats@ietf.org>
List-Subscribe: <mailto:rats-join@ietf.org>
List-Unsubscribe: <mailto:rats-leave@ietf.org>
Hi RATS WG, I am writing to request feedback on a specific use case for Remote Attestation described in my recent individual submission: "Artificial Intelligence Governance Architecture (AIGA)" (draft-aylward-aiga-00). While the draft covers broader application-layer governance, Section 5.1 specifically proposes a mechanism for "Hardware-Enforced Termination" of high-risk autonomous agents using TEEs. I believe this aligns with the RATS architecture, and I am seeking the group's insight on the feasibility of the attestation flow. The Problem: Current "kill switches" for autonomous agents are implemented in software. If an agent (or the host OS) is compromised or misaligned, it can simply ignore the termination signal. The Proposed Solution (RATS Integration): The draft defines a "Risk Class 5" Agent that MUST execute within a TEE. The enforcement mechanism relies on a periodic "Attestation Heartbeat": 1. The Prover (Agent Hardware): Generates a periodic Quote (EAT) certifying the hash of the running kernel/binary and the freshness of the session. 2. The Verifier (Governance Node): Validates the Quote against the Platform Endorsement Key (PEK). 3. The Relying Party (Network Peer): Drops all traffic if the Verifier does not publish a fresh "Liveness Token" for that Agent. My Questions for the WG: 1. Does the RATS architecture support a model where the "Relying Party" (the network peer) is distinct from the "Verifier" (the Governance Node) in a real-time loop? 2. Are there existing EAT claims (CWT/JWT) best suited for representing "Operational State" (e.g., Active vs. Terminated), or would this require a custom profile? I would appreciate any guidance on whether this use case fits within the current RATS charter or if there are existing profiles I should reference to align Section 5.1 with standard practices. Link to Draft: https://datatracker.ietf.org/doc/draft-aylward-aiga/ Best regards, Edward Richard Aylward Jr.
- [Rats] [Use Case] RATS for Hardware-Enforced Stat… Edward Aylward
- [Rats] Re: [Use Case] RATS for Hardware-Enforced … Edward Aylward
- [Rats] Re: [Use Case] RATS for Hardware-Enforced … Michael Richardson
- [Rats] Re: [Use Case] RATS for Hardware-Enforced … Edward Aylward
- [Rats] Re: [Use Case] RATS for Hardware-Enforced … Muhammad Usama Sardar
- [Rats] Re: [Use Case] RATS for Hardware-Enforced … Edward Aylward
- [Rats] Re: [Use Case] RATS for Hardware-Enforced … Muhammad Usama Sardar