Operations
Data handling
What crosses the boundary, what stays on this side of it, and what is still a decision rather than a fact.
Written to be checked against the code rather than trusted. Where something is not implemented, this page says so instead of describing an intention.
The shape of it
Tether never receives your database credentials and cannot query your systems. It reaches your data by calling an HTTPS endpoint you control, with arguments a model produced and a signature you can verify.
That is a real boundary, and it is narrower than "your data never touches Tether". Data comes back across it in tool results, and parts of what comes back are kept.
What is stored
| Data | Contains | Kept until |
|---|---|---|
| Chat history | Your customers' messages and the assistant's replies, including anything a tool result was quoted into | No automatic expiry |
| Staged actions | The arguments of a proposed write — an order id, an amount, a customer | Pruned after 30 days |
| Action executions | What a confirmed write returned from your endpoint | No automatic expiry |
| Approval records | Who approved or refused what, and when | No automatic expiry |
| Audit log | Every action transition | No automatic expiry |
| Usage ledger | Tokens and priced cost per turn. No message content | No automatic expiry |
| Telemetry | Timings, routes, model names, token counts. No message content | No automatic expiry |
| Preferences | Short statements extracted from conversation, per staff user, verified customer, or unverified visitor's conversation | Until deleted |
| Conversation owners | Which verified customer, if any, each guest conversation was opened for | Until the account is deleted |
| Knowledge chunks | Text you ingested, plus embeddings of it | Until deleted |
| Tool catalog | Your tool names, descriptions and schemas | Until replaced |
No table exists for your orders, customers, inventory or invoices. There is no bulk copy and no sync. What is above is what a breach would expose.
Deletion
Rows are soft-deleted: a flag is set and global query filters exclude them from every read. That is the right default for an audit trail — an approval record that can vanish is not an audit trail — and it is not erasure. A soft-deleted row is still in the database and still in every backup taken since.
A tenant can erase its own data with DELETE /v1/account (see Account). That
path is a hard delete, not a flag: every row Tether holds for the tenant is removed in the live
database, and every key is revoked. The tenant row remains as an empty tombstone with a salted
hash of the signup address, so that erasing an account cannot be used to obtain another
development tenant.
Secrets
| Secret | Stored as |
|---|---|
| Your Tether API keys | SHA-256. Not recoverable from the database |
| Your tool signing secret | Encrypted at rest, AES-256-GCM, key held outside the database |
| Your upstream bearer credential | Encrypted at rest, AES-256-GCM, key held outside the database |
The encryption key is Security:SecretKey. A production instance will not start without it, so
the two secrets above are encrypted wherever it runs; a development instance with no key stores
them in the clear. See Configuration. Losing or changing
the key makes them unreadable, and there is no rotation procedure yet.
The last two cannot be hashed, because they have to be presented in the clear to be useful. Reading the database alone does not yield them; reading the database and the deployment's key material does. If you have reason to think both have happened, rotate both.
A person's own token for your imported API, sent in X-Tether-Upstream-Token, is not a stored
secret at all. Tether holds it for the one request, sends it only to your imported API, and never
logs it or writes it to a row. See Calling your API as the signed-in user.
Who and what sees it
The model provider sees everything in a turn's context: the prompt, the conversation history included, retrieved knowledge, and tool results. It cannot call your endpoint — Tether dispatches tool calls, to the URL on your tenant record. What bounds this is what your tools return, which is the one control entirely on your side.
Moderation, when enabled for your tenant, sends staged write text to the provider's classifier. The instance-wide switch is off by default. When an operator turns it on, tenants on the second door are moderated unless they opt out, and tenants on the first door are not moderated unless they opt in; only an operator changes either. See Configuration.
People operating Tether can read everything in the table above. There is no technical control preventing that today; it is a contractual question, not an engineering one, and it should be settled in writing.
Before you sign
Four things this page cannot settle, all of which need a person rather than a commit:
- A retention period for each row above, enforced by a job rather than described here.
- A tested erasure procedure covering backups.
- The hosting and sub-processor list, and a data-processing agreement.
- Whether an insider control beyond contract is needed for your data.