> ## Documentation Index > Fetch the complete documentation index at: https://docs.trynito.ai/llms.txt > Use this file to discover all available pages before exploring further. # What a TEE Is > Trusted Execution Environments and the attestations they produce, in plain language. Encryption protects data at rest and in transit. The hard case is data **in use**: to run a computation, a machine has to decrypt the data into memory. At that moment, whoever controls the machine, the operating system, or the hardware can in principle read it. A model cannot answer without processing your prompt, so the prompt is exposed exactly when the work happens. ## What a TEE Is A **Trusted Execution Environment (TEE)** is a region of a computer, enforced by the processor itself, that runs code in isolation from everything else on the machine. The machine's owner, the operating system, other programs on the same hardware, and someone with physical access cannot read what is inside or change it. The isolation is policed by the silicon, not by software the host could switch off. ## What Attestation Adds Isolation alone would still be a promise: you would have to believe a genuine sealed environment ran your work rather than an ordinary machine. An **attestation** removes that leap. It is a signed statement, generated by the hardware, describing what is running inside the sealed environment. * It is **signed by the hardware**, using a key rooted in the silicon, so it cannot be forged in software. * It commits to **what is running**, as a measurement: a cryptographic fingerprint of the exact code loaded into the environment. If the environment is not a genuine TEE, or the code inside has been swapped, the attestation does not check out. Think of it as a sealed box that also hands you a tamper-evident receipt proving it was that box that did the work. ## Binding It to Your Request A receipt only helps if it describes **your** computation and not an old one being replayed. You include a fresh, unpredictable value (a nonce) with the request, and the TEE binds it into the attestation. Confirming your value is present is what tells you the receipt was produced for this request. Every verification recipe in this section starts by generating a new one. ## What This Means on Nito Confidential calls run inside these sealed environments, and you can fetch the attestation and check it yourself. Producing an attestation and **fully** verifying its hardware evidence are two different jobs. Nito runs a baseline check and returns the raw evidence to you. The hardware quotes and certificate chains are yours to validate if your threat model demands it. That split is why these docs say a result is **attested** and **verifiable**: it makes you the final verifier rather than someone trusting Nito. ## Related Resources The end-to-end flow of a Confidential attestation. The exact checks Nito runs, and the scope limit. The procedure for checking an attestation.