Speaker notes · 20 July 2026
Agent-action evidence and remote attestation
Notes accompanying Tyche's contribution to the IETF 126 public side meeting Remote Attestation Challenges for AI Agents, Grand Klimt Hall 3, Vienna, with remote participation.
Outcome in one sentence
AI is a motivating use case, not a protocol predicate: RATS should remain workload-neutral and appraise relevant properties of an untrusted endpoint, while delegated authority and the action record remain separate layers joined through an explicit composition interface.
This records a side-meeting discussion outcome. It is not IETF consensus, a working-group decision, or adoption of an Internet-Draft.
What changed during the discussion
The initial framing asked why a service should care that a requester uses an AI model. The useful answer is that it generally should not. A relying party needs remote attestation only when it legitimately conditions service on a property of an endpoint it does not trust—for example, whether the expected policy engine and policy version were running in a fresh, approved state.
In the Chicago/New York example used in the room, the same action may be governed by different jurisdiction-specific requirements. The mandate states which action and scope were authorised; RATS can provide fresh evidence about the executing endpoint; the action record states what happened. If the service does not require endpoint-state assurance, RATS adds no value.
The EU AI Act can motivate traceability, logging, human-oversight, robustness, and evidence requirements. It does not mandate remote attestation, and an attestation result alone is not evidence of legal compliance.
Freshness and composition map
This speaker-reference figure separates human authorisation, application evidence, platform evidence, Veraison appraisal, and the relying-party decision. It also shows the exact fresh/replay nonce comparison and the unresolved multi-window problem.
How to read the figure
- Mandate / wallet
- Establishes the authorised principal, exact action, scope, recipient, and limit. It does not prove platform state.
- Action Evidence Package (AEP)
- Records what the agent did, under which authority, and with what outcome. Its signature proves who signed the record, not which runtime executed.
- TPM quote
- Carries measured platform state, a PCR digest, and a verifier challenge. The PCR digest detects changed measured state; the quote signature detects altered quote bytes; the nonce detects replay.
- Veraison and EAR
- The Verifier appraises Evidence and produces an EAT Attestation Result. In the captured test, the same 235 quote bytes were accepted in their original session and rejected when replayed into a session with a new nonce.
- Load-bearing binding
- A cryptographic relationship must show that the mandate, action record, and platform Evidence refer to the same action. Merely placing several valid objects in one envelope is insufficient.
Progress leading to IETF 126
-
17 July · AICYBERSEC2026, Lesvos
Informal small-group live demonstration of the accountable-agent evidence console. Questions about mandate authoring and an in-scope but economically absurd purchase exposed the boundary between cryptographic validity and substantive policy. This was not a scheduled programme talk.
-
18–19 July · IETF 126 Hackathon, Vienna
Formal results readout for The payment agent that cannot overspend. Telefónica's independent COSE-provenance implementation accepted the evidence object, matched canonicalisation byte-for-byte, and rejected the tampered verdict. Independent execution also exposed different quote bytes travelling under the same filenames.
-
20 July · Remote-attestation side meeting
The technical work became a clearer standards boundary: RATS appraises endpoint properties; mandate/delegation establishes authority; the action record supports audit. The protocols should compose without introducing an “AI trust bit”.
Evidence boundaries
- The prototype uses
swtpm, not a manufacturer-backed hardware root. - The EARs shown in the replay viewer were captured from real laboratory Veraison appraisals; the stage viewer is not a live Veraison service.
- A fresh component does not refresh a stale wallet approval, AEP record, or platform result.
- The work does not prove model correctness, safety, fairness, legal compliance, or meaningful human oversight.
- The AEP composition Internet-Draft is an individual submission, not a RATS working-group document.
References
- IETF 126 public side-meeting schedule — event title, time, room, organisers, and SEC tag.
- IETF 126 Hackathon and the project workspace.
- AICYBERSEC2026 summer school, University of the Aegean.
- draft-sokolov-rats-aep-composition — individual Internet-Draft.