Behavioral Attestations: Cryptographic Trust History for AI Agents at Production Scale

An AI agent that has built a strong trust record on one platform faces a cold-start problem when moving to another. The behavioral history is locked in the originating platform's database — the receiving platform can't verify it, and the agent can't prove it.

Behavioral attestations solve this problem by creating cryptographically signed, portable summaries of agent operational history that any platform can verify without access to the original raw data.

1. The Portable Trust Problem

Consider an agent that has operated on Platform A for six months, building a substantial behavioral record: thousands of heartbeats, evaluation results across 16 dimensions, pact compliance history, and a composite trust score of 750. The agent's operator decides to deploy it on Platform B.

Platform B faces an information asymmetry:

• The agent's score of 750 was computed on Platform A's infrastructure
• Platform B has no way to verify that the score reflects genuine behavioral evidence
• The agent could have gamed Platform A's scoring system in ways Platform B can't detect
• The raw heartbeat and eval records are proprietary to Platform A

Without a verification mechanism, Platform B must either (a) accept the score on faith, (b) re-evaluate the agent from scratch (ignoring six months of behavioral history), or (c) reject the agent as unverified.

Behavioral attestations provide a fourth option: a cryptographically signed artifact that proves specific claims about the agent's behavioral history, verifiable by any platform with the attester's public key.

2. Attestation Schema

The memory_attestations table (from packages/db/src/schema/memory-attestations.ts) stores each attestation with these fields:

The payload contains the behavioral claim being attested — a structured summary of the agent's operational history that the signer has verified. The signature is a cryptographic signature over the payload using the attester's private key. A verifying party can confirm authenticity by checking the signature against the attester's public key.

3. Production Attestation Data

30 attestations are on record from 2026-05-13 to 2026-05-18:

behavioral_summary attestations compress an agent's operational history — recent heartbeat outcomes, pact compliance record, eval pass rates — into a structured summary that is signed at the time of creation. A behavioral_summary attestation made on 2026-05-17 represents the attester's verified claim about the agent's behavior as of that date.

filesystem_provenance attestations are used for a different purpose: they attest to the provenance of files or artifacts in the agent's operational context — that a specific codebase, skill, or configuration artifact was used in a verified operational context. The single filesystem_provenance attestation corresponds to a coding agent's code provenance record.

4. The Three-Layer Trust Architecture

Behavioral attestations occupy the middle layer of a three-layer trust architecture:

Layer 1: Raw operational data. Heartbeats, eval results, pact interactions, confabulation findings. High volume, granular, proprietary to the platform. Not portable without data sharing agreements.

Layer 2: Behavioral attestations. Cryptographically signed summaries of operational behavior. Medium volume, structured, portable. Verifiable by third parties. This is the layer this paper documents.

Layer 3: Composite trust score. A single number aggregating all behavioral evidence. Low granularity, highly portable, easy to compare. Cannot be verified without the Layer 1 data or Layer 2 attestations that produced it.

Each layer serves different verification needs:

• Layer 3 (composite score) is sufficient for first-pass filtering: "is this agent above the quality threshold?"
• Layer 2 (attestations) is sufficient for trust verification: "can I confirm this agent's behavioral claims without accessing their full operational database?"
• Layer 1 (raw data) is sufficient for full audit: "show me every data point that contributed to this score"

5. Attestation Validity Windows

Each attestation has an expiration time (expires_at). This is a critical property: a behavioral attestation should not be treated as eternally valid. An attestation of "this agent achieved 94.7% safety check pass rate over the last 30 days" made six months ago is a claim about behavior that is six months old.

The expiration window creates a freshness signal: a recently-issued unexpired attestation carries more behavioral information about current agent behavior than an expired one. Relying parties should check attestation expiry before accepting a behavioral summary as current.

6. The Verification Protocol

A relying party (e.g., a marketplace operator, a hiring organization, a partner platform) can verify an attestation without contacting the originating platform:

1. 1.Retrieve the attestation payload and signature
2. 2.Obtain the attesting platform's public key (published in a known location)
3. 3.Verify the signature over the payload
4. 4.Check that the attestation has not expired
5. 5.Parse the payload's behavioral claims

If the signature validates and the attestation is current, the relying party has cryptographic proof that the attesting platform signed this specific behavioral summary for this specific agent at a specific time. The behavioral claim is as trustworthy as the attesting platform.

This is the same verification model used in TLS certificate chains, verifiable credentials, and signed software packages — a well-understood cryptographic protocol applied to the problem of portable agent behavioral history.

Replication

Schema: packages/db/src/schema/memory-attestations.ts. Production data from memory_attestations table — 30 records as of 2026-05-18. The attestation_type distribution (29 behavioral_summary, 1 filesystem_provenance) is a direct query result.