Proof, not promises.

Tresor runs AI inside sealed hardware where your data stays protected while it is being processed. Not by policy. By physics. And you can check the proof yourself.

Verify a live receipt See how it works

Illustration of live attestation checks for confidential AI.

Live attestation you can inspect

Illustration of signed receipts tied to verified inference runs.

Signed receipts for every verified run

Illustration of memory remaining hardware-encrypted while data is processed.

Hardware-encrypted memory while data is in use

You already encrypt your data twice. We close the third gap.

Data at rest is encrypted on disk. Data in transit is encrypted over the network. But data in use, the moment it is loaded into memory and processed, has traditionally sat there in plain text. That is the gap that matters for AI.

Data stateUsuallyWith Tresor

At rest (disk)

Encrypted

In transit (network)

Encrypted

In use (memory)

Plain text

Encrypted in hardware

Your data is processed inside a sealed room that even we cannot open.

When your request reaches Tresor, it runs inside a hardware enclave, a protected zone created by the processor itself. The chip encrypts enclave memory with a key held inside a dedicated security processor on the CPU.

That key never leaves the chip. The operating system cannot read it. The cloud operator cannot read it. Tresor engineers with full root access to the server cannot read it either.

In practice, cold-boot the machine, probe the memory bus, or dump the RAM, and you do not get customer plaintext. You get encrypted nonsense.

Read the hardware deep-dive

Step 1

Your app or browser

Sends the request over TLS and can pre-check live attestation before any application data leaves your machine.

Step 2

Tresor enclave

Plaintext exists
only here

TLS terminates inside the attested runtime. Memory stays encrypted by the CPU while the workload executes.

Step 3

Approved model route

Routing, provider checks, and signed evidence stay bound to the same trust story so the request comes back with proof attached.

Every answer comes with a receipt you can verify yourself.

This is where confidential computing stops being a promise. The same evidence surface the SDK relies on is available for anyone to inspect.

1
Verify the receipt
Check the live evidence against published root certificates and open verification tooling. No private Tresor checker required.
2
Confirm the code
Match the signed workload identity to the exact software image. Change one byte and the proof fails.
3
Inspect the live enclave
Fetch the public attestation endpoint any time and inspect the trust surfaces yourself before you send application data.

Verify a live attestation now

Live evidence needs attention

invalid

The attestation surface was not fully validated. Review the checklist below and open the raw endpoint if you want to inspect the underlying evidence directly.

[GET] "/api/attestation/summary": 502 Live attestation evidence is temporarily unavailable.

Workload: Unavailable
Issued: Unavailable
Workload tag: Unavailable
TLS pin: Unavailable

Open raw /attestation

This preview checks live evidence freshness, manifest binding, and the published trust bundle surface. Full cryptographic verification is available through the open verifier SDK and CLI.

The honest answers to what you are already asking.

Not here. Memory is encrypted by the CPU, with keys held inside the chip’s security processor. The OS, the hypervisor, and anyone with root access see ciphertext, not readable customer data.
Decryption happens only inside the processor while the cores execute. The data never sits in readable form anywhere an operator can reach, and the keys never leave the chip.
The attestation report binds the runtime to a signed workload identity. If the software image changes, the workload identity tag changes too, and verification no longer matches the published expectation.
You do not rely on a vendor promise alone. The evidence chain is publicly inspectable against published certificates, and the confidential-computing ecosystem is subject to active external scrutiny. That scrutiny is part of the security model, not marketing garnish.
No. Tresor uses modern VM-level confidential computing, where the whole machine is sealed, normal software stacks can run, and the attestation surface covers the actual workload boundary used in production.

Full power, fully sealed.

Confidentiality is meaningless with weak models. Tresor is designed so the same sealed path can power serious work, not toy demos.

Speed

342.6 tok/s

gpt-oss-120B (high) on ArtificialAnalysis.ai.

ArtificialAnalysis currently measures it at 342.6 output tokens per second, making it the fastest model we show on this page.

Intelligence

Z.ai GLM-5.2 (max) on ArtificialAnalysis.ai.

ArtificialAnalysis scores it at 51 on the Intelligence Index, which is why this card now represents the strongest model in the lineup.

Capability comparable to leading public assistants, with the request path still bound to attestation and receipt evidence instead of trust-me operating policy.

Use it as a workspace, or build it into your own product.

Chat Workspace

A secure AI assistant for teams.

Upload sensitive documents, ask questions, draft reports, and collaborate inside a system where readable content is kept out of ordinary operator reach.

Zero-access chat and document workflows
Shared projects and team-level controls
Receipts and verification surfaces built in

Start a Chat Learn more

Inference API

Route your own software through the same verified path.

Same models, same parameters, same streaming shape. Change two lines and keep the zero-access guarantee attached to every request.

# Before
client = OpenAI(api_key="sk-...")

# After
client = OpenAI(
    base_url="https://api.trytresor.com/v1",
    api_key="tr-..."
)

Start building See API

At rest. In transit. And now in use. All encrypted. All verifiable by you.

Talk to the team Read the white paper

Proof, not promises.

You already encrypt your data twice. We close the third gap.

Your data is processed inside a sealed room that even we cannot open.

Every answer comes with a receipt you can verify yourself.

Verify the receipt

Confirm the code

Inspect the live enclave

The honest answers to what you are already asking.

The cloud operator can always read the memory.

Fine, but it still gets decrypted to be processed.

How do I know the right code is running?

What if the chip maker has a backdoor?

Isn’t this just Intel SGX?

Full power, fully sealed.

Use it as a workspace, or build it into your own product.

A secure AI assistant for teams.

Route your own software through the same verified path.

At rest. In transit. And now in use. All encrypted. All verifiable by you.