Confidential Execution (Protocol 1.3.1)

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:

{
  "_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

{
  "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)

{
  "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

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.