Restricted access is not the same as provable access.
Why confidential.storage exists, why receipts beat logs, and why "your auditor verifies it without us" is the only assertion that lasts past a vendor change.
Most teams who say "we have confidential storage" mean one of two things. They mean the data is encrypted at rest, or they mean the compute environment that reads the data is a TEE (an Intel TDX VM, an AMD SEV-SNP enclave, an AWS Nitro Enclave). Both are real. Both restrict who can read the data. Neither proves who did.
That gap is the whole product.
The pain a CISO actually has
A regulated enterprise -- healthcare under HIPAA, finance under DORA, EU operator under NIS2, AI deployer under EU AI Act Article 10 -- already has S3 access logs. They already have a CloudTrail history. They already have an IAM policy describing who is supposed to access what. What they do not have is a way to put any of that in front of an auditor and end the conversation.
The auditor's question is not "do you restrict access?" The auditor's question is: can you prove every access happened under the policy you claimed it did, and can a third party verify your evidence without trusting your storage vendor?
Vendor-controlled logs do not pass that test. They are mutable, the vendor sees the keys, and the auditor has to take the vendor's word that the entries are accurate and complete. That is not evidence. That is hearsay.
What a receipt is, and why it ends the conversation
confidential.storage issues a signed, content-addressed access receipt every time an attested compute environment reads or writes data. Each receipt contains six fields:
- data CID -- the Akave content identifier of the object that was accessed
- attestation measurement -- the cryptographic fingerprint of the compute environment that requested it
- policy ID -- the identifier of the policy that authorized the access
- actor -- the requester identity (an opaque identifier; pseudonymous by default)
- timestamp + nonce -- when, and proof of freshness
- Ed25519 signature -- over a canonical JSON of the above, by an issuer public key
The receipt itself is stored content-addressed on Akave. Its CID is recorded in an indexed catalog so an auditor can query "show me every receipt for object X between dates Y and Z" without the storage operator getting involved. The verifier tool is open source and runs offline. The schema is published as an open specification.
The strong claim: if Akave disappears tomorrow, every receipt issued before that point still verifies. The CID is content-addressed (math), the signature is Ed25519 (math), the policy is referenced by ID (math). None of those depend on a vendor being alive.
Why this matters more in 2026 than 2024
Three regulatory + market shifts compounded:
1. EU AI Act Article 10 went binding
Article 10 demands data-governance controls including verifiable provenance for high-risk AI systems. Vendor-controlled access logs do not satisfy "verifiable" in the way a cryptographic receipt does. Akave's broader writeup on this lives at Akave Cloud's EU AI Act compliance post; the receipt-as-artifact pattern that confidential.storage productizes is its operational form.
2. Agentic workflows became real
"Approved toolchains" -- the assumption that an LLM agent only ever runs the tools you signed off on -- is not a security boundary. Agents read storage, write storage, and chain calls in patterns no one writes in a runbook. The only way to maintain accountability is to make every access verifiable independently, not every tool call. Akave's "Approved toolchains aren't enough" argues this in detail; confidential.storage is the receipt-issuance surface that operationalizes it.
3. "AI data residency" turned out to be a checkbox
Storing data in the EU does not satisfy a regulator who asks for evidence of WHO accessed it. Residency is geography. Sovereignty is custody. Compliance is evidence. The category gap between those three is what Akave's residency-vs-evidence post covers; the receipt is what fills it.
Why this is a sister site to akave.com, not a separate product
confidential.storage runs on the same Akave Cloud platform as akave.com. The data plane (S3-compatible Akave O3 endpoint), the durability layer (Filecoin network), and the receipt anchor (Avalanche L1) are shared. The eCID primitive is the same. The verifier is the same.
What's different is the buyer-surface and the workflow. akave.com is the full platform: AI workloads, analytics, egress economics, sovereignty, more. confidential.storage is the access-flow lens for one specific buyer -- the regulated-enterprise CISO who needs cryptographic audit-grade evidence and does not yet care about the rest of the platform.
If you're in that buyer seat, you don't need a tour of the whole Akave product line to start a conversation. You need a single page that promises one thing -- proof of access -- and a feedback form that asks what you actually need. That is this site.
What we do not promise
- We do not run your model, your inference workload, or your TEE. We provide the verifiable-access surface around them.
- We do not custody your plaintext keys. Key release is gated on attestation + policy match against your KMS or HSM.
- We do not certify your compliance posture. We produce evidence; your auditor consumes it.
- We do not have a fixed TEE-family ship list. The receipt schema is attestation-family-agnostic by design; integration order is co-built with design partners.
What you can do today
If any of the above sounded like a Tuesday-morning problem at your shop, the form on the homepage is the right next step. We read every submission. The textarea exists because the value of this conversation is in the specific evidence pack you need produced, not the generic narrative we already have.