# Confidential Execution (Protocol 1.3.1)

URL: https://docs.nexart.io/docs/confidential-mode

Node-side commitment envelopes for input and output under Protocol 1.3.1. Raw plaintext is excluded from the certified snapshot and proof_json.

## Summary

Protocol 1.3.1 introduces commitment-based confidentiality, replacing the hash-bound omission model used in 1.2.0.

## Overview

In protocol `1.3.1` the client transmits raw execution data to the attestation node over TLS during certification. The node processes it transiently to convert the sensitive fields into commitment envelopes before building the CER.

- Raw `input` and `output` are transmitted to the node over TLS during certification.
- The node seals them into commitment envelopes using `sealConfidential` (HMAC-SHA256).
- Per-field salts are derived deterministically inside the node and are not exposed.
- On the node, raw `input` and `output` are:- processed transiently for the sole purpose of sealing,
- excluded from the certified snapshot,
- excluded from `proof_json`,
- not intentionally persisted by the certification flow.
- The resulting CER contains only commitments and hashes.
- Verification operates on commitments, not plaintext.

Scope of the guarantee. Raw `input`/`output` MUST cross TLS to the node in order to be sealed, so this flow does not claim they never leave the customer environment. The documented guarantee is scoped to the certification path: raw values are excluded from the certified snapshot and from `proof_json`, and the flow is designed not to persist them. A blanket claim of absence from all logs, traces, crash reports, caches, and backups is not asserted here.

## Commitment Envelope

Each committed field is replaced in the snapshot by an envelope:

Commitment envelope

```
{
  "_redacted": true,
  "scheme": "hmac-sha256-v1",
  "commitment": "sha256:<hex>"
}
```

- Scheme: `hmac-sha256-v1`.
- Computation: `commitment = HMAC_SHA256(salt, value)`.
- Properties: not reversible, not guessable without the salt, deterministic for a given `(salt, value)` pair.

## Certification Flow (1.3.1)

For `protocolVersion: "1.3.1"`:

Client sends:

- `prompt`
- `input` (raw)
- `output` (raw)
- `parameters` (full object)

Node:

- seals `input` and `output` into commitment envelopes,
- derives deterministic per-field salts internally,
- builds the CER snapshot with the envelopes in place of plaintext,
- computes `certificateHash`, signs the receipt, and returns the attested bundle.

The client MUST NOT pre-hash or pre-redact `input`/`output` for 1.3.1. Sealing is performed exclusively by the node. The hash-bound omission pattern from 1.2.0 is no longer the confidentiality model.

## Request Example

POST /v1/cer/ai/certify - protocolVersion 1.3.1

```
{
  "executionId": "exec_123",
  "provider": "openai",
  "model": "gpt-4o",
  "prompt": "You are a financial analyst.",
  "input": "Summarize the risks.",
  "output": "Revenue decline...",
  "parameters": {
    "temperature": 0,
    "maxTokens": 1024,
    "topP": 1,
    "seed": null
  },
  "protocolVersion": "1.3.1",
  "appId": "example-app"
}
```

## Resulting Snapshot (excerpt)

Certified CER snapshot - input/output replaced by commitments

```
{
  "prompt": "You are a financial analyst.",
  "parameters": { "temperature": 0, "maxTokens": 1024, "topP": 1, "seed": null },
  "input": {
    "_redacted": true,
    "scheme": "hmac-sha256-v1",
    "commitment": "sha256:b1c4...e9f2"
  },
  "output": {
    "_redacted": true,
    "scheme": "hmac-sha256-v1",
    "commitment": "sha256:7a02...41dc"
  }
}
```

## Verification

- Authenticity (default). Confirms bundle integrity, receipt signature, and envelope. No plaintext is required and none is disclosed.
- Equality (optional). A party that independently holds the original plaintext can recompute the commitment and compare it to the value in the snapshot. The node does not perform this check and does not retain the data required to perform it.

## Protocol Version Matrix

| protocolVersion | Canonicalization | Confidentiality model |
| --- | --- | --- |
| 1.2.0 | nexart-v1 (default) | Hash-bound omission (legacy). |
| 1.3.0 | jcs-v1 (RFC 8785) - transitional | Plaintext snapshot. No node-side sealing. |
| 1.3.1 | jcs-v1 (RFC 8785) | Node-side commitment envelopes for input and output. |

## Security Model

Confidential mode guarantees:

- The certified record and `proof_json` contain only commitments for `input` and `output`.
- The certification flow is designed not to persist raw `input`/`output`.
- Third parties cannot reconstruct plaintext from commitments alone.

It does NOT guarantee:

- Confidentiality of non-committed fields. `prompt` and `parameters` remain plaintext in the snapshot.
- Protection against parties who already hold the plaintext. Equality verification is by design available to them.
- Transport confidentiality beyond TLS to the node.

## Best Practices

- Only place genuinely sensitive content in `input`/`output`.
- Avoid embedding secrets in `prompt` or `parameters`; they are not committed.
- If your audit workflow requires equality verification, retain the original plaintext in your own system of record. The node does not.
- Do not log raw `input`/`output` alongside the resulting `certificateHash` unless your retention policy permits it.