ACIRead the protocol spec

How it works

Three proof layers: the model runtime, the provider, and the gateway. Each one is attested, and every response carries a receipt you can verify without trusting RedPill.

Start buildingVerify a response

Real end-to-end private AI means every privacy boundary has proof.

1. GPU TEE Model Runtime

The model path must run in confidential GPU infrastructure, such as NVIDIA Confidential Compute behind a CPU TEE.

2. Model Host Proof

The provider must expose attestation that binds the live workload to a TLS SPKI or E2EE public key the gateway can enforce.

3. Gateway Proof

The RedPill gateway publishes its own attestation report, keyset, signed receipts, and attested upstream sessions.

From the Private AI Gateway code: a provider is never accepted as verified without an enforceable channel binding. If the selected backend cannot enforce that binding on the actual request path, forwarding fails closed.

Follow one request

Four curl requests take you from the gateway's attestation to the verified session behind a single response.

  1. 1
    Check the gateway

    Fetch the current TEE evidence and check that the keyset has not expired.

    curl -fsS "https://tee.redpill.ai/v1/aci/attestation" \
  -H "Authorization: Bearer $REDPILL_API_KEY"

    Output

    {
  "api_version": "aci/1",
  "workload_keyset_digest": "sha256:4f3dc45e...",
  "attestation": { "workload_keyset": { "not_after": 1790498751, ... }, ... },
  ...
}
  2. 2
    Send a private request

    The response header contains the receipt ID, not the receipt itself.

    curl -fsS -i "https://tee.redpill.ai/v1/chat/completions" \
  -H "Authorization: Bearer $REDPILL_API_KEY" --json '{"model":"openai/gpt-oss-120b","messages":[{"role":"user","content":"Hello"}],"provider":{"aci_verified":true}}'

    Output

    HTTP/2 200
x-receipt-id: rcpt-e0eefe63b3673e2a5984951f
...

{
  "model": "openai/gpt-oss-120b",
  ...
}
  3. 3
    Inspect the receipt

    Paste the x-receipt-id above and compare its keyset digest with step 1.

    curl -fsS "https://tee.redpill.ai/v1/aci/receipts/REPLACE_WITH_RECEIPT_ID" \
  -H "Authorization: Bearer $REDPILL_API_KEY"

    Output

    {
  "api_version": "aci/1",
  "receipt_id": "rcpt-e0eefe63b3673e2a5984951f",
  "workload_keyset_digest": "sha256:4f3dc45e...",
  "event_log": [
    ...,
    { "type": "upstream.verified", "session_id": "63c5a08de14e5c5253e6fb29271151f40621beb83b552ccca65772772856053f", "result": "verified", "required": true },
    { "type": "response.returned", "body_hash": "sha256:..." }
  ],
  ...
}
  4. 4
    Inspect the session

    Copy session_id from the upstream.verified event above, then fetch that session.

    curl -fsS "https://tee.redpill.ai/v1/aci/sessions/PASTE_SESSION_ID_FROM_RECEIPT" \
  -H "Authorization: Bearer $REDPILL_API_KEY"

    Output

    {
  "api_version": "aci/1",
  "upstream_name": "...",
  "verifier_id": "...",
  "claims": { "tee_attested": { "status": "asserted", ... }, ... },
  ...
}
Full cryptographic verification guide

Who we verify

The gateway repo audits each provider against the same bar: workload identity, enforceable channel binding, privacy boundary, runtime policy, receipts, and attested sessions.

Tinfoil

Confidential router

Acceptable with conditions

TEE proof

AMD SEV-SNP or TDX plus NVIDIA CC; official Tinfoil SDK checks Sigstore provenance, hardware quote, measurement, TCB, and TLS key binding.

Binding

tls_spki_sha256

What RedPill adds

Pins the verified router channel before forwarding and records the provider verification in receipts and attested sessions.

NEAR AI

Verified gateway channel

Acceptable with conditions

TEE proof

Intel TDX plus NVIDIA CC; gateway attestation binds nonce, signing address, and TLS SPKI. Nested model attestations are delegated to the verified gateway.

Binding

tls_spki_sha256

What RedPill adds

Treats catalog flags as advisory, verifies the gateway channel, and records served model identity honestly at receipt level.

Chutes

Direct E2EE model instance

Accepted for limited E2EE traffic

TEE proof

Intel TDX plus NVIDIA CC; DCAP quote binds nonce and E2EE public key, then NVIDIA NRAS evidence is nonce-checked.

Binding

e2ee_public_key_sha256

What RedPill adds

Encrypts each request to a verified instance key and fails closed when no verified nonce/key session is available.

SecretAI

Direct SecretVM origin

Acceptable with conditions

TEE proof

SEV-SNP or TDX plus NVIDIA CC; CPU quote binds inference TLS SPKI, GPU nonce, measured SecretVM workload, and optional workload ID pin.

Binding

tls_spki_sha256

What RedPill adds

Normalizes SecretVM evidence into the same lease, binding, receipt, and session model used by other providers.

PhalaDirect

Direct dstack model endpoint

Sound binding, strict pins pending

TEE proof

Intel TDX plus NVIDIA CC through Phala dstack; version-2 report binds nonce, signing address, compose hash, and custom-domain TLS SPKI.

Binding

tls_spki_sha256

What RedPill adds

Derives the TLS pin from the verified report instead of static config, then enforces it before sending the prompt.

ACI service

First-party ACI-compatible server

First-party reference path

TEE proof

Intel TDX plus NVIDIA CC using the same `/v1/attestation/report` surface and ACI session semantics.

Binding

tls_spki_sha256

What RedPill adds

Uses the native ACI evidence shape directly, so clients get the cleanest gateway, receipt, and session verification path.

This is why RedPill can be more than a TEE model catalog: it aggregates different confidential-compute providers into one OpenAI-compatible API, but keeps the security bar uniform and auditable for every routed request.

Honest Privacy Means Clear Proof Boundaries

RedPill is strongest where it can verify both sides of the private inference path: the model host and the gateway that routes to it.

Normal API Compatibility

Use the same OpenAI-compatible request path while RedPill handles provider verification, route selection, and receipt issuance.

Independent Verification

A relying party checks the gateway report, upstream event, enforceable binding, receipt signature, and response hash.

Optional ACI E2EE

Selected request and response fields can be encrypted to keys from the attested gateway keyset when TLS alone is not enough.

What We Do Not Hide

RedPill only treats an upstream as private when its adapter verifies provider identity and enforces channel binding.

Optional middleware sees plaintext after gateway decryption and must be inside the same attested deployment and audit boundary.

Receipts are implemented with configurable TTL, but durable public transparency logging is not implemented yet.

Policy-Only AI vs Verifiable Private AI

Privacy policies are useful. Receipts, channel bindings, and audit sessions are testable.

Standard AI API

Plain hosted inference

Privacy-Policy AI

Promise-based privacy

RedPill

Private AI evidence

Encrypted Channel Binding
No
TLS only
TLS-SPKI or E2EE key in the attested keyset
Upstream Verification
No
Not provable
Provider identity verified before forwarding
Attestation Report
No
No public endpoint
/v1/attestation/report
Signed Receipt
No
No
x-receipt-id + /v1/aci/receipts/{id}
Attested Session
No
No
/v1/aci/sessions/{session_id}
Open Source
Closed
Usually closed
Gateway + evidence verifier
Verify It Yourself

Open source where it matters

The gateway, the verifier, and the protocol are public, so the proof does not depend on trusting RedPill.

redpill-gateway

Gateway source and deployment

@phala/aci-verifier

Run verification yourself

ACI draft spec

The open protocol

redpill-chat

Private chat UX

developer docs

Guides and API reference

Start building in 1 minute

Create a key, point your OpenAI SDK at the Gateway, and send your first private request.

Start building

Search

Search models and pages.