The standard story
The standard story about agent identity goes like this: an agent has a cryptographic credential — a certificate, a DID, a signed token — issued at deployment time by a trusted authority. When the agent makes a request, it presents that credential. The relying party verifies the signature, checks the issuer, and grants access.
This story is clean and tractable. It maps directly onto existing PKI, OAuth, and WebAuthn infrastructure. It is the model behind most current agent identity proposals, including several active IETF internet-drafts.
The story has one problem: it only applies at the moment the credential was issued.
Binding time versus exercise time
Consider what a credential actually attests. A certificate issued at agent deployment attests: at this moment, this agent was running this model version, had this configuration, and passed whatever checks the issuer ran. That fact is real and useful.
Now consider what happens over the next 72 hours of continuous operation. The agent processes hundreds of thousands of tokens. Its context window fills, compresses, and rotates. If the agent uses a persistent memory architecture, new facts are written and retrieved. If it does not, session history is truncated. Either way, the behavioral state at hour 72 is not the same as the behavioral state attested at hour zero.
This is not a hypothetical risk. It is the ordinary operating condition of any long-running agent with a finite context window.
A recent IETF internet-draft, draft-anandakrishnan-ptv-attested-agent-identity-00, proposes hardware-anchored attestation using TPM 2.0 and zero-knowledge proofs (Groth16 zk-SNARKs) to bind an agent's identity to a secure enclave at deployment. The proposal is technically serious — sub-200ms proof generation, HotStuff BFT consensus for distributed verification, EAT and SCITT interop hooks. It solves the binding-time problem well.
But binding-time attestation does not tell you whether the agent that calls your API at hour 72 is behaviorally consistent with the agent that was attested at hour zero. The credential is still valid. The agent may have drifted.
Why this matters for trust
Human accountability frameworks handle a version of this problem. A person has a persistent legal identity — passport, employee record, professional license — issued at a point in time. Their behavior varies. The accountability thread still holds because identity and behavior are treated as separable: you can sanction the same legal person for behavior that was different last year.
AI agents cannot make the same assumption. An agent's "identity" is not separable from its behavioral state in the same way. After context compression, model reload, or retrieval failure, the agent processing a request may be running with materially different implicit priors, retrieved context, or active constraints than the agent that was attested. The credential is the same. The behavior may not be.
In high-stakes domains — healthcare decision support, industrial control, financial execution — this is not a philosophical edge case. It is the difference between trusting the system you tested and trusting whatever that system has become since you tested it.
What exercise-time attestation requires
Binding-time attestation answers: was this agent correctly configured when it was deployed? Exercise-time attestation would answer: is this agent behaving consistently with its attested identity right now?
A minimal exercise-time mechanism would need to capture at least three things:
- Context state at request time. What is the agent's active context composition? Has it been recently compressed, rotated, or partially replaced?
- Behavioral consistency since last attestation. Has the agent's response distribution on a canonical probe set stayed within the envelope established at binding time?
- Memory write integrity. If the agent uses persistent memory, has the retrieved context at request time been drawn from the memory corpus present during attestation, or from material written after?
None of these are simple to measure. Context state is partially internal to the model. Behavioral consistency requires live probing, which adds latency and cost. Memory write integrity requires verifiable logging of all writes since attestation — which is exactly what SCITT-style transparency logs could, in principle, provide.
This is not a solved problem. But it is the problem that needs to be solved before deployment-time attestation alone can support high-trust continuous deployments.
A two-phase trust stack
The right model is not a single credential but a two-phase trust stack:
- Binding-time attestation — hardware-anchored, cryptographically sealed at deployment. Answers: was this agent correctly instantiated from a verified configuration? This is what PTV and similar proposals provide.
- Exercise-time attestation — behavioral, sampled at request time or at defined intervals. Answers: is this agent still behaving consistently with its attested identity? This requires infrastructure that does not yet exist as a deployed standard.
Phase one without phase two is like issuing an employee badge at hire and then never checking whether the person using it is still the same employee. It provides strong initial guarantees and weak ongoing guarantees.
For agents that run a single stateless transaction and terminate, phase one is probably sufficient. For agents that operate continuously over hours or days — the systems most likely to be deployed in high-stakes contexts — phase two is the missing layer.
Where the work is happening
Several IETF working groups are active on adjacent pieces: RATS (Remote Attestation Procedures) for the evidence and claims model, SUIT (Software Updates for Internet of Things) for firmware manifest integrity, SCITT (Supply Chain Integrity, Transparency and Trust) for audit transparency, and SPICE (Secure Patterns for Internet CrEdentials) for credential format discipline. Privacy Pass adds privacy-preserving token issuance for scenarios where raw agent identity should not be exposed.
None of these, taken alone, closes the exercise-time gap. A complete solution would require composing pieces from all of them — plus a behavioral probe mechanism that does not yet exist as a standards-track proposal.
The PTV draft is a useful starting point. Its threat model, STRIDE analysis, and hardware anchoring are serious work. The gap it leaves is not a criticism of the draft — it is a gap in the current state of the field. Naming it precisely is how it gets closed.