Verify a Response

Use a native ACI client when verification affects whether a request may proceed. curl and jq can inspect artifacts, but they do not verify a TDX quote, TLS SPKI binding, receipt signature, or exact stream bytes by themselves. Pi and OpenCode perform these checks automatically. The example below shows the same flow in a Node or Bun application.

Run a verified request

npm install @phala/aci-verifier
export REDPILL_AI_API_KEY="your-redpill-api-key"

import { connectAci } from "@phala/aci-verifier/runtime";

const apiKey = process.env.REDPILL_AI_API_KEY;
if (!apiKey) throw new Error("REDPILL_AI_API_KEY is required");

const aci = await connectAci({
  baseURL: "https://tee.redpill.ai/v1",
  policy: { requireProductionOs: true },
  serving: { requireVerified: true, requireReceipt: true },
});

try {
  const response = await aci.fetch(`${aci.baseURL}/chat/completions`, {
    method: "POST",
    headers: {
      Authorization: `Bearer ${apiKey}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      model: "z-ai/glm-5.2",
      messages: [{ role: "user", content: "Explain attestation briefly." }],
    }),
  });

  if (!response.ok) {
    throw new Error(`RedPill request failed with status ${response.status}`);
  }
  const body = await response.json();

  const audit = await aci.verifyReceipt();
  if (!audit.transcript.verdict.verified) {
    throw new Error(audit.transcript.verdict.line);
  }

  console.log(audit.transcript.verdict.line);
  console.log(body);
} finally {
  await aci.close();
}

connectAci() verifies the attestation before sending model traffic and pins TLS to a key in the attested workload keyset. It records the exact request and response wire digests. verifyReceipt() fetches the matching signed receipt, verifies those digests, and verifies the cited upstream session.

Release policy

The measured compose hash and the report’s source labels are different:

Value	Meaning
`sha256(app_compose)`	Bound into RTMR3 and suitable for a reviewed-release allowlist
`source_provenance.repo_url` and `repo_commit`	Workload-declared labels, useful for inspection but not a trust anchor

Without acceptedComposeHashes, the client verifies that the measured compose ran in a genuine TDX workload. It does not claim that RedPill reviewed that release. For reviewed-release enforcement, load accepted hashes from authenticated release metadata:

const aci = await connectAci({
  baseURL: "https://tee.redpill.ai/v1",
  policy: {
    requireProductionOs: true,
    acceptedComposeHashes: ["<reviewed-compose-sha256>"],
  },
});

Never copy a compose hash from the endpoint and trust it on first use.

What a passing audit proves

the TDX quote binds the fresh challenge, workload keyset, and measured compose;
the model request used hostname-validated TLS bound to an attested SPKI;
the signed receipt binds the exact request and response bytes to that workload; and
a required confidential upstream was verified and its cited session is valid.

It does not prove that a release was reviewed unless an independently obtained compose allowlist was enforced.

Core

Privacy

Migration

Tools & apps

SDKs & frameworks

Run a verified request

Release policy

What a passing audit proves

Coding agents

Attestation report

Receipts

Attested sessions

​Run a verified request

​Release policy

​What a passing audit proves

​Related

Coding agents

Attestation report

Receipts

Attested sessions

Run a verified request

Release policy

What a passing audit proves

Related