Privacy policy

Heimdallm is operated by Consensus Protocol LLC. This page states what the marketplace stores about the people who use it, for how long, which other parties receive a request, and how to export or delete an account. Data & privacy is the longer account of the same facts, including how to route on a provider's declared policy. The terms of service cover the rest of the relationship.

Who receives a request#

Heimdallm authenticates a request, routes it and forwards it. The serving provider receives the request body — messages, tools and parameters — and the optional user field when one is sent. A provider is an independent operator, and what it does with a request is governed by the data policy it declares for each endpoint and by its own privacy policy, both linked from its public profile.

A request can be restricted to providers that declare no training on prompts (data_collection: "deny") or zero data retention (zdr: true). An endpoint's zero-data-retention claim is shown as ZDR only once the marketplace has reviewed the provider's deployment and approved it, and shows as pending while review is open. An undeclared policy is never read as a promise.

The provider is shown what its own endpoints did — the model, the status, timings and token counts — and never the account, workspace or API key that sent a request.

What is stored and for how long#

The marketplace's record of a request is a billing record: ids, model, provider, token counts, timings, finish reason and exact cost. It holds no copy of the prompt or the reply.

Copies kept so the service can be restored after a disaster are retained separately from the table above. Database dumps and the write-ahead log archive taken before a record was removed still contain it until those copies age out under their own retention, which a record's own lifetime does not shorten. The content of a stored file is the exception: it is encrypted before it is written, under a key kept outside every copy and destroyed no more than 50 hours after the file was stored, so a copy holds nothing that opens it after that. The requests and replies a batch holds while it runs are encrypted the same way. Generated video and meshes are not, nor are the reference images sent with a video or mesh job while it runs: they are deleted as the table says, and a copy made before that holds them for up to 30 days.

Chat conversations in the playground are kept in the browser's own storage, and the server holds none of them. A coding machine's files are copied to the browser the same way; the machine's disk is destroyed with the machine, and the marketplace keeps no file, filename or hash from that copy.

An automated system watches each coding machine's behaviour to keep one customer's machine from attacking the platform or another customer. It judges the live view once and discards it. A flagged session keeps only a content-free record of counts and categories, and nothing of the work done on the machine.

Cookies#

• __Host-heimdallm_session holds the browser session.
• __Host-heimdallm_oidc holds the state of a sign-in for the length of that attempt.
• __Host-heimdallm_ref is set by an invitation link. It holds the referrer's eight-character code and nothing about the visitor, and is kept for three days from the last invite link opened.
• __Host-heimdallm_sandbox holds the id of the coding machine the playground has selected, so that the coding plane routes to it. It lasts for the browser session.
• hd_voter is set the first time a visitor votes on a showcase item. It holds a random value and its signature, lasts a year, and is the anonymous identity a vote is counted by.
• hd_pg is set on the address of a sandbox preview that is not public, when a viewer allowed to open it follows its access link. It holds a sealed access grant for a limited time.

Each of the four __Host- cookies is set under two names, the second being __Host-heimdall_session, __Host-heimdall_oidc, __Host-heimdall_ref and __Host-heimdall_sandbox respectively, with the same value and lifetime, so that a browser holding either name keeps its session and its choices.

All but __Host-heimdallm_sandbox and __Host-heimdall_sandbox are HttpOnly, so no script in the page can read them. The marketplace sets no advertising or analytics cookie.

Who else is involved#

• Identity providers. Google and GitHub authenticate the sign-in and share the profile above.
• Payment rails. Card payments, where offered, are taken on Stripe's page, and card details never reach the marketplace. Stablecoin transfers and x402 payments are blockchain transactions, public by nature on their chain.
• Providers. As above, for every request they serve.

Exporting your data#

The account page's Privacy tab produces a zip archive of everything held about the signed-in person: the account and its workspaces, sessions, keys, wallet bindings, deposits, previews, sandbox sessions, the full credit ledger and every billed request, with the content of stored files. Records an organization or a provider owns appear only as membership facts, and records kept for platform security are not included.

Deleting an account#

Deletion is requested from the same tab and runs on a 48-hour countdown that can be cancelled while it runs. When it ends, every browser session stops, API keys of a personal account are disabled, wallet bindings and shared previews are revoked, stored files are erased, and membership of organizations and providers ends. The remaining balance is forfeited, because balances are not refundable. The email address becomes free to register again, with no link to the old account.

The ledger and usage history are append-only accounting and are kept, attributed to an opaque account id from which the email, name, avatar and external logins have been removed. Nothing that remains identifies a person.

Questions#

Support lists the channels. The export and the deletion above need no request to anyone.