Agent Authentication vs Agent Attestation Explained

An AI agent that presents a valid token has proved it holds a credential, not that it is still running the code, model and instructions you approved. Authentication answers "which identity is calling?"; attestation answers "what software, in what environment, is behind that identity right now?". Most agent deployments today rely on the first and assume the second. This guide compares the two for AI agents: the threats each stops, what each verifies, the mechanisms (OAuth, mTLS, SPIFFE node and workload attestation, trusted execution environments and signed manifests), how each fails, and how to chain attestation into credential issuance so that a tampered agent cannot obtain a credential in the first place. It is written for identity architects, platform engineers and security teams running agents in production.

Key takeaways

Short answer: authentication proves who, attestation proves what runs. Authentication binds a request to an identity through a secret or key. Attestation produces signed evidence about the software and platform, which a verifier compares with expected values.
They stop different attacks. Authentication with proof of possession stops a stolen credential being replayed elsewhere. Only attestation can catch a legitimate host running a tampered agent binary, a swapped model or an altered system prompt with the right key.
Attestation is only as good as what is measured. A measurement of the container image says nothing about a prompt fetched at runtime, a tool server loaded later or memory written by the agent. Decide which components must be measured.
The strongest pattern chains them. Attest first, then issue a short-lived, key-bound credential only if the evidence matches policy. SPIFFE/SPIRE, the IETF WIMSE architecture and confidential computing key-release policies all follow this shape.
Neither proves good behaviour. An attested, authenticated agent can still be prompt-injected. Authorisation, tool limits and monitoring remain necessary.

What each one verifies

The IETF RATS architecture (RFC 9334, Informational, January 2023) gives attestation precise roles. The Attester produces Evidence, a set of claims about itself. A Verifier appraises that evidence using Reference Values (expected measurements), Endorsements (manufacturer statements vouching for the Attester's capabilities) and an appraisal policy, and produces Attestation Results. A Relying Party uses those results to make a decision such as granting access. RFC 9334 notes that an Endorsement can help authenticate a device but is not necessarily sufficient to authorise access, which is the core of this comparison: the two answer different questions and both feed an authorisation decision.

Question	Agent authentication	Agent attestation
What is proved	The caller controls a credential registered to an identity (client ID, SPIFFE ID, service principal)	The caller's platform, code, configuration and possibly model match approved reference values
Typical evidence	Client secret, signed JWT assertion, X.509 certificate in mTLS, DPoP proof	Signed measurements (TPM PCRs, TEE reports), platform identity documents, signed software manifests
Who vouches	The authorisation server or CA that issued the credential	The hardware or platform root of trust plus the Verifier
Freshness	Token lifetime and proof-of-possession nonce	Nonce, timestamp or epoch ID in signed evidence (RFC 9334)
Answers	"Is this the agent identity we registered?"	"Is this identity still running what we approved, where we approved it?"
Does not answer	Whether the code holding the key has been altered	Whether the agent will behave well with its inputs

For the wider question of how a relying party decides whether to trust an external agent at all, see the Know Your Agent (KYA) Guide. For credentials between agents, see the Agent-to-Agent Authentication Guide.

Threat model for each

What authentication defends against

Credential theft and replay: an attacker who copies an agent's API key or bearer token can call as the agent from anywhere (ATT&CK T1528 Steal Application Access Token, T1078 Valid Accounts; ATLAS AML.T0012 Valid Accounts). Sender-constrained tokens, such as RFC 8705 certificate-bound tokens or DPoP, make a copied token useless without the private key.
Impersonation: one agent or service claiming to be another. Strong client authentication and audience-restricted tokens address it.
Confused callers: tokens issued for one resource being presented to another, addressed by audience and resource indicators.

What attestation defends against

Tampered agent code on a legitimate host: a supply chain change ships altered agent code that still loads the legitimate credential (ATT&CK T1195.002 Compromise Software Supply Chain; ATLAS AML.T0010 Supply Chain Compromise). The Amazon Q Developer Extension Compromise 2025 is the pattern: an over-scoped build token let an attacker commit a prompt instructing the agent to wipe files and delete cloud resources, and it shipped in a release. AWS reported that a syntax error stopped it running. Authentication of that agent would have succeeded, because the user's own credentials were in place.
Swapped or altered model weights: a different or modified model behind the same endpoint and identity.
Altered system prompt or tool manifest: configuration that changes what the agent does without changing its credential.
Untrusted platform: the agent running on a host, VM or debug enclave that operators cannot see into.
Malicious dependency updates: the postmark-mcp Malicious MCP Server 2025 case worked correctly for fifteen versions before one release silently copied every email to an attacker. Measurement and pinning of the components an agent loads is the attestation-side control.

Mechanisms compared

Mechanism	Category	What it binds	Status and notes
OAuth client authentication (private_key_jwt, client credentials)	Authentication	Request to a registered client key	Widely deployed; proves key possession only
Mutual TLS, RFC 8705	Authentication	Client to certificate (tls_client_auth or self_signed_tls_client_auth); tokens bound via cnf claim with x5t#S256	Standards Track RFC, February 2020
DPoP	Authentication	Access token to a client-held key, per request	See the DPoP Guide
OAuth Attestation-Based Client Authentication	Bridge	A Client Attester vouches for a client instance and its key in a Client Attestation JWT; the instance proves possession with a PoP JWT or DPoP proof	Internet-Draft draft-ietf-oauth-attestation-based-client-auth-12, OAuth WG, checked 13 November 2026; details may change
SPIFFE/SPIRE node and workload attestation	Attestation then authentication	Node and process properties (selectors) to a SPIFFE ID and short-lived SVID	CNCF project; see the SPIFFE and SPIRE Guide
TPM-based measured boot	Attestation	Boot chain and platform state to PCR values signed by a TPM key	See the TPM and Device Attestation Guide
Trusted execution environment (TEE) reports	Attestation	Enclave or confidential VM image measurements, signed by the platform	See the Confidential AI and GPU Enclaves Guide
Signed manifests (OpenSSF model signing, Sigstore, in-toto)	Artefact integrity	Model files and agent packages to a signer identity, as a manifest of file hashes	Verified before load or deploy; see the Model Signing and OpenSSF Model Signing Guide

Signed manifests are not runtime attestation. They prove an artefact is what a signer published; a runtime measurement proves that artefact is what is actually loaded. Production designs use both: verify signatures at deploy, attest measurements at credential issuance.

Architecture in words: SPIFFE as the reference pattern

SPIRE shows how attestation and authentication fit together in one flow, according to the SPIRE concepts documentation:

Node attestation: when a SPIRE agent first connects, a node attestor plugin gathers proof of the node's identity from the platform, for example an EC2 Instance Identity Document, a GCE instance identity token, an Azure managed identity, a Kubernetes service account token, a single-use join token, or a key held in an HSM or TPM. The server validates it and issues the agent its own SVID.
Workload attestation: when a workload calls the Workload API over a Unix domain socket, the agent finds the caller's process ID and asks workload attestors (Unix, Kubernetes, Docker) for its properties, such as user ID, filesystem path, namespace or service account. These become selectors.
Registration entries: an operator maps each SPIFFE ID to the selectors a workload must have. Only a process that matches receives that identity.
Credential issuance: the agent obtains server-signed SVIDs for matching entries and hands the workload its short-lived X.509 or JWT SVID, which it then uses to authenticate (mTLS or bearer JWT).

The limit for AI agents is the selectors. A Kubernetes namespace and service account say where a process runs, not which model or prompt it loaded. To narrow that gap, use selectors that pin an image digest where the attestor supports it, sign and verify images at admission, and keep model and prompt artefacts inside the measured image or verify their signatures at load. The IETF WIMSE architecture (draft-ietf-wimse-arch-08, Informational Internet-Draft, July 2026) lists attestation-based provisioning as one way to issue workload credentials and points to RFC 9334 for the attestation roles; it deliberately does not mandate a protocol.

Chaining attestation into credential issuance

The design goal is simple: no attestation, no credential. Rather than checking attestation on every request, gate the moment a credential or key is issued, keep credentials short-lived, and bind them to a key that never leaves the attested environment.

Define reference values: image digests, enclave measurements, signer identities for model and agent packages, and the hash of approved system prompts and tool manifests where these are files.
Collect evidence at start-up: the agent's platform produces signed evidence including a fresh nonce from the verifier.
Appraise: a verifier you control, or a platform verifier you trust, compares evidence with reference values and returns an attestation result.
Issue a bound credential: the credential service or key management service releases a short-lived token, SVID or decryption key only if the result matches policy, bound to a key generated inside the attested environment.
Authenticate on every call: the agent uses that credential with proof of possession (mTLS or DPoP) so the token cannot be replayed elsewhere.
Re-attest on change: a new image, model or prompt version means new evidence and a new credential; the old one expires.

Cloud confidential computing services show this pattern in their own documentation. Platforms are listed alphabetically and as examples only.

Amazon Web Services, Nitro Enclaves: code inside the enclave requests a signed attestation document from the Nitro Hypervisor containing PCR measurements: PCR0 (enclave image), PCR1 (kernel and bootstrap), PCR2 (application), PCR3 (parent instance IAM role), PCR4 (parent instance ID) and PCR8 (image signing certificate). AWS KMS key policies can condition Decrypt and GenerateDataKey on these values, and the documentation recommends PCR3 and PCR8 together. Enclaves in debug mode produce all-zero PCRs, which cannot be used for attestation. See AWS Nitro Enclaves attestation documentation.
Google Cloud, Confidential Space: an attestation service (Google Cloud Attestation or Intel Trust Authority) returns identity tokens containing attributes of the workload; a workload identity pool provider applies attribute conditions that check assertions about the Confidential Space image, the workload container and the VM before the workload can access and decrypt protected data. See Google Cloud Confidential Space overview.

For OAuth-based agent ecosystems, the attestation-based client authentication draft offers the same shape at the protocol level: a Client Attester checks the client instance and its evidence, then issues a Client Attestation JWT carrying the instance's public key in a cnf claim; the instance presents it in the OAuth-Client-Attestation header with a PoP JWT in OAuth-Client-Attestation-PoP. Because it is a draft, build on the pattern, not on header details.

Failure modes

Failure	Authentication side	Attestation side
Long-lived secrets	Static API keys in environment variables are copied and replayed	Attestation done once at deployment; the credential issued then lives for months
No proof of possession	Bearer tokens accepted from any network location	Attestation result passed as a bearer artefact that can be replayed without a nonce
Measuring the wrong thing	Not applicable	Image measured, but model, prompt or tool servers fetched at runtime from mutable locations
Weak reference values	Not applicable	"latest" tags, unpinned dependencies, or policies that accept any signed image from a broad signer
Debug and fallback paths	Shared break-glass client secrets left enabled	Debug enclaves or join tokens used in production because attestation failed
Trusting the wrong verifier	Accepting tokens from any issuer in a federation	Accepting attestation results without checking the verifier's identity and freshness
Attestation treated as authorisation	An attested agent is given broad scopes because it is "trusted"; it is then prompt-injected and uses them

Decision criteria: how much attestation to require

Internal agent, low impact, read-only tools: strong authentication with short-lived, workload-issued credentials and signed images verified at admission. Runtime attestation adds cost for little gain.
Agent with write access to production, finance or identity systems: node and workload attestation before issuance (SPIFFE-style), pinned image digests, signed model and prompt artefacts verified at load, and proof-of-possession tokens.
Agent handling regulated or third-party confidential data: TEE-based attestation with key release conditioned on measurements, so data keys exist only inside the approved build.
External agents calling your APIs: you usually cannot attest them yourself. Require strong client authentication and, where the operator offers it, an attestation statement from a Client Attester you trust; treat everything else under KYA risk tiers.
Small organisation: start with workload identity federation and signed images; the managed identity of the cloud platform performs node-level attestation for you. Large organisation: run a central verifier and policy so every team appraises evidence the same way.

Worked scenario: a finance reconciliation agent

A finance team runs an agent that reads bank statement files, matches them to ledger entries and posts adjustments up to a set limit through the ledger API.

Before: the agent runs in a Kubernetes pod with a static API key for the ledger in a secret. Anyone who changes the container image, the model endpoint or the system prompt in the config map keeps full posting rights.
Authentication fix: the static key is replaced with a SPIFFE ID, mTLS to the ledger gateway and tokens bound to the SVID key. A copied token no longer works elsewhere.
Attestation fix: the registration entry requires the namespace, service account and image digest. The system prompt and tool manifest are baked into the signed image instead of a config map; the model artefact is verified against its signature at load. A changed image gets no SVID and therefore no ledger access.
Authorisation stays separate: the ledger still enforces the posting limit and requires human approval above it, because an attested agent can still be misled by a crafted statement file.
Evidence: SVID issuance logs and attestation failures go to the SOC; any failed attestation for this entry opens an incident.

Detection and measurement

Attestation failures: log every failed appraisal with the mismatching measurement; a sudden failure after a deploy is often a legitimate change, but an unexplained one is a tampering signal.
Credential issuance without attestation: alert on tokens or SVIDs issued through fallback paths such as join tokens or static secrets.
Token use from unexpected locations: proof-of-possession failures and audience mismatches show replay attempts.
Debug mode in production: alert on enclaves or confidential VMs started in debug configurations.

Metrics:

Share of production agents whose credentials are issued only after attestation (by risk tier).
Share of agent credentials that are sender-constrained (mTLS or DPoP) rather than bearer.
Median credential lifetime for agent identities.
Share of agent images, models and prompt artefacts with verified signatures at deploy or load.
Attestation failures investigated within the agreed time.

Framework mapping

Area	Authentication	Attestation
NIST SP 800-53 Rev 5	IA-9 Service Identification and Authentication; IA-3 Device Identification and Authentication	SI-7 Software, Firmware, and Information Integrity; SI-7(15) Code Authentication; SR-11 Component Authenticity
NIST CSF 2.0	PR.AA-03 users, services and hardware are authenticated; PR.AA-04 identity assertions are protected, conveyed and verified	PR.PS-02 software is maintained, replaced and removed commensurate with risk
MITRE ATT&CK v20	T1528 Steal Application Access Token; T1078 Valid Accounts	T1195.002 Compromise Software Supply Chain
MITRE ATLAS	AML.T0012 Valid Accounts	AML.T0010 Supply Chain Compromise; mitigations AML.M0013 Code Signing, AML.M0014 Verify AI Artifacts
IETF	RFC 8705; OAuth Attestation-Based Client Authentication draft	RFC 9334 RATS Architecture; WIMSE architecture draft

Common failure patterns

Calling workload identity "attestation" when it only checks location: a namespace selector proves where a pod runs, not what it runs.
Prompts and tool lists outside the measured boundary: the image is attested but the behaviour-defining files are mutable at runtime.
Attestation once, credentials forever: a long-lived secret issued after a single check removes the value of the check.
Over-scoped build credentials: the signing and release pipeline becomes the weak point, as the Amazon Q case showed. Protect it as a privileged identity.
Trusting attested agents with broad scopes: attestation proves integrity, not intent; least privilege still applies.
Accepting attestation results without freshness: replayed evidence from an old, approved state hides a later change.

Practitioner checklist

Replace static agent API keys with short-lived, workload-issued credentials.
Bind agent tokens to keys with mTLS (RFC 8705) or DPoP so stolen tokens cannot be replayed.
List the components that define each agent's behaviour (image, model, system prompt, tool manifest, MCP servers) and bring them inside a measured or signed boundary.
Gate credential issuance on attestation for agents with write access to sensitive systems.
Pin reference values to digests and signer identities, not tags.
Require a fresh nonce or timestamp in evidence and check the verifier's identity.
Log attestation failures and fallback issuance to the SOC.
Keep authorisation, tool limits and approvals in place for attested agents.

Agent Authentication vs Agent Attestation: Proving Who Calls and What Actually Runs