back
CDR on Testnet: A New Way to Use Sensitive Data Without Exposing It
Story
10 April 2026
This article reviews potential use cases for Confidential Data Rails.
For developer resources, visit the CDR SDK on Github.
A few months ago, we introduced Confidential Data Rails (CDR) in a technical paper: a new system for sharing encrypted data under programmable conditions. Today, CDR hits testnet; an important step toward making that design real for builders on Story.
AI is running into a data bottleneck. The most valuable data for AI training is not on the open internet. It's proprietary enterprise data, regulated healthcare and financial data, sensitive user data, and high-signal real-world data that cannot be dumped into an open marketplace. The data exists, but using it usually means giving up control.
That tradeoff becomes more important for us as Story expands toward distributed real-world data collection and onchain registration of training data as IP. If the future of AI depends on high-quality, real-world datasets, the infrastructure cannot stop at provenance and registration. It also needs confidential, programmable access.
Without that, valuable datasets stay locked, collaboration breaks down, high-impact AI workflows never get built, and new data economies fail to emerge.
If training data is going to be sourced, registered, licensed, and monetized onchain, it needs an enforceable way to stay private until the right conditions are met. That is what CDR is for.
The core idea behind CDR
CDR enables encrypted data to remain protected until predefined conditions are met.
Instead of sharing data and hoping it's handled correctly, data owners define the rules upfront, and CDR only allows access when those rules are satisfied.
Data owners define access rules onchain. When a request is made, CDR verifies those conditions and only then triggers decryption. Until that point, the data remains encrypted and inaccessible.
In short: CDR makes private data usable without making it public.
How this solves the AI data problem
CDR changes the default model of data access. Instead of sharing raw data and relying on trust, data owners can define the exact conditions under which encrypted data may be accessed or computed on.
That makes it possible for organizations to collaborate on sensitive datasets, use private data in AI workflows, and unlock models or insights that would otherwise remain out of reach.
In practice, that means developers can build workflows around sensitive data without requiring raw data to be openly shared. The use cases below show what that looks like.
Use cases for CDR
Private Data Marketplace (“Spotify for Data”)
Today there are many AI data marketplaces where people generate valuable data, from voice and video to domain-specific expertise, but capture almost none of its long-term value.
They are paid once, while the data they create continues to generate value for platforms and buyers.
Consider a scenario where contributors retain ownership of their data and earn every time it is used.
With CDR on Story, this model becomes possible.
Contributors can participate in the ongoing value of their data as it gets reused across datasets and buyers.
How it works
Contributors complete tasks or submit data samples through the marketplace.
The marketplace encrypts these samples, registers each contribution as IP on Story, and attach the encrypted access key via IP Vault with license-based conditions.
The marketplace groups individual contributions into datasets. These are registered as derivative IP on Story, creating an ownership chain that traces back to each contributor automatically.
When a buyer purchases a dataset, they receive a license through Story. CDR verifies the license and enables the buyer to decrypt the data. Revenue flows back to every contributor whose data is included, automatically, through Story's royalty system.
End-to-end workflow
- Contributor submits data to the marketplace
- Marketplace encrypts, stores, and registers the data as IP on Story via IP Vault
- Marketplace composes contributions into datasets that are registered as derivative IPs
- Buyer purchases access and receives a license
- CDR verifies the license and enables decryption
- Revenue flows automatically to contributors through Story
Why this matters
- Enables contributors to earn recurring income instead of one-time payments
- Aligns incentives for contributors to provide high-quality data
- Supports composable datasets with automatic ownership and revenue flow
Key idea
Individual contributions can be composed into datasets, with ownership and revenue flowing back to contributors every time that data is used.
Cross-Organization Threat Intelligence
Cybersecurity firms already collaborate on threat intelligence, sharing indicators like IP, domains, and file hashes through industry alliances and standardized feeds. But the deeper data that would actually improve detection, raw network logs, behavioral patterns, attack telemetry, never gets shared. Exposing it would reveal client environments, internal infrastructure, and proprietary detection capabilities.
The result is that threat detection models are trained on shallow indicators rather than deep behavioral data. Sophisticated attacks that span multiple organizations go undetected because no single firm sees the full pattern.
With CDR, firms can contribute rich threat data without exposing it.
How it works
Each firm encrypts its threat data and stores it via CDR with defined usage conditions.
Participating firms jointly define and audit an approved detection or training pipeline, a fixed binary that becomes the only way the data can be used.
The pipeline runs inside a TEE. A TEE, or trusted execution environment, is a secure enclave that can prove what code is running inside it. Through remote attestation (cryptographic proof that the environment and binary match the approved policy) CDR verifies the setup before triggering decryption into the TEE.
Raw data is not handed to participating firms. Instead, the approved pipeline produces only the intended outputs, updated detection models, threat scores, or pattern alerts, while the underlying logs remain confined to the approved environment.
End-to-end workflow
- Firms encrypt threat data and store it via CDR with conditions
- Consortium defines and audits the detection pipeline
- Participant runs approved binary inside TEE and provides attestation
- CDR verifies conditions and triggers decryption into the TEE
- Pipeline runs without exposing raw data
- Outputs are detection models or threat alerts, not raw data
Key Idea
Approved code runs inside a verifiable execution environment, allowing organizations to collaborate on deeper threat data without sharing raw logs directly.
Sovereign Data Access (In-country Enforcement)
Consider a scenario in which a country seeks to enable AI development using local data, such as healthcare or financial datasets governed by national regulations, while requiring that this data remain within its borders.
At the same time, global AI companies want to use this data to build better models.
Traditionally, this creates a hard tradeoff:
- Keep data local and limit its use;
- Or share it externally and lose control
CDR reduces this tradeoff by allowing data to be used under strict, programmable conditions without exposing the data itself.
How it works
Data stays encrypted and stored within the country.
Data owners define policies that specify how the data can be used. These policies can restrict which:
- Infrastructure providers are allowed
- Secure environments can run the workload
- Code or workloads are permitted
External participants do not receive the raw data. Instead, they submit workloads, such as training jobs or queries, to an approved in-country orchestrator.
The orchestrator runs these workloads inside approved secure environments managed by the data provider or authorized local infrastructure operators.
Before any data is decrypted, the secure environment must produce a remote attestation proving that it matches the data owner’s policies, including the expected environment and approved code.
CDR verifies this attestation. Only if the attested environment matches policy does CDR allow decryption inside that environment.
The data never leaves this controlled environment, and the external participant only receives the permitted results of the computation.
End-to-end workflow
- Data is encrypted and stored within the country
- Data owner defines policies for allowed operators, environments, and workloads
- External participant submits a workload
- An approved in-country orchestrator runs the workload in a secure environment
- The environment produces remote attestation
- CDR verifies that the attested environment matches policy
- Data is decrypted only inside that environment
- Computation runs and only permitted results are returned
What CDR unlocks
New Capabilities
- Private data becomes usable without unrestricted sharing
- Collaboration across organizations and regions
- Programmable data access policies
- Data owners retain control over usage and monetization
- Compliant AI systems with built-in auditability
What CDR does not solve
CDR improves access to private data, but does not remove all risks:
- No guarantee against all forms of leakage (e.g., model memorization)
- Depends on the security of the execution environment and approved code
- Trust shifts from participants to code, infrastructure, and policy enforcement
Looking ahead
AI got this far on public data, and there's a heated race for proprietary data already underway. The next phase will depend on high-value data that is private, regulated, or commercially sensitive.
CDR gives developers a way to start building for that future by leveraging encrypted data flows, conditional access, and policy-enforced decryption on testnet.
From here, the goal is to prove the mechanism and expand what builders can do with it. As Story moves toward a world of distributed real-world data collection and onchain registration of training data as IP, confidential access becomes even more important. Provenance tells you what data is while CDR helps define how that data can be unlocked and actually be used.
