Account and trust
Zero retention by default.
Every model with a zero-retention route uses it by default, with nothing to switch on. Signed receipts make every charge checkable.
On this page
Account and key records
Account identifiers, linked wallet details, key labels, limits, and the hash used to validate each API key.
Usage records
Model, upstream provider, endpoint, token counts, cost, status, timestamps, and settlement references.
Public proofs
Settlement digests, transaction references, price sheets, and inclusion proofs needed to verify charges.
Prompts and completions
Models with a zero-retention route use it by default. A model marked 'provider may keep data' is served by a provider that may keep request data; choosing it is your choice. GET /v1/models shows it as may_keep_data, and each route's data_policy is in GET /v1/pricing.
Each request can ask for its own privacy: see Provider preferences for the asks. What is kept, and for how long, follows below.
By default we keep no prompt, completion or tool-call text, and the usage table has no column for them. Exceptions you control: request logs, if you turn them on for the account or a key, keep the prompt and the response for 30 days; a saved preset keeps its system prompt until you delete it. A batch result stays with the model provider that ran it, up to 7 days after the job ends; a generated video is held in memory at most 30 minutes.
What the provider does with the content is published per route, as that route's data_policy in GET /v1/pricing. It is there before the request is ever sent.
Each request goes to the cheapest available provider for its model. That provider processes it under its own data policy, and you must follow the model provider's terms and acceptable-use rules.
Foundry keeps no prompt or output by default. A key in no-logs mode keeps prompt text, completion text and tool arguments out of every write path: the database, a log line, an alert. Error paths are included. Every key starts in no-logs mode. To keep a key's requests for 30 days so you can read, export or delete them, turn on request logs for the account or for one key on the dashboard. Private-tier keys are never logged.
- Still recorded: token counts, cost, model, latency and status. They make a charge billable and checkable against the usage log.
- A no-logs request is marked as such on its own row.
- Set it per key on the dashboard, or as the default for every key the account creates. See Spend caps, allowlists and pause.
| Record | Kept for | Why |
|---|---|---|
| Usage rows | Indefinitely. Never deleted. | Each is a leaf in the public usage log, anchored onchain. Removing one would break a proof someone already holds. |
| Request detail | 90 days | How the request ran: the routes tried, timings and status. Never any content. |
| Request logs | 30 days, or until you delete it | Only for an account or key with request logs turned on. |
| Presets | Until you delete it | A saved preset keeps its system prompt. |
| Batch job results | Held by the model provider, up to 7 days after the job ends | Then the result expires. Its status, cost and receipt stay. |
| Unclaimed USDF links | Until expiry: 30 days, or less if the sender sets it | Then the amount goes back to the sender. |
| Statements | As long as the account exists | One per month, as CSV, PDF or JSON. |
| Account and key records | As long as the account exists | A revoked key's record stays, so past usage stays attributable in the activity log and statements. |
| Private attestation receipts | Archived. Never deleted. | Kept for verification. |
Anyone, with no key, can read a request's receipt:
- Its model, provider and endpoint.
- Its token and cost figures, the price sheet version and the status.
- For an x402 or MPP payment, the payment itself.
Prompt and completion text are never published. To check a receipt against the log yourself, see Verify.
Every receipt is public at GET /.
Full API keys are shown once and stored only as hashes. Wallet ownership is proved by signature; private wallet keys never leave the wallet.
Attested hardware
Private-tier requests run only on attested hardware, at the same price as any other request, encrypted in transit and inside that hardware, with signed receipts and an onchain build registry. Before a route serves one, Foundry verifies its Intel TDX quote, its build and its keys itself. What is proven about the GPUs depends on the route, as the table below says. A request with no matching route is refused before any charge. Archived reports appear here by date and key rotation.
- Attestation
- Checking
| Attested route | Foundry verifies before it serves | The provider attests |
|---|---|---|
| Attested instances | The Intel TDX quote to Intel's root, the build in the registry, the instance's encryption key, and the confidential computing evidence of its GPUs | Nothing Foundry relies on |
| Attested gateway | The Intel TDX quote to Intel's root, the build in the registry, and the keys the gateway signs and encrypts with | The GPUs behind the gateway: Foundry does not check them itself |
Which routes serve now, and when each was last verified: GET /.
Ask for it per request: add the model suffix :private, or send "provider": { "private": true } in the body. Or set a key to Private tier on the dashboard; a Private-tier key whose setting cannot be read is refused rather than served on an ordinary route. A request that cannot be served on attested hardware is refused and nothing is charged: no_route_for_policy when no attested route fits it, private_unarmed or attestation_unverified while its attested routes are not connected or not verified now. A model's private in GET /v1/models says whether a private request for it is served now.
Every private response carries a signed receipt and the attested provider's receipt id, and an onchain build registry identifies the attested code. After the response the gateway fetches the provider's receipt, checks it and archives it byte for byte with its SHA-256. GET /v1/privacy/receipts/{request_id} returns the archived receipt to the key that made the request, and GET /v1/receipts/{request_id} shows its attestation as pending, verified or failed. Verify checks a private receipt in your browser: Foundry's signature, the build in the registry, Intel's TCB status and, with the answer's whole receipt pasted, the enclave's own signature.
Attested private requests are billed at the model's own price, in USDF. A private request for a model with no attested route is refused and nothing is charged. See Security for what serving it needs.