What Untold does not promise

13 of these 27 grades are computed from the running system, so they change when the code does, without anyone editing this page. The other 14 are written by hand — judgements a program cannot make — and each is marked stated so you can tell which is which. If we ever quietly stopped providing a guarantee, the computed ones would say so on their own; the stated ones depend on us being honest, which is exactly why they are labelled.

• Answers are produced inside an attested enclaveyes

  1 provider(s) can attest right now. Every sealed answer is produced inside an Intel TDX enclave, and the quote proving it is verified to a pinned Intel root before the answer is served. If no provider can attest, sealed requests are refused rather than quietly served unsealed — the same behaviour, whichever way the line above reads.

• The enclave runs the code we say it runsyes

  The initial image measurement (MRTD) is pinned. That one is computed by the processor's TDX module over the machine's initial contents before any guest code runs, so neither the software inside nor the operator running it can dictate it. The OS image is pinned alongside it. The application's own compose hash is NOT pinned: the provider's value moved three times in one day, so pinning it would have refused sealed delivery on their release schedule rather than on evidence. MRTD still fixes the machine's initial contents; the compose hash would have fixed which application image ran inside it.

• You are never shown an answer we cannot provepartlystated

  True when you do not stream. A non-streamed answer is verified before any of it reaches you, and is refused outright otherwise. A STREAMED answer cannot work that way — the enclave signs its receipt only once the response is complete, so tokens arrive before the proof does. A stream therefore carries no privacy badge while it is arriving, and if the proof then fails the text stays on screen with the failure stated beside it rather than being badged. STREAMING IS THE DEFAULT in the web app, and this page previously said the opposite — that streaming was opt-in and the safer path was the default — while the client hardcoded streaming and offered no alternative at all. The choice is now a checkbox in the composer, marked 'prove before showing', and it is off by default because a reasoning model can think for tens of seconds and a blank screen is its own kind of dishonesty. If you would rather wait for the proof, turn it on.

• A privacy mode we name but do not offer is listed as unofferedpartly

  Named but not offered by any model: private, e2ee. `private` rests on a contractual no-retention promise, and we have no model under such a contract, so it is a name in the protocol and not a choice you can make here.

• Every privacy mode we offer is one you can actually pickyes

  Every mode we OFFER is pickable. `private` is named in the protocol and no model offers it — see the row above. Of the three we do offer, end-to-end encryption is the strongest and it is a choice on any of the 6 sealed model(s), not a separate one: tick "Encrypt on this device" in the composer, or use /api/e2ee/relay with your API key. Your prompt is encrypted IN YOUR BROWSER to a key published inside the enclave's attested keyset, and we relay it without being able to open it. The consequences are stated where you choose it rather than buried here: on that path we cannot moderate what you send, cannot save the conversation, and cannot finish verifying the answer for you — the enclave's receipt commits to the DECRYPTED request, so only your browser holds what is needed to check it. It does that itself, and the badge will not claim the mode unless that check passed.

• An agentic answer can be provedyesstated

  One call carries the same receipt the chat issues; several calls (every tool round is one) carry a run receipt — one link per call, every link committing its prompt to the conversation exactly as you sent it and its response to what that call returned, naming the enclave's own per-call receipt, the run's mode its weakest link's — signed by us, verifiable in your tab, link by link, each link's prompt opening with your own messages. What a run receipt does NOT bind: the tool outputs and Untold's own text each later call was given, which nobody was ever handed and so nobody could have opened. WHEN THE ENCLAVE CANNOT PROVE A CALL, THE ANSWER IS NOT SERVED: the run tries the next model, and if none can be proven it refuses and /api/agent says which call failed and on what condition. It used to serve those words badged unproven, which meant the same question delivered or refused depending only on whether its last call streamed — chat has always refused. The cost is availability, and we would rather lose an answer than hand over a sealed one we cannot prove. What the agent guarantees either way: the mode it reports is the WEAKEST across every model call — never the best one used — and every service it contacted is named on the answer.

• Tools you connect yourself reach only what you approvedyesstated

  Nothing of yours is connected by default. The public MCP registry can be searched from the connect dialog, behind our short verified list and labelled: anyone may publish there, a result only suggests an address, and the search words go to that registry's host when you press the button and not before. You can connect your own tool servers, and each one publishes NOTHING until you have seen what it offers and TICKED THE TOOLS YOU WANT — approving a server is not approving everything it offers, so a connection you made to read your issues need not also be able to delete them. Where a server says whether a tool only reads, we show you what it said and label it as the server's own claim: the protocol is explicit that those hints must not be trusted from a server you do not control, and a tool that deletes could simply claim otherwise. Those claims are pinned along with the tool's description and its inputs, so a server that re-labels a tool after you approved it is held back until you look again — that is a real attack the protocol itself does nothing about. Your connections are yours: they are built for your run alone and are never visible to anybody else's. Where a service can express the difference, you choose whether the connection is allowed to change things or only to read — and it is offered only where the service’s own scopes can express that, because a control that narrows nothing is worse than none. It is NOT read-only by default: the thing that prompted this feature was an agent refusing to commit a file, and a default that hides writes would ship that refusal inside the fix. Addresses must be HTTPS and are refused if they resolve onto a private network — checked when you connect and again inside every call, because an address may resolve differently in between. Connectors offers a short list of services a run has been seen using, with the date last checked; that is a starting point and NOT an endorsement of what any of them does with what you send, and every one goes through the same checks as an address you type. Looking at a service creates nothing: a connection exists only once you start its first step, and it is not added — not counted, not offered under the message box, not used by an answer — until you have finished every step and chosen at least one thing it may do. The name on your answer’s contacted-services line is the verified host, never the label you typed. When a connection you added contributes nothing, the run says which of three reasons it was — its tools changed, your sign-in lapsed, or it did not answer — rather than quietly leaving it out.

• We do not store the credentials for tools you connectpartlystated

  WE DO NOT KEEP IT; WE ARE NOT BLIND TO IT, and the difference matters. A credential for a server you connect — one you typed, or one from signing in — is stored in your own browser and is never written to our database. Connecting sends the address alone, so a dump of our storage yields an address and an approval and nothing that could act on your account. There are three moments when it reaches this process anyway, and all are real. The tool call is made by our server, so the credential passes THROUGH this process while a tool runs. For GitHub, the same token is also used, from our server, to ask GitHub where its app is installed — once when you sign in and again when a GitHub answer comes back empty — so we can tell you it reaches nothing rather than let the agent say you have nothing; that request goes to api.github.com, and it is named where it happens: on the answer’s contacted line during an answer, and in the connect dialog when you sign in. And when you sign in, the exchange that turns the service’s answer into a token is made by our server too — not by preference: this site forbids your browser from contacting any other origin, and lifting that to move one request would hand any future script injection a list of places to send things. So a stolen database is worthless and nobody here can browse your tokens at rest; it does not mean we could not read one in flight if we were compromised. We hold no client secret of our own for any service, and where a service hands one back we drop it. If your sign-in expires we say exactly that, rather than reporting the server as broken or as having changed. The stronger version — stored as ciphertext whose key never leaves your device — is designed and not yet built, and this row will say so until it is. `partial` is the honest grade.

• We tell you when a run read the web and then touched your accountspartlystated

  PARTIAL, and the honest version is worth more than a stronger-sounding claim. Content the agent reads can try to influence what it does next — a page or an issue can contain instructions aimed at the model, and if you have connected a tool that reaches one of your accounts, the combination of the two is the shape every published attack on agents uses. Nothing in the protocol prevents it, and the people who wrote the protocol say so. What we do is NOTICE: when a run reads something from outside and afterwards uses a tool that reaches an account of yours, the answer says so and names which. We do NOT block it, because "look this up and then file it" is the thing an agent is for, and refusing it would trade a real capability for a partial defence. So this is disclosure, not protection: it puts the one judgement a program cannot make in front of the person who can make it.

• Skills you write stay on this deployment and reach nothingyesstated

  A skill is instructions you wrote for a kind of task. The agent carries a one-line description of each on every run and loads the full text only when the work matches, so a shelf of them costs almost nothing until one applies. Loading one contacts nobody: the text was already here and the lookup is in memory, so a skill never appears on the contacted-services line and cannot widen what a run touches. Yours are offered to your runs only. When one is used it appears in the run's steps, so you can see which instruction shaped the answer rather than having to take our word for it.

• The agent can search the web or generate imagespartly

  Search, yes; images, pictures only, no editing or video. The agent can call: get_time, calculate, convert_currency, crypto_price, get_weather, web_search, fetch_page, read_document, run_javascript, generate_image. Every call is shown on the answer with what it sent and what came back, and the answer names each service contacted — a search query goes to the search service, a page address to that page's server, a place name to the weather service. This deployment has no other services attached: everything above is a keyless public endpoint or runs on your own device. It cannot edit images or make video, look up sports scores, or send anything to anyone. It CAN read an image you attach: the picture goes on the model call itself and the answer says it was read. What the answer claims about tools is computed from the inventory and from the calls that actually ran — a record, not a best-effort reading of the model's own wording, which is what the old per-step marking was and which will miss phrasings by construction.

• You can recover an account if you forget the passwordno

  Not yet, and this is a configuration gap rather than a missing feature. The flow, the tokens and the sign-out-everywhere behaviour are built and tested; no mail provider is configured, so there is nothing to deliver the link. Asking for a reset returns an error saying exactly that rather than telling you to check an inbox that will receive nothing. Support is the route in the meantime.

• The model itself ran in the enclave, not merely the gatewayyes

  Worth separating, because the two are not the same. Every model on the gateway — confidential or not — returns a receipt signed by the SAME enclave keyset, so a valid signature alone proves only that the gateway handled the request inside a TEE. We additionally require the receipt to record that the upstream MODEL was itself attested, and that it is the model you asked for, AND that the gateway itself would have refused to serve had that check failed. Measured: the documented gateway enforces it, while another endpoint for the same model in the same enclave records the failure and serves anyway. We only call an answer sealed when two independent parties enforced it, not when one of them merely noticed.

• The enclave's evidence is rooted in Intel's own certificatesyes

  Every quote's signature is verified to a PINNED Intel SGX Root CA: the certificate chain, the quoting enclave's report, the binding between that report and the attestation key, and the signature over the measurements themselves. Every certificate travels inside the quote, so this runs offline — no Intel service is contacted. What it does NOT cover: Intel's TCB status and revocation lists, so a certificate Intel has since revoked, or a platform on downlevel microcode, would still pass here.

• The signing keys are the enclave's ownpartlystated

  The receipts you can verify are signed by a workload keyset, and that keyset's digest is re-derived from the keyset itself rather than trusted. What we CANNOT yet show is a cryptographic link from that keyset into the Intel-signed quote: the quote's REPORTDATA does not carry the keyset digest, and the key-custody chain the gateway supplies is carried as evidence rather than verified, because the signed preimage is undocumented. So the tie between 'this hardware is genuine' and 'these are the keys it holds' currently rests on our connection to the gateway. It is the weakest link in the chain and we would rather name it than let the Intel root imply it away.

• A captured quote cannot be replayedpartly

  The attestation endpoint is not challenge-response, so the nonce we send is not bound into the quote. Replay is bounded three other ways. We re-fetch evidence every minute and refuse anything older than ten. Each answer carries a receipt signed inside the enclave committing to that exact request and response, so a receipt cannot be moved to a different exchange. And that receipt must have been issued within the last five minutes. THE THIRD ONE MATTERS MORE THAN IT SOUNDS, and we had it wrong: committing to bytes proves WHICH exchange a receipt describes, not WHEN it happened. Requests are deterministic, so two people asking the same short question produce identical bytes — and without a freshness bound a single genuine receipt could have been replayed against every matching request until the signing keys rotated. A nonce answers 'is this happening now'; a byte commitment answers 'is this the same thing'. We need both, and we previously described the byte commitment as the stronger of the two.

• We cannot read your conversationpartlystated

  Conversation payloads are stored as ciphertext with wrapped keys, and no table can hold prompt or response text — the column type refuses a string at runtime. But the key that unwraps them is held by our servers, which is how the account export returns them in the clear: this defeats a stolen database, not us. Client-HELD keys for stored conversations are not shipped. End-to-end encryption, which is shipped, is a different thing and covers the request rather than the archive.

• A receipt proves what happened without revealing ityesstated

  Receipts are EIP-191 over the sha256 digest of RFC 8785 JCS(body). They carry a salted COMMITMENT to your prompt, not a hash of it — a bare hash would let anyone holding a filed receipt confirm a guess from a candidate list. The salt is returned to you and never stored, so we cannot open your commitment either. You can, if you choose to prove what you asked: the commitment is over the conversation exactly as you sent it, on the chat, the agent and the API, streamed or not, with our own instructions, your saved memory and your attached documents outside it (pictures you attach are inside it), so your own messages open it. It proves what you submitted, not that the model read all of it: a long history can be cut before it reaches the model.

• You can verify a receipt without trusting uspartly

  THE TOOL IS NOT PUBLISHED YET. `npx @askuntold/verify` does not resolve and this repository is private, so today you would have to ask us for the verifier — which is precisely the dependence it exists to remove, and we would rather write that down than let this row read as done. What you CAN do without anything of ours: the signature is EIP-191 over the sha256 digest of the canonicalised body, so ordinary Ethereum tooling checks it against the address below, and the digest must equal sha256 of the canonicalized body. When you do have the tool it makes no network calls — run it disconnected, that is the point. It needs ONE thing you did not get from the receipt: our signing address, 0xA1641C53Be06C7d3370403e7daC01660A209F8D1, published here and fetched over TLS. Pass it with `--signer`. Without it the tool reports CANNOT CONCLUDE rather than OK, because a signature checked against an address that arrived in the same file shows only that whoever wrote the receipt also signed it — anyone can generate a key and do that. Inclusion proofs work the same way: a proof checked against its own root proves nothing, and the tool says so rather than inventing a verdict.

• Every model is privatepartly

  6 model(s) can be sealed; 22 are third-party passthrough and can never be. Passthrough models are labelled anonymised, carry no enclave provenance, and are refused outright if you require sealing. We do not attest somebody else's API and we do not pretend to.

• Rate limits are accurateyes

  Your tier limit is a single shared counter, so it means the same number however many servers we happen to be running. One limiter is still per-instance on purpose: the one that runs before you are authenticated, because sending anonymous traffic to a shared database would turn the limiter itself into something worth attacking. Note the ceiling above your tier: an unauthenticated guard allows 60 requests a minute per address on the chat routes, and it runs BEFORE your key is checked. Every paid tier's number is higher than that, so from a single address you will reach 60 a minute rather than your tier's figure. We would rather say so than let you discover it as 429s you cannot explain.

• We publish the number that would catch us lyingpartlystated

  PARTIAL, and the correction is worth more than the claim. We tried three times to build a counter INSIDE the request that would catch us delivering a weaker mode than promised, and all three compared a value against itself: the catalogue entry the delivered mode came from; then a value the caller sent us; then the receipt, whose body is literally the same object. Within one request every field naming the mode descends from one decision, so no two of them are independent — a comparison that cannot differ is not a tripwire, and publishing it as one was the dishonest part. What runs now is OUTSIDE the process: a monitor fetches the catalogue over HTTP, asks for an answer, and compares the advertised mode, the delivered mode and the mode inside the receipt — three values obtained separately, against the deployed system. In-process we check something narrower and real: every receipt is verified against the signing address published on this page before the answer is served, and a receipt that fails is refused rather than sent with a proof that proves nothing.

• The Studio makes images, video and audiopartly

  1 provider is configured. Not offered by any configured provider: video, edit, reference, upscale, background, music, tts, voice, sfx. The six tools, their sessions, the credit debit-and-refund, the library and the sealed storage are built and tested; each control goes live only when a provider declares the field it needs, and a tool with no provider says so on the page rather than pretending. Video also needs a render worker consuming the queue, which the Studio checks from the worker's own heartbeat and claims, never from a flag. This deployment starts a render worker inside its web process (UNTOLD_RENDER_WORKER=1); whether it is consuming right now is read from its heartbeat on the Studio page. Prompts pass a word-list filter, not a classifier: on every tier it refuses a prompt that pairs a marker for a minor with a sexual marker FROM ITS LIST, and on the moderated tier it also refuses gore, explicit and NSFW. A list is not a boundary — a phrasing it does not hold passes it — so the provider's own refusal is the second layer, and neither is a classifier. The pre-Studio image and video routes, which charged and filtered nothing, answer 410. The label under every result names who read the prompt — the sealed enclave or the provider by name — and never says "anonymized".

• What you share on the Feed is publicyesstated

  Sharing is the act of making something public, and the sheet says so before the press: the picture or clip, its prompt, its tags and your handle become public; your library copy stays sealed and only you can delete it. Unsharing removes the post and every vote, save, reaction and report on it. The media itself is not classified by anything we run: the sharer's own mature mark, three reports from different people, and a guest listing that carries no mature post are the controls. A shared file may live in a browser or edge cache for up to five minutes after an unshare.

• You can take your data and you can make us forget youyesstated

  Export at /api/account/export gives you everything we hold, decrypted, as a file. Deletion at /api/account destroys the content — conversations, artefacts, keys, sessions — rather than flagging it. Credit-ledger rows survive because a financial record has to, but they stop referencing you: the amounts remain, the person does not. Worth stating plainly that until recently deletion was not merely unimplemented, it was impossible — the database refused every route to it.

• We could get your data back if we lost itpartlystated

  The restore is rehearsed, not assumed: a script dumps the database, restores it into a throwaway copy, compares every table in every schema by row count AND a content digest — one changed byte in one restored row fails it, with the table named — and checks that the ledger's tamper-proofing survived the restore — measured at 64 seconds on 400 MB. But it has only been rehearsed against the development database, not production, and nothing pages a human when something breaks. Both are gaps we would rather name than let you assume away.

• We know who you arenostated

  You can use the product with no account at all. An anonymous identity carries no entitlement penalty, and nothing about the sealed tier is gated on paying — what is paid for is topic freedom, never privacy.

Also available as JSON at /api/limits, so you can diff our claims over time.