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

[Muhammad Usama Sardar <[e-mail]>]

Hi Edward,

Thanks very much for responses. If you fix the things below, I will 
support this effort. This is interesting and timely problem and I am 
willing to contribute as a co-author.

On 20.01.26 02:19, Edward Aylward wrote:
>
> 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"
>
By source, I meant where all of this is coming from? as in an some 
authentic reference (some paper, etc.), or is it just your opinion?
>
> 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.
>
Very cool stuff, thanks. This is sufficient motivation for me to support 
this work. Please explain this with authentic references in the security 
considerations section.
>
> 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.
>
Are you aware of SEAT WG [0]? This seems to have a lot of overlaps with 
what we are proposing there. For example, you may be interested in 
[1,2]. That /may/ be what you are looking for. You are welcome to submit 
your comments on [1,2] at SEAT.

Speaking as author of [2]: If you have additional requirements, I will 
be happy to consider them in my protocol design.

> 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
>
This needs more explanation in security considerations. Who issues the 
liveness token? Who provisions the key? Who assigns instance ID claim? 
Can identity be replicated? Can identity be faked? etc.
>
>  *
>
>     I will work on the figure for Section 11 and the definition
>     updates immediately
>
cool, that would be a great addition. Thanks.

-Usama

[0] https://datatracker.ietf.org/wg/seat/about/

[1] https://datatracker.ietf.org/doc/draft-usama-seat-intra-vs-post/

[2] https://datatracker.ietf.org/doc/draft-fossati-seat-expat/