Privacy Policy

The short version

Sable Network is a compute platform. The single most important thing to know about our privacy posture: the content of your requests (prompts, completions, and any code you submit for execution) is never written to our disks or our logs. It exists only in memory for the moment it takes to serve the request, and is then gone. We do not train on it, we do not retain it, and we cannot produce it later, because we never kept it.

What we do not store

• Prompt text or message content.
• Model completions or generated output.
• Code submitted to a sandbox, its environment variables, or its stdout/stderr.
• Any upstream provider response body on a successful request.

These are handled entirely in-frame: decrypted at the moment of use, passed to the model host or execution runtime, returned to you once, and never persisted. Our databases have no column that could hold them.

What we do store (metadata only)

To meter usage, enforce budgets, and produce signed receipts, we record metadata about each request: a request identifier, the API key and account it belongs to, the model and provider used, token or resource counts, cost, latency, status, region, and a content fingerprint (a sha256 hash prefix of the request body, never the content itself). Signed receipts carry this same metadata and the fingerprint, never content.

We store account information (wallet addresses used for sign-in, an email placeholder), API key hashes (keys are stored as Argon2id hashes; the plaintext is shown once at creation and is never re-derivable), billing ledger entries, and on-chain deposit records. Prompts are encrypted in transit and sealed on ingress.

Training and model providers

We do not use your prompts or completions to train any model. Sable routes requests to upstream model hosts to serve them; those hosts process the plaintext to run the model, which is what running a model means. On the standard and anonymized tiers, the upstream host sees the prompt (though never your identity; the vendor sees Sable, not you). On the confidential tier, the request runs inside a hardware-attested enclave and the host provably cannot read it. We select providers with data policies consistent with this posture, but their handling of in-flight data is governed by their own terms.

Logs and retention

Operational logs contain identifiers, model strings, token counts, latency, and error classes. Never prompt or completion content, and never decoded error bodies that could echo a prompt. Metadata usage records are retained for billing, audit, and your own usage history. Webhook delivery logs are pruned after 30 days.

On-chain data

When you fund a balance with USDT, or when a receipt or vault batch is anchored, information is published to a public blockchain (a transfer, a memo commitment). On-chain data is public and permanent by nature. Anchored commitments are content-free fingerprints: they prove that something occurred, never what.

Your controls

• Revoke any API key at any time; revocation cascades to delegated sub-keys.
• Unlink a wallet or invalidate all sessions from the portal.
• Export your usage history as CSV.
• Opt into outbound scrubbing (sable_scrub) to redact secret and PII shapes from a prompt before it reaches any provider.

Contact

Questions about this policy: contact@buildsable.com. Security disclosures: security@buildsable.com. The technical privacy contract is documented at /docs/privacy.