[Rats] Re: [Use Case] RATS for Hardware-Enforced State Management in Autonomous Agents (AIGA)

[Edward Aylward <[e-mail]>]

Hello Usama!

Thank you for the quick review and the feedback.

To answer your questions:

1. General Comments & Definitions

   -

   Table 1 Source: The columns represent the specific stages of the RATS
   governance lifecycle. "Check-in" refers to the periodic evidence submission
   (Prover → Verifier), and "Approval" refers to the issuance of the Liveness
   Token (Verifier → Prover)
   -

   "exp AGI": That is short for "Export controlled AGI"
   -

   Section 11 Figure: I Agree! A diagram would be good here to visualize
   the Agent → Verifier → Relying Party communication flow

2. The Proposed Solution (RATS Integration)

Could you explain the need for "periodic"? Why is one-time attestation
insufficient? What exactly can change?

One-time attestation (e.g., only at boot) creates a "time of check, time of
use" vulnerability. We require periodic attestation to mitigate:

   -

   Runtime Compromise: An agent might boot securely but be exploited later
   i.e., a prompt injection, buffer overflow, the AI modifying its own code,
   etc.
   -

   Revocation: If a vulnerability is discovered in the agent’s software
   stack, the governance node needs a mechanism to revoke trust dynamically.
   The periodic heartbeat ensures that a newly compromised agent loses its
   "liveness token", (and thus network access), within the heartbeat window
   (e.g., within a certain amount of time)
   -

   Freshness: It proves the agent is currently online and functioning
   correctly, preventing the replay of old evidence.

Section 12 seems to suggest you use TLS. Do I understand correctly that you
want to design a HTTP protocol on top of TLS for periodic attestation?

Yes, the intention is to use HTTPS, (which is HTTP over TLS, as the current
HTTPS is no longer HTTP over SSL as it was in the 1990’s), for the
transport of the evidence and liveness tokens. We leverage the existing
security of the TLS session for confidentiality, while the RATS structure
(EAT) provides the integrity and authenticity of the machine state.

What is the identity of the Agent? In other words, how does the RP identify
the Agent?

The relying party identifies the agent via a cryptographic binding, not
just an IP address. The liveness token, (attestation result), contains a
subject key identifier, or a specific instance ID claim

   -

   Mechanism: When an agent opens a connection to the RP, it presents the
   Liveness Token. The RP verifies the token's signature (from the Governance
   Node) and ensures the token’s Subject Key matches the key used by the Agent
   in the TLS handshake. This prevents identity spoofing.

What do you mean by "drops all traffic"? What does the RP do after
successful attestation? What does the RP do after failed attestation?

This is a "Fail-Closed" model:

   -

   Success: The RP accepts the Liveness Token and processes the application
   data (e.g., API requests, inference tasks).
   -

   Failure: If the token is missing, expired, or invalid, the RP terminates
   the connection immediately or silently discards packets. It does not
   parse the application payload. This prevents a compromised or non-compliant
   agent from propagating data to the network.

3. Questions for the WG

Could you tell more about the possible values for "operational state"? Is
it just active and terminated? What does the RP do with these states?

For the AIGA use case, we are looking at defining a custom EAT profile to
capture the lifecycle of an AI Agent. The states would likely be:

   1.

   Initializing: Booted, generating evidence, waiting for approval.
   2.

   Active: Fully attested and compliant; traffic allowed.
   3.

   Suspended: Temporarily untrusted (e.g., missed heartbeat, investigation
   pending); traffic blocked or limited to telemetry only.
   4.

   Revoked/Terminated: Permanently untrusted (e.g., confirmed compromise);
   all traffic blocked.

The RP uses these states to apply real-time policy without needing to
understand the underlying hardware complexities.

I will work on the figure for Section 11 and the definition updates
immediately.

Best regards,

Edward Aylward

On Sat, Jan 17, 2026 at 4:08 PM Muhammad Usama Sardar <
[e-mail]> wrote:

> I had a quick look at the draft. I have a few general questions and
> comments:
>
> What is the source of Table 1? It seems there is no proper definition or
> explanation of what the columns actually represent. What is "check-in"?
> "Approval" of what?
>
> Several terms are undefined. What is "exp AGI"?
>
> Could you add a figure in Section 11? It will be easier to follow an
> overall figure first before details.
> On 13.01.26 19:56, Edward Aylward wrote:
>
>
> 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":
>
> Could you explain the need for "periodic"? Why is one-time attestation
> insufficient? What exactly can change?
>
> Section 12 seems to suggest you use TLS. Do I understand correctly that
> you want to design a HTTP protocol on top of TLS for periodic attestation?
>
> 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.
>
> What is the identity of the Agent? In other words, how does the RP
> identify the Agent?
>
> What do you mean by "drops all traffic"? What does the RP do after
> successful attestation? What does the RP do after failed attestation?
>
>
> 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?
>
> Yes
>
> 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?
>
> Could you tell more about the possible values for "operational state"? Is
> it just active and terminated? What does the RP do with these states?
>
> -Usama
>
>