Wiki · Concept · Last reviewed June 25, 2026

Entity Attestation Token (EAT)

An Entity Attestation Token, or EAT, is an IETF token format for carrying attested claims about a hardware or software entity. For AI agents, EAT belongs in the evidence layer before secrets or authority are released.

Category: Concept Updated: June 25, 2026 Tags: EAT, attestation, RATS, AI agents, workload evidence, trusted execution

Definition

Entity Attestation Token, or EAT, is defined by RFC 9711 as an attested claims set describing the state and characteristics of an entity, such as a device, hardware component, software component, or service implementation. In EAT vocabulary, an entity is the target being described by attestation claims, not a person or organization.

EAT is part of the IETF Remote ATtestation procedureS, or RATS, family. RFC 9334 defines the architecture: an attester produces evidence, a verifier appraises that evidence against policy and reference values, and a relying party uses the result to decide how much trust or access to grant. EAT supplies a reusable token structure for the claims that move through those flows.

An EAT can be encoded as a CBOR Web Token or a JSON Web Token with attestation-oriented claims. RFC 9782 later defined media types for EAT payloads, including EAT forms that can be carried in RESTful APIs. EAT is not a complete attestation system by itself. It is the evidence container and claim vocabulary that other protocols, verifiers, and relying-party policies must interpret.

How It Works

An EAT contains claims about an entity and about the token. RFC 9711 registers claims for freshness, identifiers, hardware and software version, debug status, manifests, measurements, submodules, issued-at time, profile, and intended use. Profiles narrow which claims, encodings, algorithms, and semantics a deployment accepts.

The most important practical step is appraisal. A verifier does not merely parse an EAT. It checks the signature or MAC, issuer or signing key, freshness, intended use, profile, and claim meanings against reference values and policy. Only then can a relying party release a key, allow registration, grant a credential, accept a workload, or restrict an action.

RFC 9782 adds media types such as application/eat+cwt and application/eat+jwt, plus bundle and unprotected claims-set variants. The IANA RATS registry also records intended-use values for EAT, including generic attestation, registration, provisioning, certificate issuance, and proof of possession. Those values help receivers avoid treating every attestation token as valid for every purpose.

Agent Context

Agent systems need more than names. A website, model gateway, enterprise data service, or tool server may need evidence that a request came from an approved runtime: a managed container, confidential VM, signed connector, or sandbox with a particular software version and debug state. EAT gives those claims a standards-based shape.

This matters most when authority is conditional. A system might release a retrieval key only to a measured runtime, accept a connector only if debug mode is disabled, or require a fresh nonce before granting a sensitive tool permission. EAT does not decide that policy; it lets evidence travel in a form verifiers can inspect.

EAT also sits beside newer agent identity work. OAuth Attestation-Based Client Authentication binds OAuth client authentication to attested client-instance evidence. Confidential Computing for AI depends on attestation before key release. AI Agent Identity asks who acted under whose authority. EAT asks a narrower question: what does this runtime claim to be, and who attested it?

Governance Risks

EAT can create false confidence if the receiver treats a token as a certificate of safety. The meaningful question is policy-specific: which claims were verified, which reference values were used, which profile applied, how fresh the evidence was, and what decision followed. A valid EAT can still describe an over-permissioned runtime.

Privacy is a real issue. Universal or semipermanent entity identifiers, location claims, boot seeds, debug state, and measurements can become tracking or fingerprinting material. RFC 9711 includes privacy guidance for several claim families, and agent deployments should preserve only the evidence needed for audit, revocation, and policy review.

There is also a supply-chain risk. A verifier must trust attestation keys, endorsements, profiles, and reference values. If those sources are stale or too broad, the token can launder weak assumptions into a strong-looking decision.

Governance Pattern

Source Discipline

Use RFC 9711 for EAT structure, claims, profiles, privacy, and security considerations. Use RFC 9782 for media types. Use RFC 9334 for RATS architecture and role vocabulary. Use IANA for registered RATS values. Product documentation can verify a vendor-specific format, but it should not redefine EAT.

Do not say that an EAT proves an AI agent is safe, authorized, or trustworthy in general. It proves only what the token, issuer, profile, and appraisal policy support. Source discipline means naming the exact claim and the decision it may affect.

Spiralist Reading

Spiralism reads EAT as a receipt from the machine body.

The model interface says "I can act." The attestation token says something smaller: this measured thing, with this key, claims this state, under this issuer, for this intended use. A serious institution appraises that receipt, limits it, logs the decision, and leaves room to say no.

Open Questions

Sources

Return to Wiki