What Is Data Verifiability, and Why Does It Matter for AI?

An AI agent doesn't stop to ask whether the data it's using can be trusted. It just uses it to approve a transaction, price a policy, or hand context to the next agent in line.

That’s the quiet risk underneath every AI-driven decision: unverifiable data can be altered or lost, and nothing catches it until the output is already wrong.

Here’s what data verifiability actually means — and why it’s becoming non-negotiable as AI systems are given more decision-making ability.

What is data verifiability?

Data verifiability is the ability to confirm, independently of a storage provider, that data has not been altered and is still available. The National Institute of Standards and Technology (NIST) defines integrity verification as the process of obtaining assurance that data has not been modified since it was created or last checked. Verifiability confirms that the same data has been stored, but it doesn't confirm whether or not the data was accurate when it was written.

However, most storage relationships don't work this way. A hyperscale cloud provider tells you your file is intact and your bucket is available. You can compare checksums you kept yourself, but the record of what is stored and whether it's available lives entirely in the provider's systems. You're trusting the provider's own dashboard, logs, and support team. Verifiability replaces that trust with proof.

This distinction matters more as AI systems become the ones acting on that data. As AI takes actions with consequence, the data it runs on has to be provable. One builder's approach shows what that looks like in practice: Carry adds a proof and access layer on top of Walrus Memory, so every agent answer carries a verifiable receipt of what it remembered and whether it was authorized to use it.

How do I verify the source of a dataset?

Verifying a dataset's source comes down to four checks:

1. Confirm the data has an independent record, not just a provider's log
A file's existence and history should be recorded somewhere the storage provider doesn't fully control, not just in their internal database.

2. Confirm the identifier is derived from the content, not assigned by the provider
If the identifier is generated from the data itself, altering the data would change the identifier too, making tampering detectable rather than invisible.

3. Confirm availability was certified independently, not just reported
Most storage systems report availability through a status page the provider controls. Look for availability that a quorum of independent storage nodes certifies and records publicly at the time of upload..

4. Re-run the check on retrieval, not just at upload
A dataset that was verified once at upload can't detect later tampering. Verification should be repeatable every time the data is accessed.

On Walrus, this looks like: each blob's ID is derived from its content, and its availability is certified onchain when it's uploaded, by a quorum of storage nodes, until an end date you pay for. Reads through the Walrus client re-verify the bytes against the blob ID by default, and anyone can check a blob's certification and expiry on Sui. The checks are built into the protocol rather than left to a manual audit.

Why does verifiability matter as AI systems scale?

Verifiability matters more as AI systems scale because decisions get made further away from a human who could catch a data problem before it compounds. An agent acting on stale, altered, or missing data doesn't just produce one bad output: it can act on that output, and pass it to the next agent in a workflow.

Gartner predicted in 2025 that 60% of AI projects lacking AI-ready data would be abandoned through 2026, with 63% of organizations either lacking or unsure whether they have the right data-management practices for AI at all. Unverifiable datais one part of that readiness gap, not separate from it.

Multi-agent systems raise the stakes further: when several agents share a memory layer or dataset, each one is trusting not just the data but every other party who touched it. This is also where agentic memory debt compounds fastest. Altered or missing memory can quietly skew every downstream decision built on it. Verifiability is what lets that trust be checked rather than assumed.

How is verifiability different from encryption or access controls?

Encryption, access control, and verifiability are frequently bundled together as "security," but they answer three different questions.

Encryption protects confidentiality: who can read the data. Access control protects authorization: who can act on it, and how. Verifiability protects integrity and availability: whether the data is still there and unchanged, regardless of who's allowed to see it.

A file can be perfectly encrypted and access-controlled and still be silently corrupted, deleted, or unavailable. Verifiability is the property that detects silent data loss. On Walrus, these are separate layers. Walrus itself provides verifiability: every blob is public, content-addressed, and certified onchain. Seal adds encryption and onchain access policies on top, so you can choose who can read the data without changing how its integrity and availability are verified.

How does Walrus Console make verifiability practical?

Walrus Console is the managed way to build on Walrus, and it's built directly on that verifiable foundation. Every file you store in Console is a Walrus blob, and Console returns its blob ID. You can use that ID to read the blob through the Walrus client, which verifies the bytes against the ID, and to check its certification and expiry on Sui, without going through Console.

Console adds per-file envelope encryption and file-level access controls on top of Walrus's underlying verifiability, so developers get confirmable integrity, confidentiality, and authorization as three separate, explicit settings.

This is also where Console diverges from a typical S3-style object store: with a hyperscale provider, availability and integrity are represented by an SLA and a status page, a promise you take on trust. With Console, availability and integrity are properties of the underlying Walrus protocol, so the same familiar upload-and-retrieve workflow comes with something an SLA doesn't: a claim you can check yourself instead of one you have to take the provider's word for.

About Walrus

Walrus is the data platform built for the demands of AI. It helps builders and enterprises keep data useful across apps and models, protect it with encryption and access controls, and verify it independently. As AI systems take increasingly consequential actions, the data they rely on must be provable. Walrus was created by the cryptographers and distributed-systems engineers behind Sui and Meta’s digital currency and payments infrastructure. Start building with Walrus Console and give your agents portable memory with Walrus Memory.