Verify a response

Using https://tee.redpill.ai forces confidential routing, but a base URL alone does not verify the TEE from your machine. A verified client checks the workload attestation before sending model traffic, binds TLS to a key in the attested keyset, and verifies the signed receipt for the exact request and response bytes. curl and jq can inspect the artifacts; they cannot perform these checks.

Client	Verification
Pi	Built in, through `pi-provider-redpill`
OpenCode	Built in, through `opencode-provider-redpill`
Node or Bun application	`connectAci()` from `@phala/aci-verifier`, below
Claude Code, Codex CLI, Cline, and other base-URL-only tools	None; they cannot inject the pinned transport

Agent tools, MCP servers, browser automation, and telemetry remain separate trust boundaries.

Node and Bun

npm install @phala/aci-verifier openai

Node 20.18+ and Bun 1.4+ share the same API; the /runtime export selects the pinned transport.

import OpenAI from "openai";
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 client = new OpenAI({ apiKey, baseURL: aci.baseURL, fetch: aci.fetch });
  const response = await client.responses.create({
    model: "z-ai/glm-5.2",
    input: "Reply with exactly: verified",
  });

  const audit = await aci.verifyReceipt();
  if (!audit.transcript.verdict.verified) {
    throw new Error(audit.transcript.verdict.line);
  }
  console.log(response.output_text);
} finally {
  await aci.close();
}

connectAci() verifies the attestation before sending model traffic and pins TLS to a key in the attested workload keyset. Pass aci.fetch only to the client that uses this gateway; it records the exact request and response wire digests. verifyReceipt() fetches the matching signed receipt, verifies those digests, and verifies the cited upstream session. Audit a response before treating its serving path as verified.

Release policy

requireProductionOs rejects development and unknown OS measurements. Without acceptedComposeHashes, the client verifies that the measured compose ran in a genuine TDX workload; it does not claim that RedPill reviewed that release.

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

For reviewed-release enforcement, load accepted hashes from authenticated release metadata and pair compose appraisal with a dstack verifier result for the same quote (is_valid: true). Never copy a compose hash from the endpoint and trust it on first use.

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

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.

Get started

Use in agents

Build with the API

Features

How it works

Verify and control

Providers and trust

RedPill Chat

Node and Bun

Release policy

What a passing audit proves

Attestation report

Receipts

Attested sessions

ACI verifier source

​Node and Bun

​Release policy

​What a passing audit proves

​Related

Attestation report

Receipts

Attested sessions

ACI verifier source

Node and Bun

Release policy

What a passing audit proves

Related