log inget an API key
//01  Security

How SayGM keeps your prompts private.

Every request to SayGM passes through a gateway sealed inside an Intel TDX trusted execution environment. This page explains what that seal covers, how it extends to each model tier, how to check it for yourself, and what SayGM records.

Your request is decrypted inside the enclave. Operators and the host sit outside the seal.
[02] The sealed gateway

A gateway sealed by the chip.

A trusted execution environment (TEE) is a sealed region of a processor. Code inside it runs isolated from everything else on the machine, including its operating system, its hypervisor and the people who operate it.

The SayGM gateway runs inside one. API requests through the OpenAI, Anthropic and Gemini-compatible endpoints are decrypted and handled inside that enclave. Guardrails and routing run there too. SayGM’s operators and the host machine sit outside the seal, so your prompt and the model’s reply stay sealed from them while the gateway handles them.

Everything around the enclave sits outside the seal.

  • Intel TDX

    The gateway runs in a confidential VM, isolated by the processor from the host it runs on.

  • Phala dstack

    The confidential VM runs on Phala Cloud with dstack, which measures the code it boots.

  • TLS ends inside

    HTTPS for api.saygm.com terminates inside the enclave, so your request is decrypted there.

[03] Two routes

One sealed gateway, two tiers of model.

Frontier models

Sealed on the way to the model.

Claude, GPT and Gemini run on hardware their provider controls — the model maker or a cloud host — under that provider’s API terms. Your request reaches it through the SayGM gateway, which runs sealed inside a TEE, so it stays sealed from SayGM and the host machine until it reaches that provider.

YouSayGM routerModel
Confidential models

Your prompt stays inside the enclave, end to end.

Open-weight models served inside a TEE, so your prompt is decrypted only within the enclave that runs the model. They carry a -tee suffix on their model id: sealed from request to response.

YouSayGM routerModel

GET /v1/models labels every model with a tier of frontier, confidential or open, and names the upstream service in gateway_provider, so your code can check the route before a request goes out. Open-weight models in the open tier take the frontier route: sealed through the gateway, then served by the named provider under its terms. The privacy model docs cover each tier.

GET /v1/modelsexcerpt
{ "id": "claude-sonnet-5", "tier": "frontier",
  "gateway_provider": "anthropic" }{ "id": "kimi-k3", "tier": "open",
  "gateway_provider": "moonshot" }{ "id": "kimi-k3-tee", "tier": "confidential",
  "gateway_provider": "moonshot" }
[04] Attestation

Check it yourself.

When the gateway boots, dstack records measurements of the OS image and the exact container configuration into the TDX hardware. On request, the hardware produces a quote: those measurements, signed with keys rooted in Intel.

A valid quote shows the gateway is running on genuine Intel TDX hardware, which OS image and container configuration it is running, and that its identity key belongs to that workload. On frontier routes, what the provider does after the gateway hands over the request is set by that provider’s terms. The attestation docs cover the trust model.

  1. Step 1

    See the live check

    A verifier outside the gateway checks it for you.

    SayGM’s registry, a verifier outside the gateway, requests fresh evidence with its own nonce and checks:

    • 1Quote signature
    • 2TCB status
    • 3OS measurements
    • 4Gateway identity

    The homepage attestation panel shows the result and when it was last checked.

  2. Step 2

    Ask the gateway directly

    Ask the gateway for fresh proof. No API key needed.

    32 random bytes of your own · no key needed
    NONCE=$(openssl rand -base64 32)curl -sG https://api.saygm.com/attestation/info --data-urlencode "nonce=$NONCE" -o attestation.json
    What comes back
    quote
    The TDX quote
    event_log
    Its event log
    vm_config
    VM configuration
    gateway_pubkey
    The gateway's public key
    Check the binding

    report_data = SHA‑512(gateway_pubkey ‖ nonce)

    A match shows the quote was made for your nonce and names this key; step 3 checks Intel’s signature on it.

    Both lines print the same value
    (jq -r .gateway_pubkey attestation.json | openssl base64 -d -A; printf %s "$NONCE" | openssl base64 -d -A) | openssl dgst -sha512 -binary | openssl base64 -Ajq -r .report_data attestation.json
    Live check · in your browser

    Generate a nonce here, fetch fresh evidence, and recompute report_data.

  3. Step 3

    Verify the quote

    Check Intel's signature and read the measurements yourself.

    Split the response for the verifier
    jq -r .quote attestation.json | openssl base64 -d -A | xxd -p | tr -d "\n" > quote.hexjq -r .event_log attestation.json > event_log.jsonjq -r .vm_config attestation.json > vm_config.json

    Run the quote, event log and VM configuration through a TDX verifier, such as the dstack verifier in Phala’s platform verification guide, to confirm Intel’s signature and read out the measurements yourself.

[05] Guardrails

Redact before it leaves the enclave.

  • Personal data (PII)
  • Secrets and credentials
  • Your own regular expressions
  • Blocked words and topics

Guardrails are scanners you switch on per API key. They run inside the gateway’s enclave, on the request, before it is sent to the model. Matches are swapped for placeholders, and the originals stay inside the enclave for the life of the request.

Redactions that can round-trip, such as personal data, are put back into the reply inside the enclave, streamed responses included, so your application reads the real values. Blocked words and topics can stop a request instead.

  1. 1 · Your app

    Sends the real values

    Draft a reply to [email protected] and add her number, (415) 555-0132.

  2. 2 · Sealed gateway

    Swapped out

    Draft a reply to [REDACTED_EMAIL_1_a41f09c2] and add her number, [REDACTED_PHONE_1_d83b5e17].

    Vault · this request only
  3. 3 · Model

    Model sees placeholders

    Receives

    Draft a reply to [REDACTED_EMAIL_1_a41f09c2] and add her number, [REDACTED_PHONE_1_d83b5e17].

    Replies

    To: [REDACTED_EMAIL_1_a41f09c2]. Thanks for getting in touch. I'll call you on [REDACTED_PHONE_1_d83b5e17] this afternoon.

    Outside the enclave
  4. 4 · Sealed gateway

    Swapped back, streams included

    To: [REDACTED_EMAIL_1_a41f09c2]. Thanks for getting in touch. I'll call you on [REDACTED_PHONE_1_d83b5e17] this afternoon.

    Vault · this request only
  5. 5 · Your app

    Gets the real values

    To: [email protected]. Thanks for getting in touch. I'll call you on (415) 555-0132 this afternoon.

Scanners match the patterns they describe, which makes them one layer of protection. For data that must stay sealed end to end, pick a confidential model.

Guardrails docs ↗Set up guardrails →

[06] What gets recorded

Metadata for billing, content for nobody.

The gateway writes a matching pair of records for each serving attempt, sharing the request id. Every record below holds metadata only; prompts, completions and provider-supplied error text stay out of all of them. Guardrail activity is logged as counts per scanner, such as how many email addresses or API keys it caught.

Settlement record

Published
Example values
{
"request_id": "01K5Z3Q8V2M7R4T9B6N1C0XJ5H","timestamp": "2026-09-25T09:14:03Z","gateway_id": "gw-mainnet-2","product": { "provider": "anthropic", "model": "claude-sonnet-5" },"usage": { "input_tokens": 1843, "output_tokens": 412 },"effective_price_ndollars": { … },"success": true}
Not in this record
  • prompt
  • completion
  • account
  • api_key
  • ip_address

Pays the provider that served the request and keeps the network’s accounting checkable. It holds a gateway id, the provider and model that served it, token counts, price, a timestamp and whether it succeeded, with no account, key or IP address. Each settlement period’s records are published as public data, so anyone can check the accounting.

Diagnostic record

Kept 30 days
  • Latency
  • Retry count
  • Error class
  • Guardrail counts

Kept for 30 days in storage SayGM controls, for support and debugging. It holds latency, retry counts, an error class and guardrail counts.

Usage and billing

Per key
  • Requests
  • Tokens
  • Errors
  • By provider and model

Per API key and billing period: request counts, tokens consumed and error counts, broken down by provider and model.

The privacy policy is the full legal account, including retention.

[07] Questions

Common security questions.

Who can read my prompt on SayGM?

The SayGM gateway decrypts and handles your request inside an Intel TDX enclave, sealed from SayGM's operators and the host machine. On a frontier or open model, the provider serving it then processes the request under its own API terms. On a confidential model, inference runs inside a TEE too, so the prompt stays sealed end to end.

How do I tell which route a model takes?

GET /v1/models returns a tier for every model: frontier, confidential or open. Confidential models carry a -tee suffix on their id. The gateway_provider field names the upstream service that receives the request when the route leaves the gateway.

Can I verify the attestation myself?

Yes. Call GET https://api.saygm.com/attestation/info with a random nonce of your own. The response carries a TDX quote bound to that nonce and to the gateway's public key, together with the event log and VM configuration you need to check it with a TDX verifier.

Are guardrails on by default?

Guardrails are opt-in per API key. Turn them on for a key in the SayGM dashboard, and they run on every request made with that key.

What does SayGM keep about my requests?

Metadata: which model and provider served each request, token counts, price, timing, error class and guardrail counts. Prompts and completions stay out of every record. The privacy policy lists each record and how long it is kept.

[08] Further reading