Running bottom-up AI point solutions — letting a thousand flowers bloom — has failed to yield major returns. The big gains come from workflow redesign: taking a top-down view of the process and changing how execution steps work together end-to-end.
— Andrew Ng

In recent analyses on enterprise AI architecture, Andrew Ng made a compelling case: real breakthrough value doesn’t come from using an LLM to speed up an isolated task (like summarizing a PDF). It comes from top-down workflow redesign—re-architecting multi-step business operations into agentic execution graphs.

To illustrate this, Ng points to the commercial credit journey. Automating a single review step saves a modest ~5% in costs. But redesigning the entire process so a borrower gets approved in 10 minutes instead of two weeks redefines the product itself.

This raises an essential question for systems architects: if agentic AI requires end-to-end workflow graphs, what serves as the underlying protocol layer when those workflows cross enterprise boundaries?

India’s Open Credit Enablement Network (OCEN 4.0) is the most concrete public example of that protocol layer for credit—not because it became “UPI for loans,” but because it already specifies roles, async APIs, and a loan-application state machine that agents can invoke without inventing the execution path.

Note: This essay is adjacent to Confidential AI Network (CAN). CAN applies a similar “protocol + governed execution” idea to multi-party training; OCEN applies it to multi-party credit. Both sit in the broader India Stack / iSPIRT design lineage (alongside DEPA).

The bottleneck: why agentic software graphs hit an execution wall

When developers build agentic workflows in code frameworks (LangGraph, AutoGen, CrewAI), they define execution nodes, state transitions, and tool calls within a single software environment.

The moment an AI agent attempts to execute a financial workflow across independent companies, it hits an interoperability wall:

                  [ SOFTWARE AGENTIC GRAPH ]
                     (LangGraph / AutoGen)
                     Conversational Intent
                             │
                             ▼
  ┌──────────────────────────┼──────────────────────────┐
  │                          │                          │
  ▼                          ▼                          ▼
[Data Extraction]     [Risk Scoring]         [Offer Matching]
  │                          │                          │
  └──────────────────────────┼──────────────────────────┘
                             │
                             ▼
                     [ EXECUTION WALL ]
          (No standard APIs to talk to external banks,
           consent platforms, or repayment rails)

Without a unified network protocol:

• An agent cannot pull verified, real-time cash-flow data without manual document uploads.
• It cannot broadcast structured loan requests to multiple independent lenders simultaneously.
• It lacks a universal settlement rail to execute e-signatures and automated repayment mandates.

An agentic software graph is only as powerful as the network protocol it can invoke outside its own environment.

Bridging Silicon Valley “brains” with DPI “rails”

The key to solving this execution bottleneck is synthesizing two different technology philosophies:

Without open protocols, AI agents risk becoming “brains in a jar”—strong at reasoning, blocked whenever they touch banking, identity, or settlement.

Without agents on the edges, open protocols remain static rails waiting for human-driven software. The breakthrough is connecting the two: autonomous reasoning at the edges driving deterministic, protocol-based execution at the core.

Why OCEN can be read as a protocol answer to workflow graphs

Developed as part of India’s DPI (by iSPIRT), OCEN 4.0 takes the core components of a workflow graph and codifies them into an open, multi-party network protocol.

1. A protocol is a network-level graph

In software, a graph consists of nodes, edges, and state objects. OCEN standardizes those primitives across independent market participants:

                            ┌────────────────────────────────┐
                            │     Participant Registry       │
                            │  (Identity & Public Key Auth)  │
                            └───────────────┬────────────────┘
                                            │
                                            ▼
┌──────────────────┐               ┌─────────────────┐               ┌──────────────────┐
│ Loan Agent (LA)  │ ────────────► │  Product Reg.   │ ◄──────────── │ Lenders (Banks)  │
│ (Embeds Credit)  │  Offer Req.   │  (Offer Bids)   │  Publishes    │ (Capital Engine) │
└────────┬─────────┘               └─────────────────┘               └────────┬─────────┘
         │                                                                    │
         │               ┌────────────────────────────────────┐               │
         ├─────────────► │  Derived Data Partner / AA (Data)  │ ◄─────────────┤
         │               └────────────────────────────────────┘               │
         │               ┌────────────────────────────────────┐               │
         └─────────────► │ Disbursement & Collections Partner │ ◄─────────────┘
                         └────────────────────────────────────┘

• Nodes (actors): Loan Agents (borrower interfaces), Derived Data Partners (consent / derived credit inputs), Lenders (capital), Collections Partners.
• Edges (transitions): Open, standardized REST/JSON APIs for offer request, evaluate, e-sign, e-NACH.
• Graph state: Standardized objects that track a loan deterministically from intent to collection.

2. Deterministic protocol core + agentic edges

Financial regulators demand strict auditability—an LLM cannot invent interest rates or skip compliance steps.

OCEN-style designs decouple reasoning from execution:

• Protocol core (deterministic): Enforces state machines for origination, consent verification, and repayment setup.
• Network edges (agentic): Agents translate unstructured voice, regional language, or invoice scans into the precise JSON the protocol graph requires.

That pattern—deterministic core, agentic edges—is the architectural lesson beyond India credit.

3. Walkthrough: intent → OCEN JSON → e-sign / e-NACH

Take a GeM-style working-capital ask—the kind of flow OCEN was actually built to carry:

“Purchase order GEMC-5116877-5754010-1, ₹4.2 lakh, need funds in 48 hours against the PO.”

An LLM at the Loan Agent edge can parse GSTIN, amount, tenure, and product-network membership. It cannot invent an interest rate, skip Account Aggregator consent, or mark the loan disbursed. Those steps belong to the protocol.

Step 1 — the agent emits a CreateLoanApplicationRequest. Fields below are an illustrative subset of OCEN 4.0; live calls are async, JWS-signed, and keyed by requestId for idempotency.

{
  "metadata": {
    "version": "4.0.0",
    "originatorOrgId": "org-loan-agent-gem",
    "originatorParticipantId": "la-gem-sahay",
    "timestamp": "2026-08-24T12:01:00Z",
    "traceId": "trc-9f3a…",
    "requestId": "req-e2e-001"
  },
  "productData": {
    "productId": "po-working-capital-30d",
    "productNetworkId": "pn-gem-sahay"
  },
  "loanApplications": [{
    "borrower": {
      "primaryId": "AAACU1234F",
      "primaryIdType": "PAN",
      "category": "ORGANIZATION",
      "name": "Usha Components Pvt Ltd",
      "aaIdentifier": "aa-id-…"
    },
    "terms": {
      "requestedAmount": 420000,
      "currency": "INR",
      "tenure": { "duration": 30, "unit": "DAY" }
    },
    "pledgedDocuments": {
      "source": "GSTN",
      "type": "GSTN_B2B_INVOICE",
      "format": "JSON",
      "reference": "GEMC-5116877-5754010-1"
    }
  }]
}

Step 2 — the network, not the model, advances state. The Loan Agent fans the application to every lender in the product network. Each lender returns CreateLoanApplicationResponse (PROCESSING or reject). Consent APIs collect one AA consent and forward it. Offer APIs return machine-readable bids. After the borrower accepts, the conversation collapses from many lenders to one, and the application walks a published status machine:

intent (voice / PO / invoice)
        │  agent → structured JSON
        ▼
CreateLoanApplicationRequest  ──►  lenders in product network
        │  async ack (requestId)
        ▼
AA consent  →  offers  →  accept offer
        ▼
KYC  →  loan agreement (e-sign)
        ▼
repayment setup (e-NACH / UPI mandate)
        ▼
disbursement account  →  grant  →  disburse

Statuses the graph already knows: CREATED → CONSENT_RECEIVED → OFFERED → OFFER_ACCEPTED → KYC_COMPLETED → LOAN_AGREEMENT_COMPLETED → REPAYMENT_SETUP_COMPLETED → GRANTED → DISBURSEMENT_COMPLETED.

The agent’s job is to fill JSON the state machine will accept. The lender’s job is to underwrite. The protocol’s job is to refuse illegal transitions—no model is allowed to jump from OFFERED to DISBURSEMENT_COMPLETED.

Why OCEN is a blueprint, not UPI for credit

OCEN has not become UPI, and pretending otherwise makes the architecture claim weaker. UPI is a payment instruction with an operator (NPCI), monthly public volumes, an existing bank participant set, and years of fiscal support for adoption. A loan is an underwriting decision every lender wants to keep proprietary; a protocol can standardise the pipes (application, consent, offer, e-sign, e-NACH) and cannot standardise the yes. OCEN is a specification with no NPCI-equivalent switch, so it has no public origination dashboard. Its data layer—Account Aggregator—took until the mid-2020s to reach reliable bank coverage, years after the 2020 launch. What actually shipped at scale is still mostly government-anchored working capital (GeM Sahay, GST Sahay), not an open marketplace where any Loan Agent talks to any lender the way any UPI app talks to any bank. Lenders still prefer bilateral NBFC/fintech contracts where risk-sharing and default-loss guarantees are negotiated once, not left implicit in a shared spec.

That gap is the point for agentic systems: the protocol shape is usable even when the market is not UPI-scale. Agents need a deterministic graph they can call. OCEN already wrote that graph down. Adoption is a separate, harder problem—and it is why “blueprint” is the right word, not “the missing rail.”

How could the US implement this blueprint?

Replicating a state-backed network protocol in the US faces structural hurdles: the market runs on private abstraction layers rather than public infrastructure.

A composable private graph in the US

US builders do not need a public mandate to test the pattern. They do need the part OCEN actually contributed—a shared schema and registry—not just three vendor SDKs in one agent:

                              ┌──────────────────────┐
                              │  US Borrower Agent   │  (LLM reasoning node)
                              │ (LangGraph / AutoGen)│
                              └──────────┬───────────┘
                                         │ Structured API payloads
       ┌─────────────────────────────────┼─────────────────────────────────┐
       ▼                                 ▼                                 ▼
┌──────────────┐                 ┌──────────────┐                 ┌──────────────┐
│ Data Consent │                 │ Risk Engine  │                 │ BaaS Lenders │
│ (Plaid / MX) │ ──────────────► │ (Alloy / …)  │ ──────────────► │ (Column / …) │
└──────────────┘                 └──────────────┘                 └──────────────┘

Composing Plaid + Alloy + Column is ordinary bilateral integration. The OCEN lesson is a shared participant/product registry and one loan-application schema every lender in the network accepts. Without that, each edge is a custom deal—and the agent is back at the execution wall. The US can test the pattern privately; it does not get the pattern for free by wiring three vendor APIs into LangGraph.

Takeaway

OCEN is not the only way to build agentic financial systems, and it has not won the way UPI did. It is still the clearest public spec of a pattern agents actually need:

Reasoning at the edges, a deterministic multi-party protocol at the core, and a state machine that will not let the model skip e-sign or e-NACH. Without that graph, “workflow redesign” stops at the first bank that does not speak the agent’s tools.

Glossary

References

• Ng, Andrew. (2026). Winning in the Agentic Era — Bain & Company Insights.
• Ng, Andrew. (2026). AI Won’t Replace Workers. It Will Redesign Work — keynote.
• iSPIRT Foundation. OCEN 4.0 — API design principles (async CreateLoanApplicationRequest / Response, idempotent requestId, JWS).
• iSPIRT. Loan journey: auction and offer — one-to-many create / consent / offer, then collapse to one lender.
• iSPIRT / ProductNation. Open Credit Enablement Network — roles (LA, lender, DDP) and GeM Sahay as PO cash-flow pilot.
• Sahamati. Account Aggregator architecture and ecosystem reporting.
• NPCI. UPI product statistics — contrast: operator + public monthly volumes, which OCEN as a spec does not have.

Related: Product tour · Azure product tour deck · SPIFFE/SPIRE on Azure · Contract signing & keys · KMS DEK/MEK · TEE attest → decrypt · Entra architecture note · In-repo: AZURE_SECURITY_ARCHITECTURE.md · AZURE_FEATURES_AND_CONFIGURATION.md · AZURE_SPIFFE_SPIRE_WIF.md

Status: Local Docker product tour covers contracts → train → infer → Auditor (not a hardware TEE). Azure platform IaC includes Key Vault, Blob, and AKS Workload Identity (Terraform README). Confidential compute + Secure Key Release (SKR) are the clean-room target: JCS attestation is often simulated; DCsv3 / confidential containers + real SKR are Design / Phase 3.

1. Control requirements on Azure

1. Can Microsoft operators, or TSP/CCRP operators, read dataset or model plaintext?
2. Can the CAN control plane (Node API) hold DEK/MEK?
3. What evidence shows this job ran in this attested environment under this contract?
4. What happens when escrow times out or attestation fails?

Layered answer:

Microsoft docs worth keeping open: Azure Attestation · Secure Key Release overview · Azure Key Vault.

2. Threat model (Azure clean-room training)

2.1 Assets

2.2 Adversaries (what we design against)

2.3 What confidential computing does not cover

• It does not make bad contract terms safe.
• It does not prove the model is fair, accurate, or free of poisoning (see Auditor / Merkle for lineage, not ethics).
• It does not replace Entra MFA, WAF, or network segmentation.
• Local Docker demos deliberately sit outside this threat model—label them as UX, not TEE.

flowchart LR
  subgraph Outside["Outside TEE — ciphertext + policy"]
    Blob["Blob ciphertext"]
    CAN["CAN API / escrow signals"]
    Entra["Entra SSO"]
    KV["Key Vault / MHSM"]
  end
  subgraph TEE["Confidential VM / container"]
    Att["Attestation evidence"]
    Mem["Decrypt in memory"]
    Train["Train"]
    Out["Re-encrypt outputs · zeroize"]
  end
  Entra --> CAN
  CAN -->|"SIGNED + job"| TEE
  Att -->|"SKR policy match"| KV
  KV -->|"release DEK/MEK or unwrap"| Mem
  Blob --> Mem
  Mem --> Train --> Out

3. Azure Key Vault layout for CAN

Do not collapse every secret into one vault key. Separate infra, signing, and principal crypto.

Contract JSON kmsConfigs should bind the Azure path parties expect, for example:

Maturity: configs are persisted today; training does not yet fully enforce live Key Vault calls on every path. Live resolve-at-train is a go-live checklist item (features catalog).

4. Secure Key Release (SKR) policy

Secure Key Release is Azure’s way to say: this HSM-backed key may be released only to a workload that presents attestation claims matching a release policy.

For CAN, SKR is the Azure-native twin of “attested TLS delivery of DEK/MEK into the TEE.”

4.1 Policy intent (what the policy should encode)

A useful SKR / attestation policy for a CAN job asserts roughly:

If claims fail → no key. Fail closed.

4.2 How SKR fits dual-key escrow

CAN still needs both DEK and MEK (TDP + TDC). SKR does not remove dual-key escrow; it hardens how each key (or a wrap key) leaves the HSM:

Contract SIGNED
  → CCRP provisions confidential environment
  → TEE obtains attestation token (Azure Attestation)
  → Escrow OPEN (deadline)
  → TDP path: DEK (or wrap) released only if SKR/attestation policy OK
  → TDC path: MEK (or wrap) released only if SKR/attestation policy OK
  → BOTH_READY → decrypt in memory → train
  → Re-encrypt outputs · zeroize · DESTROY

Alternate delivery: principals push DEK/MEK over attested TLS into the TEE without SKR, still never through the Node API. SKR is preferred when keys live in Azure Managed HSM / Key Vault with release policy.

4.3 Anti-patterns

5. End-to-end training on Azure

Two flows share the same product UX; only the crypto boundary differs.

5.1 Flow A — Portal train on Azure compute (Phase 1 pilot)

Stakeholder path aligned with the Azure product tour deck:

Entra SSO (MSAL) → Portal + APIM JWT
  → TDP publishes dataset (ciphertext preferred; demo clear only in non-prod)
  → TDC creates Ricardian contract (Azure env + Key Vault kmsConfigs)
  → TDP then TSP/CCRP sign
  → Optional SCITT claim
  → TDC starts training (ACI / AKS Job target)
  → Register artifact → deploy → predict (Open-GMASE gate when wired)
  → Auditor: Merkle tree + contract review

Use this when you need Azure tenancy smoke without full TEE custody on every path.

5.2 Flow B — Dual-key escrow → confidential clean room (production target)

sequenceDiagram
  participant Entra
  participant TDP
  participant TDC
  participant TSP as TSP / CCRP
  participant CAN as CAN + JCS
  participant AA as Azure Attestation
  participant KV as Key Vault / MHSM
  participant TEE as Confidential VM
  participant Blob

  Entra->>CAN: Authenticated parties
  TDC->>CAN: Create contract (Azure + kmsConfigs)
  TDP->>CAN: Sign
  TSP->>CAN: Sign → SIGNED
  TDC->>CAN: Start training job
  TSP->>TEE: Provision confidential SKU
  TEE->>AA: Attestation evidence
  AA-->>TEE: Attestation token
  TEE->>CAN: Attestation bundle (job-bound)
  TDP->>TDP: Verify attestation ∧ contract
  TDC->>TDC: Verify attestation ∧ contract
  TDP->>KV: Authorize DEK / SKR
  TDC->>KV: Authorize MEK / SKR
  KV->>TEE: Release under policy (or attested TLS)
  Blob->>TEE: Pull ciphertext
  TEE->>TEE: Decrypt in memory → train
  TEE->>Blob: Encrypted outputs
  TEE->>TEE: Zeroize keys · destroy session
  TEE->>CAN: Provenance / SCITT events

Same story as the multi-cloud TEE post, with Azure-specific roots of trust (Attestation + SKR).

5.3 Provenance events GRC should expect

• Contract signed (parties, hash, Key Vault refs)
• Job created (bound to contractId)
• Attestation presented / verified
• DEK released · MEK released (signals and/or SKR audit)
• Training started / completed / failed
• Session destroyed / keys zeroized
• Optional SCITT receipt + Auditor Merkle inclusion

Timeout without both keys → EXPIRED / DESTROYED, not “retry forever with soft keys.”

6. Maturity matrix

7. Operator checklist (crypto go-live)

• Signing keys off DB plaintext → Key Vault / MHSM; verify on sign
• Blob containers ciphertext only; CMK on
• DEK/MEK never logged; Node rejects raw key material
• Confidential SKU + attestation policy + SKR (or attested TLS) for CCR path
• Escrow timeout destroys compute; alert on late key attempts
• Provenance/SCITT for signed → attested → released → started → completed → destroyed
• No Keycloak in Azure resource groups

Full architecture and RBAC tables: AZURE_SECURITY_ARCHITECTURE.md §16.

8. Takeaways

1. Threat model first — confidential SKUs defeat host memory snooping; they do not replace contract gates or Entra.
2. Key Vault is layered — platform secrets, CMK, signing HSM, and principal DEK/MEK are different jobs.
3. SKR is policy-as-key-custody — release only to attested measurements the contract allows.
4. E2E train on Azure = Entra → SIGNED contract → attested environment → dual-key release → decrypt-in-memory → zeroize → provenance.
5. Local product tour = runnable UX; this post = Azure confidential-compute target.

One sentence: On Azure, CAN treats training as decrypt-in-enclave under Entra identity, Key Vault custody, and Secure Key Release / attestation policy—never as “trust the TSP’s disk.”

Related: Ricardian contracts · Contract → prediction · KMS DEK/MEK · Azure CC / Key Vault · Merkle / Auditor · Product tour · In-repo: CONTRACT_SIGNING_TECHNICAL_REFERENCE.md · CONTRACT_SIGNING_USER_GUIDE.md

Status: Sign authorization (who may set tdpSigned / tspSigned and reach SIGNED) is live. Cryptographic verification against HSM-backed keys is target (SIGNING_REQUIRE_CRYPTO_VERIFY / Key Vault). Contract Detail often submits a hash or placeholder as signature. Party signing keys are distinct from DEK/MEK.

1. Two key classes (do not conflate)

Signing keys answer: Did this party approve these terms?
DEK/MEK answer: May plaintext exist in the clean room for this job?

Mixing them in one “KMS” slide confuses CISOs.

2. Contract management lifecycle

stateDiagram-v2
  [*] --> PENDING_TDP_APPROVAL: TDC creates Ricardian
  PENDING_TDP_APPROVAL --> PENDING_TSP_APPROVAL: Linked TDP signs
  PENDING_TSP_APPROVAL --> SIGNED: Assigned TSP signs
  SIGNED --> Training: TDC starts job (gate)
  SIGNED --> Inference: Deploy under contractId
  SIGNED --> Audit: Auditor Merkle + contract review

Human-readable terms + machine fields are covered in the Ricardian post. This post focuses on keys, sign, and verify.

3. How party signing keys are managed today

3.1 Data model

Keys are stored as UserKey rows (user_keys):

APIs under /api/signing (authenticated):

Config is env-driven (KEY_ALGORITHMS, DEFAULT_KEY_ALGORITHM, KEY_ID_PREFIX, …). The service can encrypt private PEM with a password helper; production design is not “store raw PEM forever in Postgres.”

3.2 What the live Contract Detail path actually does

On the primary UI path (ContractDetail):

1. GET /api/contracts/:id/signing-data → builds a message and SHA-256 contractHash.
2. UI sets signature to that hash or a ui-{party}-… placeholder.
3. POST /api/contracts/:id/sign with { signature, partyType, did?, walletAddress? }.
4. Backend checks auth: JWT party type, linked TDP / assigned TSP (contractSigningGate).
5. Appends entry to legalDocument.signatures[], sets tdpSigned / tspSigned, advances status.
6. Best-effort SCITT contract_approval claim.

So today the gate that matters for training is: authenticated party allowed to sign + status machine. It is not yet “ECDSA verify over legalDocumentHash with Key Vault key, fail closed.”

3.3 Richer signing surfaces (partial)

There are additional components (ContractSigning, DID modal, es256sign.js WebCrypto, /api/signing/sign) aimed at stronger crypto/DID flows. Additional scaffolding for stronger crypto/DID; product-tour clicks are not HSM-verified end-to-end.

4. Sign authorization (what is enforced)

Authenticated user
  → partyType must match claimed partyType (rolesAllowSigning)
  → TDP: must be linked dataset owner (unless AppAdmin)
  → TSP: must be contract.tspId (unless AppAdmin)
  → Append legalDocument.signatures[]
  → TDP → PENDING_TSP_APPROVAL (typical)
  → TSP → SIGNED

Runtime note: Training checks status === 'SIGNED', reached when the assigned TSP completes the current flow. A tdcSigned column may exist; do not assume “all three roles must crypto-sign” is what local train enforces. Prefer the live path above (Ricardian §4.2).

Auditor never signs — read-only Merkle + contract review.

5. Verification — today vs target

5.1 Today

5.2 Target (Azure / enterprise)

Naming pattern (Azure): can-{env}-user-sign-{depaId} — see Azure security architecture §16.4.

sequenceDiagram
  participant Party
  participant UI
  participant CAN as CAN API
  participant KV as Key Vault / MHSM
  participant DB

  Party->>UI: Approve terms
  UI->>CAN: GET signing-data (message / hash)
  UI->>KV: Sign digest (target)
  KV-->>UI: Signature
  UI->>CAN: POST sign (signature, partyType, keyId/did)
  CAN->>CAN: Authz gate
  CAN->>CAN: Crypto verify (target / flag)
  CAN->>DB: signatures[] + status
  CAN-->>UI: SIGNED or next pending

6. What “verification” means for auditors

7. Maturity matrix

8. Operator checklist (signing go-live)

• SIGNING_KEY_BACKEND=azure-keyvault (or MHSM); no private PEM in DB
• SIGNING_REQUIRE_CRYPTO_VERIFY=true
• SIGNING_REQUIRE_DID_VERIFY=true when DID is present
• Sign message binds legalDocumentHash (not only a timestamp string)
• Train start optionally re-checks signature set / status
• Pen test: forged signature blob with wrong role / wrong party rejected
• Keep DEK/MEK release APIs free of signing-key material and vice versa

9. Takeaways

1. Party signing keys prove agreement; DEK/MEK unlock clean-room plaintext — different custody.
2. Contract management is a state machine: create → TDP → TSP → SIGNED → train/infer/audit.
3. Today the hard gate is authenticated authorization + status; stored “signatures” may be hashes/placeholders on the main UI path.
4. Target is HSM/Key Vault sign + verify-on-submit (and optional verify-on-train), with public keys / DIDs in the app.
5. Auditors verify lineage under Merkle and read the Ricardian; they do not get cryptographic signature verification until verify flags and Key Vault signing are enabled.

One sentence: CAN manages contracts as enforceable lifecycle state; party signing keys should live in Key Vault/HSM and be verified on sign—while today’s demos correctly gate training on who is allowed to mark the contract SIGNED.

Related: Three identity planes · SPIFFE on OCI · Azure confidential computing · Azure Entra architecture · Contract signing keys · In-repo: AZURE_SPIFFE_SPIRE_WIF.md · Azure Terraform README

Status: Path N is in Terraform (enable_workload_identity, default on): AKS OIDC issuer, user-assigned identities, federated credentials, Key Vault Secrets User + Blob Data Contributor for backend / training-job / external-secrets. SPIRE is scaffolded (enable_spire + Helm values)—full mesh and Path F (SPIFFE JWT → Entra) remain phased. Microsoft Path F tutorial: Federate SPIFFE/SPIRE with Entra ID.

1. The three planes on Azure (again)

SPIFFE does not replace TEE attestation / SKR for DEK/MEK release. It answers which process; the enclave answers what hardware measurement.

2. Two Azure paths

Path N — native AKS Workload Identity (IaC ready)

Pod SA → federated Entra identity → Azure RBAC → Key Vault / Blob
(+ later: SPIRE X.509 SVID for east-west mTLS)

Best for pods that stay on AKS and only need Azure APIs. Wired in deployment/azure/terraform/modules/workload_identity.

Path F — SPIRE JWT → Entra federation (design)

SPIRE JWT-SVID (aud = api://AzureADTokenExchange)
  → Entra federated identity credential (issuer = SPIRE OIDC, subject = exact SPIFFE ID)
  → Access token → Azure SDK (ClientAssertionCredential)

Best when the same SPIFFE ID must work off-cluster (CI, multi-cloud CCR) or you want one portable identity mapped into Entra.

flowchart TB
  subgraph Humans["Plane A"]
    EntraH[Entra SSO]
  end
  subgraph Peers["Plane C — SPIFFE"]
    SPIRE[SPIRE Server]
    Backend[Backend]
    Trainer[Trainer Job]
    CCR[CCR / confidential]
    SPIRE --> Backend
    SPIRE --> Trainer
    SPIRE --> CCR
    Backend <-->|mTLS X.509 SVID| Trainer
    Trainer <-->|mTLS| CCR
  end
  subgraph AzureAPIs["Plane B — Azure"]
    KV[Key Vault]
    Blob[Blob]
    PathN[AKS Workload Identity]
    PathF[Entra WIF via JWT-SVID]
    PathN --> KV
    PathN --> Blob
    PathF --> KV
    PathF --> Blob
  end
  EntraH --> Backend
  Backend --> PathN
  Trainer --> PathN
  CCR --> PathF

3. SPIFFE IDs for CAN on Azure

Trust domain example: spiffe://can.{env}.azure.example

Prod rule: Entra federated credential subject = exact SPIFFE ID — no wildcards.

4. What ships when

Local Docker still has no hardware SPIRE story. Azure pilot can claim Path N short-lived cloud access without claiming a full SPIFFE mesh.

5. Takeaways

1. Entra for people; SPIFFE for peers; AKS WI / Entra WIF for Azure APIs.
2. Prefer Path N on AKS (now in TF); use Path F for portable / off-cluster SPIFFE.
3. Exact SPIFFE subjects on federated credentials.
4. Pair with Attestation + SKR for DEK/MEK — SPIFFE alone is not a clean-room.
5. Apply with Azure Terraform README; optional SPIRE via Helm after enable_spire=true.

One sentence: On Azure, CAN’s Zero Trust plan is SPIRE for east-west identity and either AKS Workload Identity or SPIFFE→Entra token exchange for northbound cloud APIs—never long-lived keys in the training pod.

Narrative: Entra → Ricardian contract → Key Vault / confidential compute (attest → DEK/MEK → decrypt-in-memory → train) → provenance → deploy/predict under Open-GMASE, with CompliancePulse on the decision path. Design/pilot slides are labeled as such in the deck.

DEPA context: depa.world.

Companion: TEE execution — attest, verify contract, then decrypt · Azure confidential computing (SKR / Key Vault) · Lifecycle source of truth: Participant onboarding & E2E · Product loop: Contract to governed prediction

Status: Architecture and partial implementation. Local demos often train on staged artifacts without a hardware TEE. CAN/JCS Phase 1 uses key-release signals (no key bytes to the Node API). Attested TLS delivery of DEK/MEK into the enclave is the Phase 2 target.

1. Why KMS matters in CAN

CAN is inspired by iSPIRT’s DEPA (Data Empowerment and Protection Architecture): use-bound, accountable sharing—not a central data lake. Cryptographically that means:

1. The platform must not hold principal-owned dataset or model keys in plaintext.
2. Ciphertext may live in object storage or the catalog path; plaintext exists only inside an attested clean room for a bounded job window.
3. Training starts only when both data and model keys are released under contract + attestation policy (dual-key escrow).

Without that discipline, “confidential training” collapses to “trust the operator’s disk.”

2. Two principal-owned keys

flowchart TB
  TDP["TDP"]
  TDC["TDC"]
  Store["Object storage / catalog<br/>ciphertext only"]
  Escrow["CAN / JCS escrow<br/>release signals"]
  TEE["CCR / TEE<br/>plaintext window"]

  TDP -->|"encrypt with DEK"| Store
  TDC -->|"encrypt with MEK"| Store
  TDP -.->|"DEK release if policy OK"| Escrow
  TDC -.->|"MEK release if policy OK"| Escrow
  Escrow -->|"both ready"| TEE
  Store -->|"pull ciphertext"| TEE

Rule of thumb: DEK and MEK are not the same as cloud “customer managed keys” for disk encryption of the portal database. Those are infrastructure. DEK/MEK are workload secrets for the training job, owned by parties to the Ricardian contract.

3. What “KMS” means in this stack

CAN talks to key services at two layers:

Wizard fields such as kmsConfigs on contracts capture which provider / region / key id the parties expect for the clean-room path. The CCRP / TSP offering must be able to run in an environment that can use those keys under IAM and attestation policy.

Deep design notes in-repo:

• KMS_TRAINING_ENVIRONMENT_ARCHITECTURE.md
• MULTI_TENANT_KMS_ARCHITECTURE.md
• DECENTRALIZED_KMS_ARCHITECTURE.md

4. Dual-key escrow (the gate before train)

Target sequence:

1. Contract is SIGNED (all required parties).
2. CCRP provisions a clean-room session (TEE / confidential VM / attested K8s job).
3. Job enters escrow: waiting for DEK released and MEK released.
4. Each principal releases only after verifying attestation + contract binding (see TEE post).
5. When both signals (and, in Phase 2, key material into the TEE) are present → training may start.
6. Hard timeout → session EXPIRED / CCR DESTROYED; keys must be zeroized in a real enclave.

Phase 1 MVP: principals post key-released signals with keyType: DEK|MEK. The API rejects raw key bytes to the Node process. Coordinates release without accepting key material into the Node API.

# Illustrative — see CAN_QUICKSTART in the repo
POST /api/can/jcs/jobs
POST /api/can/jcs/jobs/{id}/attestation   # bundle (simulated today)
POST /api/can/jcs/jobs/{id}/key-released  # keyType: DEK
POST /api/can/jcs/jobs/{id}/key-released  # keyType: MEK
# → release → CCR executor may start

5. Encryption modes (maturity)

For stakeholder demos of contracts → train → infer, the local Docker path is the right story. For keys and clean rooms, see KMS / DEK·MEK and TEE attest → decrypt.

6. What auditors should ask

7. Takeaways

1. DEK ≠ MEK — data principal and model owner keep separate custody.
2. Dual-key escrow is the economic and cryptographic AND-gate before train.
3. Cloud KMS wraps infrastructure and customer keys; CAN/JCS orchestrates release against the Ricardian contract.
4. Local demos cover product UX; attested key delivery into TEE is the clean-room target.

Next: TEE execution — attestation, contract check, decrypt-in-memory.

Companion: KMS — DEK, MEK, and dual-key escrow · Azure confidential computing deep dive · Flows: TDP encrypted dataset · TDC encrypted model · iSPIRT DEPA: depa.world

Status: Target for CCRP / confidential-compute paths (Azure confidential computing, OCI confidential VMs, etc.). Local Docker / native training is a host path. CAN/JCS uses simulated attestation bundles and key-release signals; attested TLS / SKR key delivery is Phase 2+.

1. Decrypt gate

Requirement: Can the clean-room operator, or the SaaS, read our data and model?

Control: a decrypt gate with two locks:

1. Hardware attestation — the enclave proves its measurement / identity (CPU/firmware/image claims the cloud vendor supports).
2. Contract verification — the Ricardian agreement names allowed regions, TEE requirements, parties, and use; keys release only for that job/session.

Only then may DEK (dataset) and MEK (model) enter the TEE so ciphertext can be decrypted in memory, training can run, outputs can be re-encrypted, and keys zeroized when the session ends.

That is DEPA-shaped thinking for enterprises: use-bound access with evidence, not bulk export into a lake.

2. End-to-end sequence (target)

sequenceDiagram
  participant TDP
  participant TDC
  participant CAN as CAN / Contract
  participant CCRP as CCRP / TSP
  participant TEE as TEE / CCR
  participant Store as Ciphertext store

  TDP->>Store: Upload encrypted dataset
  TDC->>Store: Upload encrypted model
  TDP->>CAN: Sign Ricardian contract
  TDC->>CAN: Sign
  CCRP->>CAN: Sign / accept offering
  CAN->>CCRP: Job for SIGNED contract
  CCRP->>TEE: Provision enclave / confidential VM
  TEE->>TEE: Ephemeral keypair + attestation quote
  TEE->>TDP: Attestation bundle
  TEE->>TDC: Attestation bundle
  TDP->>TDP: Verify attestation + contract binding
  TDC->>TDC: Verify attestation + contract binding
  TDP->>TEE: DEK over attested channel
  TDC->>TEE: MEK over attested channel
  Store->>TEE: Pull ciphertext
  TEE->>TEE: Decrypt in memory → train
  TEE->>TEE: Re-encrypt outputs · zeroize keys · destroy
  TEE->>CAN: Provenance / job events

Same idea in one block (from the lifecycle guide):

CCRP provisions TEE
  → TEE generates ephemeral TLS keypair + attestation
  → Principals verify attestation independently
  → CCR pulls encrypted dataset + encrypted base model
  → TDP delivers DEK over attested TLS into TEE
  → TDC delivers MEK over attested TLS into TEE
  → Decrypt in memory → train → re-encrypt outputs
  → Zeroize keys → destroy CCR session
  → Emit provenance (created, attested, keys released, started, completed, destroyed)

3. What “hardware attestation” means here

SPIFFE/SPIRE (workload identity for agents and pods) complements TEE attestation; it does not replace it for DEK/MEK release. See Three identity planes.

4. What “contract verification” means here

Before a principal releases DEK or MEK, the contract (and job binding) should establish at least:

Open-GMASE can still deny start_training even if keys are present—policy on the side effect is a separate fail-closed gate (demo slice). TEE answers where plaintext may exist; OPA answers whether the job may start.

5. Dataset path vs model path

TDP — encrypted dataset (DEK)

1. TDP encrypts locally (target) → uploads ciphertext + metadata (tee_only, key id references).
2. Contract requires TEE + attestation.
3. After attestation + contract OK → DEK into TEE → decrypt dataset in memory.

TDC — encrypted base model (MEK)

1. TDC encrypts model IP locally (target) → uploads ciphertext.
2. Same clean-room session pulls model ciphertext.
3. After attestation + contract OK → MEK into TEE → decrypt model in memory → train with dataset.

Symmetric stories; both keys required. Details: TDP flow · TDC flow.

6. Live today vs target

Local product-tour screenshots show the runnable loop. Azure confidential VMs + Key Vault / SKR are the cloud target—see Azure confidential computing deep dive. Host training and TEE paths are distinct.

7. Provenance events (evidence)

A clean-room job should leave a trail such as:

• Job created (bound to contractId)
• Attestation presented / verified
• DEK released · MEK released
• Training started / completed (or failed)
• Session destroyed / keys zeroized

Ledger-backed claims (SCITT CCF) and CAN AuditLogs / CompliancePulse ingest sit beside this for GRC. The cryptographic story only works if destroy is real when escrow expires.

8. Takeaways

1. Decrypt is a privilege, not a default—gated by attestation ∧ contract ∧ dual-key escrow.
2. Plaintext stays in the TEE for the job window; storage holds ciphertext.
3. Local demos ≠ confidential VMs—label them correctly for CISOs.
4. Pair with KMS / DEK / MEK for who owns which key, and with Open-GMASE for whether training may start at all.

One sentence: In CAN’s clean-room design, encrypted data and models are decrypted only after the enclave proves what it is and the Ricardian contract proves that enclave is allowed to train.

Related: Contract → governed prediction · Ricardian contracts in CAN · Product tour — Auditor · Open-GMASE · TEE attest → decrypt · In-repo: AUDITOR_ROLE.md · MERKLE_TREE_PROVENANCE_IMPLEMENTATION.md

Status: Merkle builders, proofs, and Auditor UI (/auditor/*, /api/auditor/*). Verify checks leaf inclusion under a published root. Provenance report UI and SCITT path are available. Cross-cloud Merkle replication and extended leaf types: partial. See AUDITOR_ROLE.md.

1. Why “the model misbehaved” needs cryptography

A bad prediction, a leaked feature, or a training run that used the wrong dataset creates a GRC incident. Typical evidence fails under scrutiny:

You need a structure where:

1. Every material event is hashed.
2. Hashes are aggregated so one root commits to the whole set.
3. Anyone can check a single event with a short inclusion proof against a published root (and optionally a ledger receipt).

That structure is a Merkle tree.

2. Merkle trees in one diagram

flowchart TB
  R["Root hash<br/>(commit to entire job)"]
  A["H(A∥B)"]
  B["H(C∥D)"]
  L1["leaf: dataset digest"]
  L2["leaf: contract / terms digest"]
  L3["leaf: training config"]
  L4["leaf: model artifact / decision"]

  R --> A
  R --> B
  A --> L1
  A --> L2
  B --> L3
  B --> L4

• Leaf = cryptographic hash of a provenance record (dataset chunk, config JSON, checkpoint, policy decision, …).
• Parent = hash of its children (order fixed; algorithm usually SHA-256).
• Root = single digest that commits to all leaves.
• Inclusion proof = sibling hashes along the path from leaf → root. Anyone with the root can recompute and verify the leaf was in the tree when that root was published.

Change one byte of training data or swap a config field → leaf changes → root changes. That is the audit property.

3. What CAN puts under the tree

3.1 Target design (full lifecycle)

Aligned with the provenance design and training job lifecycle:

The Merkle Tree Service aggregates nodes; PostgreSQL stores trees/nodes/proofs; SCITT CCF can hold a receipt that anchors the root (or claim) on a confidential ledger—so the root itself is harder to rewrite than an app database row alone.

Events → hash leaves → Merkle root → (optional) SCITT receipt
                ↑
     inclusion proof for one disputed event

3.2 What the Auditor UI builds today

The Auditor workspace (/auditor/dashboard → Audit tree) builds a contract-scoped tree from durable DB evidence. Each Verify click checks inclusion of one of these leaf kinds:

Not every row in the “target design” table above is a separate leaf yet (for example raw DP config or every G-MASE decision may live in AuditLogs / CompliancePulse until folded into this tree). The product-tour screens show this path: Auditor section.

4. What an Auditor actually verifies

Two different jobs—do not conflate them.

4.1 What Verify checks (cryptography)

That a leaf is included in the tree under the published root hash.

In other words: “This evidence record belongs to this committed provenance set and has not been silently dropped or swapped relative to this root.”

If the inclusion proof fails, treat it as an integrity / ops problem first—not only a model-quality problem.

4.2 What the Auditor reviews (human)

After Verify succeeds (or while investigating), they open the Ricardian contract the training was based on and ask process questions:

• Was this the agreed use, data, and environment?
• Which training job produced the disputed artifact?
• Which SCITT markers were recorded for sign / train / deploy?

Merkle trees do not make models ethical. They make denial and rewriting of history expensive. Auditors prove lineage integrity, then judge process fit to the contract—not model quality by itself.

5. Incident playbook: model misbehaves

Suppose an inference result looks wrong, unsafe, or outside the Ricardian use terms.

5.1 Freeze the claim

1. Capture model id, job id, contract id, timestamp, and the disputed output.
2. Open the Auditor audit tree for that contract (or export the proof package)—load the published Merkle root (and SCITT receipt if enabled).
3. Do not only trust the live training UI screenshot.

5.2 Verify the lineage you care about

5.3 Separate “bad model” from “bad process”

6. How this fits Open-GMASE and CompliancePulse

Together: prevent where possible (OPA), record always (audit), prove under challenge (Merkle + receipt).

7. What auditors should ask for

1. Algorithm (e.g. SHA-256) and leaf canonicalization rules (JSON field order, hashing of files).
2. Published root for the contract (Auditor audit-tree view).
3. Inclusion proof for the disputed leaf (Verify in the UI, or API POST /api/auditor/verify-proof).
4. Optional SCITT receipt verifying the root/claim.
5. Mapping from leaf → human-readable event (contract id, job id, claim id, model id).
6. The Ricardian contract record itself—terms the training was based on.

If the vendor cannot produce (3) against (2), you have a narrative, not evidence.

8. Limits

Hashing raw prompts that contain secrets into leaves can create a new leakage path—hash digests or redacted envelopes, not plaintext PII, in the published tree.

9. Takeaways

1. A Merkle root is a compact commitment to the provenance set for a contract / job.
2. Auditor Verify answers: “Is this leaf in the committed history under root R?”—integrity of lineage, not model quality.
3. After proofs succeed, review the governing Ricardian contract to separate bad process from bad model.
4. CAN pairs Merkle with SCITT, AuditLogs, and Open-GMASE so incidents separate integrity from model quality.
5. Ask for proofs under challenge—not screenshots.

One sentence: Merkle trees let CAN turn “trust our logs” into “verify this leaf against a published root”—and the Auditor role is where that check happens when a model’s behavior is under dispute.

CAN uses a Ricardian contract: legal prose plus machine-enforceable structure (datasets, params, environment, keys, signatures) so train/infer proceed only under that state.

Related: Contract → governed prediction · Contract management — signing keys & verify · Product tour · Merkle / Auditor · KMS DEK/MEK · TEE attest → decrypt · In-repo: RICARDIAN_CONTRACT_GUIDE.md

Status: Creating, previewing, multi-party signing, and SIGNED → train gates are live on the local stack. On-chain deploy and some signature crypto are demo / Phase 1 (see §8). Cloud clean-room key release remains Phase 2 in the TEE narrative.

1. What “Ricardian” means here

Ian Grigg’s Ricardian idea (simplified): one document that humans can read, machines can hash unambiguously, and signatures bind to that byte-exact artifact.

In CAN: legal prose bound to machine-enforceable structure (datasets, training params, privacy, clean-room host).

Legal prose  ──hash──►  legalDocumentHash  ──bound to──►  Contract row
     ▲                                                      │
     │                                                      ▼
Human review / signatures                         Runtime gates (train / infer)

Machine-only → opaque JSON. Legal-only → NDA. Ricardian is both.

2. The dual layer in CAN

Creation (simplified):

1. TDC runs the wizard → POST /api/contracts/ricardian.
2. Service generates legalDocument from a template (AI_TRAINING or BASIC).
3. Canonical JSON → SHA-256 → legalDocumentHash (0x…).
4. Platform records ricardianSignature over that hash (see §8).
5. Optional smart-contract address (real chain if configured; otherwise mock).
6. Persist Contract at PENDING_TDP_APPROVAL and notify linked TDPs.

Screens: product tour — contract create & sign.

3. Who the parties are

Design roots sit with iSPIRT DEPA—consent-style, multi-party sharing with identifiers (DEPA IDs) on parties, datasets, contracts, and jobs.

4. Lifecycle: from draft intent to enforced runtime

sequenceDiagram
  participant TDC
  participant CAN
  participant TDP
  participant TSP
  participant Train

  TDC->>CAN: Create Ricardian (legal + machine fields)
  CAN->>TDP: Notify PENDING_TDP_APPROVAL
  TDP->>CAN: Sign as TDP
  CAN->>TSP: Status PENDING_TSP_APPROVAL
  TSP->>CAN: Sign as TSP
  Note over CAN: status = SIGNED
  TDC->>Train: Start training (requires SIGNED)
  Train->>CAN: Jobs, provenance, optional G-MASE gates

4.1 Create (TDC)

Five-step UI (CreateRicardianContract):

1. Template
2. Details & dataset selection (1–3 datasets)
3. Environment & TSP (compute, security, KMS refs)
4. Review generated legal document
5. Submit

4.2 Sign (TDP → TSP)

• TDP signs via POST /api/contracts/:id/sign with partyType=TDP → moves toward TSP approval.
• TSP (assigned tspId) signs → status becomes SIGNED.
• Each approval appends to legalDocument.signatures[] and writes a best-effort SCITT claim (contract_approval).

Runtime note: The training gate today requires status === 'SIGNED' (reached when TSP completes). A separate tdcSigned column exists on the model; do not assume every UML “all three parties must sign” path is what the local trainer enforces. Prefer the live path above.

4.3 Train and infer

• Train: tdcTrainingExecutionService refuses jobs unless the contract is SIGNED (and env / cloud / privacy constraints are present).
• Infer: Deployed models stay tied to the training contractId; Open-GMASE can gate deploy/predict via package open_gmase/can_contracts (demo slice).

No signature → no training. That is the product claim that replaces “we emailed a Word doc.”

5. What the machine side binds

These fields are not decoration—they are what jobs and gates consume:

Wizard defaults lean secure: attestation required, encryption at rest/in transit, network isolation—even when the local trainer is Docker rather than a hardware TEE.

6. How the contract shows up in evidence

When a model misbehaves, the contract is the spine of the audit story:

Auditors do not use the Ricardian text to prove the model was “correct.” They use it to prove which agreement governed the run, then Verify Merkle inclusion for that trail.

7. Why this is better than “PDF + NDA”

That is the DEPA-shaped idea applied to AI training: use is licensed by agreement, not by whoever has a copy of the CSV.

8. Phase 1 limits

9. Takeaways

1. A Ricardian contract in CAN is legal prose plus hashed binding plus machine fields the runtime enforces.
2. Lifecycle: create → TDP sign → TSP sign → SIGNED → train/infer.
3. Machine bindings (datasets, trainingParams, environmentSpecs, kmsConfigs, cloud) are first-class—not footnotes.
4. Provenance, Merkle, SCITT, and Open-GMASE all hang off the same contract id.
5. Ask vendors for the hash, the signature trail, and the SIGNED gate—not a PDF alone.

One sentence: CAN’s Ricardian contract is how multi-party AI collaboration becomes enforceable state instead of an email attachment—readable by people, hashed for integrity, and checked before training runs.