RATS Architecture
RATS Architecture is the IETF model for remote attestation: an attester produces evidence, a verifier appraises it, and a relying party decides whether a measured peer should receive trust, access, or secrets.
Definition
RATS Architecture is the IETF architecture for Remote ATtestation procedureS, standardized as RFC 9334 and published as an Informational RFC in January 2023. It describes how evidence about a remote peer's operating state is generated, conveyed, appraised, and converted into a decision by another party. The RFC is deliberately neutral about processor architecture, claim content, and wire protocol.
In plain terms, RATS asks a smaller question than "is this system safe?" It asks what evidence an attester can produce, who can appraise it, and what a relying party may decide from the resulting attestation. That makes it useful for devices, software components, trusted execution environments, containers, services, and agent runtimes, but not a blanket certificate of good behavior.
How It Works
RFC 9334 assigns distinct roles. The attester produces evidence. The verifier consumes evidence, reference values, endorsements, and an appraisal policy for evidence, then produces attestation results. The relying party consumes attestation results and its own appraisal policy for attestation results. Endorsers vouch for attester capabilities, reference value providers supply expected values, and owners configure the policies used by verifiers and relying parties.
The same entity can play more than one role, but the separation is important. Evidence may be device-specific, vendor-specific, and privacy-sensitive. Attestation results can be shaped into a relying-party-friendly statement, such as a boolean compliance result, a richer claim set, or a signed result from a trusted verifier.
RFC 9334 names two common interaction models. In the Passport Model, an attester obtains an attestation result from a verifier and later presents it to a relying party. In the Background-Check Model, the attester sends evidence to the relying party, which forwards it to a verifier. Both models need freshness controls such as timestamps, nonces, or epoch identifiers, plus trust in the verifier, trust anchors, and policies.
Agent Context
Agent systems need more than names and API keys. A website, enterprise data service, browser automation layer, model gateway, or tool server may need evidence that a request came from an approved runtime: a managed container, confidential VM, signed connector, sandbox, or trusted execution environment.
RATS is strongest when authority is conditional. A key broker might release a retrieval key only to a measured runtime. A tool gateway might accept a connector only if a verifier reports the expected software stack and debug posture. A confidential-computing service might require a fresh result before sending prompts, data, model weights, or credentials.
This is not a proof that an AI model is aligned, accurate, authorized by a user, or safe to act. It is evidence about a component and an appraisal process. Agent governance still needs user authority, scoped permissions, audit trails, data minimization, output controls, incident response, and ordinary security review.
Governance Risks
Remote attestation can create false confidence when teams compress many judgments into the word "attested." The meaningful question is policy-specific: what evidence was received, which verifier appraised it, which reference values and endorsements were used, how fresh it was, and what relying-party decision followed. An attested runtime can still be over-permissioned or connected to a harmful workflow.
Privacy is also a design constraint. Evidence and attestation results may reveal measurements, configuration state, identifiers, hardware properties, or operational details. RFC 9334 warns that both can contain sensitive information. A verifier and relying party should retain only what is needed for audit, revocation, and policy review.
There is a supply-chain risk beneath the ceremony. If endorsements are weak, reference values are stale, policy owners are careless, or a verifier is compromised, the result can launder weak assumptions into an access decision. RATS structures the appraisal; it does not guarantee that the policy is wise.
Governance Pattern
- Name the decision. State whether remote attestation is used for key release, workload admission, registration, token issuance, tool access, or inventory.
- Name the roles. Identify the attester, verifier, relying party, endorsers, reference value providers, and policy owners.
- Pin the policy. Record the appraisal policy, accepted reference values, expected endorsements, verifier trust anchors, and result format.
- Check freshness. Require timestamps, nonces, epoch identifiers, or equivalent controls so old evidence cannot authorize a new action.
- Minimize disclosure. Keep raw evidence away from parties that only need attestation results, and avoid storing stable identifiers unless necessary.
- Separate attestation from authority. A measured runtime still needs scoped permissions, user authority, rate limits, and action logs.
Source Discipline
Use RFC 9334 for RATS role vocabulary, conceptual messages, interaction models, freshness discussion, privacy cautions, and trust assumptions. Use RFC 9711 when the evidence or result is carried as an Entity Attestation Token. Use RFC 9782 when an EAT payload is conveyed with registered media types such as REST-facing HTTP APIs.
Product documentation can verify a vendor-specific attestation format, but it should not redefine the architecture. A careful claim names the evidence type, verifier, policy, trust anchors, freshness mechanism, and relying-party decision. Avoid saying "the agent is trusted" when the sourced fact is only "this verifier produced this result about this measured component."
Spiralist Reading
Spiralism reads RATS as a ritual of conditional access.
The machine asks to act, connect, or receive a secret. The institution answers with a narrower question: under what measured state, witnessed by whom, judged against which policy, and for which limited decision? That question is less dramatic than trust. It is also more useful.
Open Questions
- Which agent actions should require remote attestation before secrets or sensitive tools are released?
- How should relying parties explain attestation failure without exposing sensitive measurements or policy details?
- When should raw evidence be hidden behind verifier-issued attestation results for privacy and parser-minimization reasons?
- Can compound agent workflows preserve useful evidence across browsers, tool gateways, enclaves, and model calls?
Related Pages
- Entity Attestation Token (EAT)
- OAuth Attestation-Based Client Authentication
- Confidential Computing for AI
- AI Agent Identity
- AI Agent Sandboxing
- SPIFFE Workload Identity
- Workload Identity in Multi System Environments (WIMSE)
- Sender-Constrained Tokens
- Confused Deputy Problem
- AI Audit Trails
Sources
- H. Birkholz, D. Thaler, M. Richardson, N. Smith, and W. Pan, IETF, RFC 9334: Remote ATtestation procedureS (RATS) Architecture, Informational, January 2023.
- IETF Datatracker, Remote ATtestation ProcedureS (rats) working group, charter and status page, reviewed June 25, 2026.
- L. Lundblade, G. Mandyam, J. O'Donoghue, and C. Wallace, IETF, RFC 9711: The Entity Attestation Token (EAT), Proposed Standard, April 2025.
- L. Lundblade, H. Birkholz, and T. Fossati, IETF, RFC 9782: Entity Attestation Token (EAT) Media Types, Proposed Standard, May 2025.