AI Agent Output Attestation: A Practical Guide

Output attestation is a signed record that binds an agent-generated file to the model, prompt, and tool chain that produced it. Instead of a bare PDF showing up in a shared folder, the file arrives with a cryptographic envelope that names the agent, the model version, the prompt hash, the tools it called, and a timestamp from a trusted authority.

The concept is familiar from software supply chain work. SLSA, in-toto, and Sigstore all exist because build artifacts on their own do not prove how they were produced. Agent outputs have the same problem, and they carry more risk because the "build" is non-deterministic. A regenerated file will differ even with identical inputs, so the only durable anchor is a signed record of the run itself.

The C2PA specification, originally designed for photos and video, has become the rough template for agent provenance. It defines a manifest that travels with the asset and can be re-verified after the fact. Text, code, and structured data need the same treatment, just with different manifest fields. The Coalition for Content Provenance and Authenticity publishes the current spec at c2pa.org.

Attestation is not the same as access control or audit logging. Access control decides who can read a file. Audit logs record what happened inside a system. Attestation produces an artifact that survives outside any single system and can be checked by a party that was not present when the file was generated.

Two pressures are pushing attestation from research paper to procurement checklist. The first is deepfake risk. Finance teams have already been tricked by synthetic video calls, and the defensive response has been to demand provenance on any artifact that influences a decision. If a vendor sends a signed invoice PDF generated by an agent, the receiver wants to know which model produced it and whether the signing key is trusted.

The second pressure is internal. When agents start touching money, contracts, or regulated data, legal and risk teams ask a simple question: can you reconstruct what the agent did? Logs in a vendor console are not enough, because the vendor controls the logs. A signed output that names the model, prompt, and tool calls is independently verifiable, even after the agent platform is replaced.

Writing in April 2026, SVRN covered how several payment rails now require provenance on any agent-originated instruction before it clears, and an Ethereum hackathon demoed on-chain verifiable agent registries that let counterparties check an agent's public key before accepting its output. The common thread is that provenance is moving from a nice-to-have inside one company to a protocol-level expectation between companies.

None of this requires blockchains or exotic cryptography. The underlying primitives, hash trees, detached signatures, and timestamp authorities, have been stable for decades. The work is in plumbing them into the agent runtime.

At a minimum, a working attestation pipeline has three stages: capture, sign, and store. Each one is simple on its own. The interesting decisions are about what you capture and where you store it.

Step 1: Capture the run context. Before the agent produces its final artifact, assemble a manifest. Include the model name and version, a hash of the full prompt (system plus user), a hash of any retrieved context, the ordered list of tool calls with their arguments and responses, the agent's identity, and a timestamp. Do not include the raw prompt in the public manifest if it contains sensitive data. Hash it and keep the plaintext in a restricted store.

Step 2: Sign the artifact plus the manifest. Concatenate a hash of the output file with the manifest hash, then sign the result with a key tied to the agent's identity. Short-lived keys issued per run, as Sigstore does with its Fulcio CA, avoid the operational pain of long-lived secrets. If you already run a workload identity system like SPIFFE, reuse it. The goal is that anyone with the public key can verify that a specific agent produced a specific file at a specific time.

Step 3: Store the signed bundle with the artifact. The attestation should travel with the file or be retrievable from a well-known location. For binary formats that support embedded metadata, C2PA-style in-asset manifests work. For plain text, JSON, or arbitrary files, a sidecar file with a predictable name (report.pdf next to report.pdf.intoto.jsonl) is the simplest pattern. Downstream verifiers fetch both and run a standard check.

Give your agent outputs a verifiable home

Fast.io gives agents a workspace with versioning, audit trails, and granular permissions, so attestation records stay bound to the files they describe. Free agent plan includes 50GB storage and 5,000 credits per month, no credit card required.

Sign Up Free

The storage layer is where most attestation projects stall. A signed manifest is useless if the verifier cannot find it, or if the artifact has been re-uploaded and stripped of its sidecar. Three options cover most real deployments.

Object storage like S3, GCS, or R2 is the default. Put the artifact and the attestation in the same prefix, set an immutability policy, and publish the bucket's public key. This works, but you end up writing your own indexing, retention, and access control. Every agent team rebuilds the same glue.

A dedicated supply chain store like Sigstore's Rekor transparency log is the right answer for public artifacts. Rekor gives you an append-only log and inclusion proofs, which matters when the verifier does not trust the signer. The tradeoff is that the log is public, so you cannot use it for confidential agent outputs without additional encryption.

A workspace platform that already models files, versions, and permissions is the practical middle ground for most teams. Fast.io is one option here. When an agent uploads a file, the workspace records who uploaded it, when, and which version it replaces. Pair that with a signed attestation stored as a sibling file or in the file's metadata, and you have a workspace where every artifact has a verifiable provenance record and a human-readable history. The audit trail gives human reviewers a timeline, and the permissions model keeps the attestation visible only to the people who should see it. Alternatives like Box or Google Drive can hold the sidecar file too; the choice comes down to whether the platform also gives you agent-native APIs and ownership transfer for when the human takes over.

Here is the shape of a working pipeline, using in-toto-style attestations and a generic object store. The exact tooling does not matter; the data flow does.

import hashlib, json, time
from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PrivateKey

def attest(agent_id, model, prompt, tools, output_bytes, signing_key):
    subject_digest = hashlib.sha256(output_bytes).hexdigest()
    predicate = {
        "agent": agent_id,
        "model": model,
        "prompt_sha256": hashlib.sha256(prompt.encode()).hexdigest(),
        "tool_calls": tools,
        "timestamp": int(time.time()),
    }
    statement = {
        "_type": "https://in-toto.io/Statement/v1",
        "subject": [{"digest": {"sha256": subject_digest}}],
        "predicateType": "https://fast.io/agent-output/v1",
        "predicate": predicate,
    }
    payload = json.dumps(statement, sort_keys=True).encode()
    signature = signing_key.sign(payload)
    return {"statement": statement, "signature": signature.hex()}

The verifier does the reverse: fetch the artifact, hash it, fetch the attestation, check that the subject digest matches, verify the signature against the agent's public key, and check any revocation or timestamp policies. All of that can run in under 50 lines of code per language.

The harder work is capturing accurate tool call records. If your agent framework does not already serialize tool inputs and outputs, you will need to wrap the tool executor. For MCP-based agents, the tool call boundary is already well-defined, which makes capture simpler. Fast.io's MCP server at /storage-for-agents/ exposes each action as a discrete tool call, and the MCP documentation covers the request and response shape that your capture layer needs to record.

A few failure modes come up repeatedly. The first is prompt leakage through the manifest. A well-meaning team hashes the prompt but also stores the plaintext next to it for debugging, then shares the bucket with an auditor and exposes customer data. Separate the verifiable record from the debug log.

The second is timestamp drift. If the signer's clock is wrong, attestations can fail verification against revocation lists. Use a timestamp authority or a trusted time service rather than the agent's local clock.

The third is attestation rot. A signed artifact from 2024 cannot be verified in 2029 if the CA's public key is gone. Archive the full trust chain, not just the signature. Nick Vincent's overview of attestation across the AI supply chain and Truescreen's guidance on prompt traceability both emphasize this point: durability is a storage problem, not a cryptography problem.

The fourth is scope creep in the manifest. Every additional field is a field that future verifiers must understand. Start with a tight schema, version it explicitly, and resist adding runtime fields unless a real verifier needs them.