Building Confidential AI Network — governed multi-party training without a data lake

Multi-party AI still often starts with a corpus copy, an NDA, and operational trust about where training ran.

CAN targets the case where partners need each other’s data but cannot centralize it or treat bilateral agreements as the sole control.

Technical walkthrough: components, fit, and design vs live. Product tour · GitHub.

Problem

Training needs multi-party data; regulation and competition forbid bulk export; audits need attributable evidence.

Protocol (not a warehouse):

Publish metadata and policy, not the corpus
Negotiate a Ricardian contract (legal prose + machine-enforceable state)
Train only inside a policy-bound environment (TSP / CCRP)
Leave tamper-evident provenance (SCITT CCF + job audit bundles)

Informed by iSPIRT DEPA.

Three parties, one control plane

Role	Job	Typical assets
TDP — Training Data Provider	Monetize / share data safely	Encrypted datasets, classification, usage policy
TDC — Training Data Consumer	Train models under contract	Model IP, training params, evaluation criteria
TSP / CCRP — Tech Service / Confidential Clean Room Provider	Host isolated compute	Confidential VMs, OKE/AKS jobs, KMS, storage

AppAdmin operates the platform (users, constraints, global deployment settings).

Humans never share one “god login.” Production identity is the cloud IdP for that deployment:

Cloud	Identity
OCI	IAM Identity Domains
Azure	Microsoft Entra ID
GCP	Identity Platform
AWS	Cognito

Keycloak remains for local docker-compose and Playwright only — not on OKE/AKS.

Lifecycle: catalog → contract → train → prove → predict

TDP publishes catalog          TDC drafts Ricardian contract
        │                                │
        └──────────┬─────────────────────┘
                   ▼
         Multi-party sign (TDP / TDC / TSP)
                   │
                   ▼
         Provision / select clean-room env
                   │
                   ▼
         Training job (ciphertext in → artifacts out)
                   │
                   ▼
         Provenance claim + SCITT receipt
                   │
                   ▼
         Optional deploy / inference under same policy

What makes this different from a workflow tool:

No training without signed state — the contract is the gate
Environment binding — compute, region, KMS, and storage are part of the agreement
Evidence plane — outcomes are claimed, not merely logged in an app DB

Walk it in the UI: lifecycle user guide and the participant E2E guide.

Four planes (how we think about the system)

1. Control plane

React portal + Node.js APIs: catalog, contracts, roles, AppAdmin.
State machine for contract lifecycle; RBAC mapped from IdP groups.

2. Data & crypto plane

Dataset encryption patterns (DEK/MEK), optional differential privacy, DEPA-aligned entity IDs, residency / jurisdiction fields on contracts.

3. Execution plane

Training jobs in isolated environments — confidential VMs, segmented Kubernetes (OKE Jobs on OCI), or attested clean rooms. East-west trust can use SPIFFE/SPIRE; cloud APIs use workload identity (no long-lived keys in pods).

4. Evidence plane

SCITT (Supply Chain Integrity, Transparency, and Trust) on a CCF confidential ledger for claims; SIEM export hooks for SOC tools.

Deep dive: multi-cloud security patterns · three identity planes.

Stack (what you actually run)

Layer	Choice
Frontend	React (MUI), role dashboards, contract wizard, training UI
Backend	Node.js, Express, Sequelize
Data	PostgreSQL (local and OCI managed Postgres)
Local IdP	Keycloak (compose)
Ledger	SCITT CCF (compose / opt-in cloud)
OCI IaC	Terraform: VCN, OKE, PostgreSQL, OCIR, Identity Domains, K8s apps
Azure IaC	Terraform pilot: AKS (+ WI), PostgreSQL, Entra apps, Key Vault, Blob (`deployment/azure/terraform`)
AWS / GCP	Security architecture docs; IaC still design-stage

Local path: ./start-system.sh · quick start.

OCI path: ./deployment/deploy-oci.sh terraform -y --images · OCI readiness.

On OKE, the frontend nginx proxies /api to the backend ClusterIP so the browser stays same-origin — no brittle absolute API URLs baked into images.

OCI as the primary cloud product path

We invested first in Oracle Cloud because clean-room + Vault + OKE + Identity Domains map cleanly to the four planes:

Identity Domains for TDC / TDP / TSP groups (no Keycloak on cluster)
OCI Database with PostgreSQL for the app (Sequelize dialect)
OCIR for backend/frontend images
Vault / Object Storage / SPIFFE / WIF / training Job as opt-in modules (enable_*)
Azure deployment narrative: product tour + Azure confidential computing deep dive when a tenancy is not yet available

Maturity: baseline apply path is in-repo; live WAF/API Gateway, SCITT HA, and production Job submitters are still opt-in / operator follow-through. See OCI design complete and the marketplace listing checklist.

Compliance mapping

Crosswalk of met / partial requirements (not a tenancy certification claim):

NIST Cybersecurity Framework 2.0
NIST SP 800-53 Rev. 5
CIS Controls v8

Read: SECURITY_CONTROLS_NIST_CIS_MAPPING.md · blog note.

That matrix is a control map, not a claim of SOC 2 / FedRAMP certification for a customer tenancy.

Out of scope / non-claims

Claim	Reality
“One-click multi-cloud production”	OCI/Azure have IaC depth; AWS/GCP are architecture-first
“SCITT always on in every deploy”	Local/opt-in; cloud HA is operator-led
“Keys never leave the enclave in every path”	Design + partial code; TEE attestation maturity varies by cloud
“Keycloak in production on OCI”	False — Identity Domains only

Readiness docs: OCI_READINESS.md, AZURE_READINESS.md.

Why this architecture

Alternative	Failure mode	CAN stance
Central data lake	Sovereignty + blast radius	Federated catalog; data stays with TDP
Email NDAs	No machine gate	Signed Ricardian state before train
Single IdP everywhere	Cloud lock-in + key sprawl	Cloud-native IdP + SPIFFE for workloads
App-only audit logs	Tamperable	Ledger claims + SIEM export

The product bet is simple: contract first, compute second, proof always.

Where to go next

Goal	Link
UI tour	Product tour
Docs home	docs/README.md
Architecture	ARCHITECTURE.md
SCITT	SCITT_CCF_ARCHITECTURE.md
SPIFFE + OCI WIF	post · design
Source	github.com/gitmujoshi/Confidential-AI-Network

If you are evaluating CAN for a regulated collaboration, start with the product tour, then the multi-cloud security patterns doc, then an Azure staging subscription (or your preferred cloud) — not a slide deck alone.